Announcement

Collapse
No announcement yet.

Unused Textures

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Unused Textures

    I seem to remember there being an editor console command to remove unused textures from a map but I can't remember what the command is and don't see it in any list of commands I can find either. IIRC it was mentioned in some video mapping tutorial by Clawfist. Anyone know what that command is?

    Also are there any similar commands for meshes or other assets that should be run occasionally to clean things up?

    #2
    I was under the impression the cook ignores all unused assets. I have a few folders of custom textures and meshes but my latest pak on a shell was only 5MB.
    DM-Nine | CTF-HolyOak

    Comment


      #3
      I'm very interested to know which of the two scenarios in this post is the final answer. Clawfist, could you or someone else from Epic clarify? Thanks!

      Comment


        #4
        Cooking a map will only supply items referenced by that map, and aren't already in the build.

        If it supplied everything without checking, every single map would be 5.6GB, as that's the size of the fully cooked game.

        Comment


          #5
          The command I'm thinking of may have been "CleanBSPMaterials" which seems to be the same thing as the "clean geometry materials" button.

          At any rate when I use either a message window opens saying "Cleared 0 BSP material references. Check log window for further details."

          Not sure exactly what it's supposed to do though.

          Anyhow the issue was the pak file size of a map I'm working on has grown huge very quickly. I was wondering if it might be due to unused assets (mostly a bunch of materials I'd experimented with using but didn't use in the end) not being cleared properly and still being included the pak file anyhow.

          But it looks like the file had grown larger than I realized sooner than I thought. Working backwards, removing materials, meshes, lifts, doors, reflection captures, etc., the file grew incrementally smaller until finally I was back down to a untextured greybox shell about the same size as the original BSP shell I started with.
          Last edited by MoxNix; 06-17-2015, 11:53 PM.

          Comment


            #6
            In a shell, one of the main culprits for file size is likely to be lightmaps. It might help to go through all the hidden faces in the level and apply a black unlit material to them (M_Shell_SolidBlack can be found in the ShellResources folder). The editor will detect that it's an unlit material and skip over it when building lighting, so you won't waste memory on lightmaps for surfaces that will never be seen.

            If you click the viewport dropdown where it says "Lit" by default you can also change that to the Lightmap Density view mode to visualize the density of the lightmaps in the level relative to their size - though currently you can only see this after building lighting. Anything that shows up blue is fine, and anything red should probably have its lightmap resolution tweaked unless it really needs it. You might be able to shave of a few MBs doing that.

            Just to confuse everyone, lightmap resolution is backwards for BSP surfaces - with static meshes, increasing the value increases the resolution, but with BSP it's the other way around. So for big BSP surfaces that don't need the lightmap resolution because they're far away or don't have shadows cast across them, you can try increasing (decreasing) their lightmap resolution to something like 256

            Comment


              #7
              Originally posted by [Epic]Thomas Browett View Post
              In a shell, one of the main culprits for file size is likely to be lightmaps. It might help to go through all the hidden faces in the level and apply a black unlit material to them (M_Shell_SolidBlack can be found in the ShellResources folder). The editor will detect that it's an unlit material and skip over it when building lighting, so you won't waste memory on lightmaps for surfaces that will never be seen.

              If you click the viewport dropdown where it says "Lit" by default you can also change that to the Lightmap Density view mode to visualize the density of the lightmaps in the level relative to their size - though currently you can only see this after building lighting. Anything that shows up blue is fine, and anything red should probably have its lightmap resolution tweaked unless it really needs it. You might be able to shave of a few MBs doing that.

              Just to confuse everyone, lightmap resolution is backwards for BSP surfaces - with static meshes, increasing the value increases the resolution, but with BSP it's the other way around. So for big BSP surfaces that don't need the lightmap resolution because they're far away or don't have shadows cast across them, you can try increasing (decreasing) their lightmap resolution to something like 256
              .... so if you had default textures in back of areas that will never be seen you should apply the black unlit material to them as well?


              http://aggressivewarriors.com -=- {AW}'s Community Map Test Server -=-

              Comment


                #8
                Yeah, if you look at the outer faces of a map like CTF-CrashSite you'll see they're black too - though the important thing is just that it's a material set to "Unlit". It should cut down on lighting build times a little as well.
                Last edited by EGTomB; 06-18-2015, 05:05 PM.

                Comment


                  #9
                  Originally posted by [Epic]Thomas Browett View Post
                  In a shell, one of the main culprits for file size is likely to be lightmaps. It might help to go through all the hidden faces in the level and apply a black unlit material to them (M_Shell_SolidBlack can be found in the ShellResources folder). The editor will detect that it's an unlit material and skip over it when building lighting, so you won't waste memory on lightmaps for surfaces that will never be seen.

                  If you click the viewport dropdown where it says "Lit" by default you can also change that to the Lightmap Density view mode to visualize the density of the lightmaps in the level relative to their size - though currently you can only see this after building lighting. Anything that shows up blue is fine, and anything red should probably have its lightmap resolution tweaked unless it really needs it. You might be able to shave of a few MBs doing that.

                  Just to confuse everyone, lightmap resolution is backwards for BSP surfaces - with static meshes, increasing the value increases the resolution, but with BSP it's the other way around. So for big BSP surfaces that don't need the lightmap resolution because they're far away or don't have shadows cast across them, you can try increasing (decreasing) their lightmap resolution to something like 256
                  Thanks for the insight. I remember back in 2k4 having to meticulously review large surfaces for shadows and determine a good lightmap resolution, and apply the unlit black to hidden surfaces... looks like it's still a common practice.
                  DM-Nine | CTF-HolyOak

                  Comment


                    #10
                    The map I'm working on is 155M with lightmap resolution of 16 on all surfaces and the default editor texture on surfaces that can't be seen (only a handful of surfaces, mostly on the outside of a large additive build box and on three subtractive cuts into it).

                    Starting with that map I did some more testing to see how changing various things affects filesize.

                    Putting the texture Thomas suggested on those few surfaces (about 9 in total) only reduced filesize by about 100k. an insignificant amount. The map is still over 155M.

                    I got about the same results by simply leaving the default texture on those surfaces and changing the lightmap resolution on them to 256.

                    Changing lightmap resolution on all surfaces from 16 to 32 reduces filesize by about 5M or about 3%. The map is still over 150M.

                    Removing all reflection captures reduces filesize by 40 megs (25.8%), bringing it down to 115M.

                    But not having any reflections in the map doesn't look very good and even then the file size still seems excessive to me, especially considering the map isn't very far along yet. It's mostly just fairly simple BSP, doesn't have a lot of materials, meshes or emitter and has no sound, music or dynamic lighting (except a single stationary light, the sunlight actor). I'm concerned by the time it's finished, fully meshed, textured and complete with atmospheric details like sounds, music and (more) emitters, it's going to be over 1G! If most maps are going to wind up even approaching 1G, that's going to be problematic.

                    I guess the real question is whether this is temporary or not. Are map files always going to be so huge or is there still plenty of room for eventual improvement through planned optimizations?
                    Last edited by MoxNix; 06-18-2015, 08:38 PM.

                    Comment


                      #11
                      Originally posted by MoxNix View Post
                      The map I'm working on is 155M with lightmap resolution of 16 on all surfaces and the default editor texture on surfaces that can't be seen (only a handful of surfaces, mostly on the outside of a large additive build box and on three subtractive cuts into it).

                      Starting with that map I did some more testing to see how changing various things affects filesize.

                      Putting the texture Thomas suggested on those few surfaces (about 9 in total) only reduced filesize by about 100k. an insignificant amount. The map is still over 155M.

                      I got about the same results by simply leaving the default texture on those surfaces and changing the lightmap resolution on them to 256.

                      Changing lightmap resolution on all surfaces from 16 to 32 reduces filesize by about 5M or about 3%. The map is still over 150M.

                      Removing all reflection captures reduces filesize by 40 megs (25.8%), bringing it down to 115M.

                      But not having any reflections in the map doesn't look very good and even then the file size still seems excessive to me, especially considering the map isn't very far along yet. It's mostly just fairly simple BSP, doesn't have a lot of materials, meshes or emitter and has no sound, music or dynamic lighting (except a single stationary light, the sunlight actor). I'm concerned by the time it's finished, fully meshed, textured and complete with atmospheric details like sounds, music and (more) emitters, it's going to be over 1G! If most maps are going to wind up even approaching 1G, that's going to be problematic.

                      I guess the real question is whether this is temporary or not. Are map files always going to be so huge or is there still plenty of room for eventual improvement through planned optimizations?
                      I see your concern. My map is tiny, and just filling it with Outpost23 assets and not a single custom thing has made it go from 7.7mb at a complete shell to 63mb at a 50% meshed map. Ive kept all my light maps on default have added reflection sphere catpures sparingly. I think we should move this to another thread?

                      Comment


                        #12
                        After further testing I've come to the conclusion textures increase map filesize more than anything else. Talking about the textures used to create materials here, not lightmaps. Doubling the dimensions of a texture increases the number of pixels by 4x too (twice as wide and twice as high = 4 times larger).

                        Going with textures in package files like 99 and 2kx used would make a big difference since the textures would only need to be in the package and not in every map that uses them. I noticed some 2k4 custom maps with custom textures in mylevel rather than a separate utx file are in the 40-50M range too.

                        I realize this is just a pre-alpha, I'm not demanding, insisting or even expecting it to change anytime soon, I'd just like to know if we can expect it will eventually change at some time in the future.
                        Last edited by MoxNix; 06-29-2015, 04:09 PM.

                        Comment

                        Working...
                        X