Thread: [Tutorial] On textures and wpoly (128, 256 or 240, which is the best?)

Page 1 of 2 12 LastLast
Results 1 to 25 of 28
  1. #1
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    [Tutorial] On textures and wpoly (128, 256 or 240, which is the best?)

    Over the years I've read many ways to improve performance and lower the wpoly, but this one was new to me. I had a hard time finding the right information, so I thought I'd post this all here for everyone to enjoy.

    So, I'm a big fan of the Nightwatch WAD that comes with SvenCo-op and I've used it a lot. It's full of nicely made high definition textures: 256x256 and even 512x512! The engine fully supports those but there's a rendering limitation that rains on our little parade: face subdivision.

    What is a face and what's subdivision?
    A face is a side of a brush you put your texture on. So a cube has 6 faces. Each face then creates a World Polygon or wpoly. Since I played nicely by the rules and put my 256x256 texture on a 256x256 face, I'd expect to be rewarded with 1 wpoly:



    What the deuce? I end up with 4poly! What's going on? Well, here's where subdivision comes into play. On scale 1,00, the engine cuts off and creates a new face (or polygon) every 240 pixels. You can see these cuts with gl_wireframe mode. I've highlighted them in red in the above screenshot. Cutting off at 240 pixels causes this texture to create 4 faces, thus creating 4wpoly.

    How to fix this?
    By shrinking the 256x256 texture to 240x240! This will prevent the cut-off from happening on the same size brush. But of course you still want to use a 256x256 brush, so you'd have to scale the texture slightly (1.067). And now our face is back to being 1 polygon as we want it to:



    As you can see there is only a small quality difference between the first and second screenshot. And imagine gaining 75% of your wpoly back for each time you apply this!

    What about 512x512?
    Due to the 240 cut-off, a 512x512 texture on a same sized brush generates 9wpoly. You could also use the same trick, but you'd have to shrink your texture to 448x448 and scale it 1.143.


    The wpoly has been fixed but the quality difference is very clear. This is why 512x512 doesn't work well for regular use in this engine. If you have to use it, then try this solution: cut it up in 4 segments and use 240x240 textures on 1.067 scale.



    There you have it, a high quality texture with only 4 poly!

    What's the best texture size?
    So, because of the game asset scales, the standard wall in HL has a height of 128 units. The Nightwatch WAD uses 256x256 textures, so you'd have to scale them down to 0.50 to make them match the wall. This looks great but, as we established, causes extra wpoly.



    Since BSP cuts off a plane every 240 units on scale 1.0, 240x240 is the perfect texture size! No-matter how much you scale it down, it will always give you back 1 wpoly!



    Of course, that applies to squares and it will definatly make a few extra cuts when you use longer walls. But as you can see from the example below, it's only a small performance loss in comparisment to 128x128 textures and a big gain compared to 256x256 textures:



    Now, if you're doing this, you need to pay close attention to the scale size! If you fit a 240 texture on a 128 unit brush, you'd end up with a scale of 0,533333333333. As you can see, that number will never round up properly. It's a tiny difference but enough for the engine to make another cut in the face. So make sure you add 1 to the 3rd decimal.



    Interestingly enough, that tiny difference puts the cut at 16px from the edge. I guess that is because of the lightmap being 16x16px and the division snaps to that lightnap grid. That probably also explains why the subdivision shifts oddly along longer faces. Endless division results (like 0.333 or 0.666) might nudge it out of the expected spot.

    Is there a downside to all this?
    Yes, there is, because of the downsizing of the renderer. It resamples and resizes textures on a scale of a power of 2 (16, 32, 64, 128, 256 and 512), always rounding off downwards. So a 240x240 texture will first be downscaled to 128x128 and then resized to its intented scale. In this process some quality is lost. Some sources claim that it's better to use 128x128 textures and scale them up yourself to make sure the engine doesn't affect the quality. Let's test that!

    Compare the first screenshot (in editor) and second (in-game):



    The 128x128 textures clearly retains it's quality and you can see the difference between 240x240 as intended and how it's handled by the engine. It has surely lost quality. But compared to eachother, the 240x240 version is still clearly the sharper texture, even with the quality loss caused by the engine.

    Conclusion
    So, in conclusion, I'd say that 240x240 textures are the most efficient mix between quality and performance. It's quite a high resolution for Goldsrc and you can scale textures down to your liking without much wpoly loss! Even with the resampling-loss, 240x240 still beats smaller texture sizes like 128x128. If you don't have to save on wpoly extremely, I'd consider changing all your smaller textures to 240 wpoly.

    It is still ok to use 256x256 textures, but we've seen how inefficient they are when it comes to the subdivision. But if you really want to go for high quality and your area can take a wpoly, then be sure to use those textures to your liking. You can even mix them up with 240x240 versions whereever you need to lower the wpoly or where players won't see them upclose. 512x512 textures should be used VERY sparingly, though.

    Misc. info:
    The amount of subdivision is connected to the scale of the texture. On 1.00 scale it cuts at 240, on 0.50 scale on 120 and on 2.00 on every 480 pixels, and so on. This is why many r_speed tutorials tell you to scale up your textures to improve the wpoly.

    If you want to optimise your wpoly, then enable 'sv_cheats' and 'developer 1' in the console. Then start a 1 player LAN server and load up your map. Write 'gl_wireframe 2' in the console and you can see the subdivisions. See if you can either change the resolution or the scale of the texture to make sure certain subdivisions are no longer made by the engine to improve wpoly.

    The subdivision can be altered by adding -subdivide # to BSP while compiling. 240 is the highest it can go without crashing, though. Setting it higher will cause RAD to crash. Faces larger than 240x240 will cause RAD to assing lightmap size greater than 16x16, and 16x16 is the hardcoded limit.
    Last edited by Hezus; Yesterday at 08:08 AM.

  2. #2
    trigger_delay & func_lazy TrEmPlEr's Avatar  
    Artist
    Join Date
    Jul 2002
    Location
    Valve Hammer Editor 3.5 beta
    Posts
    2,268

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    well, i´m speechless
    Great job on this. really usefull to some of us thanks for sharing

    here
    Modstatus: Unknown

  3. #3
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    189

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Concise and well-written tutorial, thanks Hezus.

    I vaguely recall reading once that during compiling a 'vis cut' is made every 1024 units as well (thus still giving you possibly more wpoly than you'd expect). I also believe there was a compile parameter to change that but seeing as how zhlt.info seems to be down right now, I can't look it up...

    There's one downside to the method mentioned in your tutorial though: The decrease in quality of the textures, as you already noted in the 512x512 example. Has something to do with downsampling I believe (ideally, textures should have dimensions that are powers of 2) but my knowledge is too limited to know the specifics. It has something to do with the "Quality Considerations" section of this tutorial.

    Anyway, good info!
    In-game name:


    Administrator at the ModRiotGaming servers

  4. #4
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Thanks for the comments so far!

    @GA: I also found some old info regarding the 1024 cut-off rule but I wasn't able to reproduce it. So I figured that the newer compilers somehow fixed that issue. The only thing I noticed is that (when using longer walls) the cut-off points can shift along their horizontal angle. So a 1024 wall can have 5 wploy instead of the expected 4.

    EDIT: See below for more info.
    Last edited by Hezus; 07-04-2018 at 08:13 AM.

  5. #5
    QPU-aligned Silencer's Avatar  
    Contributor
    Join Date
    May 2006
    Posts
    6,057

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Quote Originally Posted by Hezus View Post
    Make sure to use modern image rescaling such as waifu2x-multi if you are going to do this though. At least if your texture has high-contrast lines or such.

  6. #6
    Donated 15NS$ for Sven's Holiday at the Bahamas Puchi's Avatar  
    Artist
    Join Date
    Nov 2002
    Location
    Akihabara, Bochum or Sailune
    Posts
    5,586

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Oh dear, this is terrible news also to me :O
    Do it with passion, or not at all.
    Do not say everything you know. Know everything you say.
    [ MarySP ][ nacl-h2o ][ The next SC Version ♥♥♥♥ing pwns! ][Puchis Maps ]

  7. #7
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Found out a few interesting things. If you're using the scaled texture with longer brushes, something wierd happens:



    The top row are 4 separate brushes next to eachother. The most left one reacts as we'd expect but then on the 2nd brush the system starts shifting. I've measured it but it only does that once and then returns to its 240px cycle (or 256 editor units). This now creates another poly. The lower row is one long brush and also has a wierd shift that causes another face to turn up.

    On a single 256x256 face it uses the top left as an achor point for the 240px cut-off, but on longer brushes it's quite random. Judging from the examples it doesn't operate from the center either. There used to be a 1024 cut-off rule (the engine would subdivide a face every 1024 units regardlessly, starting from the world origin, 0,0,0 in editor ), but with the newer compile tools I havn't seen any effect of this supposed rule. I've also tried to move the brushes away and towards the world origin but that does not affect the anchorpoint of the face subdivision.

    I only found out 1 way to fix this issue and that's to use seperate brushes and revert the x-axis of the texture on each second brush. It works but it's a very tedious job for just 1 wpoly gain. Plus, it would only work on seamless textures where you wouldn't be able to spot the difference of the axis switch.


    As for the people using 256x256 textures now: don't panic too much! You can still use them whereever your wpoly is within limits or where a higher wpoly isn't such a problem. Now, in area's where it is important, grab your mostly used textures and convert them to 240x240. Then reinsert them in your WAD with the suffix *_cheap. Simply swap them out with their higher definition counterparts and you're good to go.

  8. #8
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    189

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    Did you manage to find out what causes that subdivide shift?

    Quote Originally Posted by Hezus View Post
    Then reinsert them in your WAD with the suffix *_cheap.
    And keep in mind that texture names longer than 15 characters are cut off.
    In-game name:


    Administrator at the ModRiotGaming servers

  9. #9
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] r_speeds: Why 256x256 and 512x512 textures are a bad idea

    I gave the face subdivision some more thought and here's some more insightful info!

    So, because of the game asset scales, the standard wall in HL has a height of 128 units. The Nighwatch WAD uses 256x256 textures, so you'd have to scale them down to 0.50 to make them match the wall. This looks great but, as we established, causes extra wpoly.



    Since BSP cuts off a plane every 240 units on scale 1.0, 240x240 is the perfect texture size! No-matter how much you scale it down, it will always give you back 1 wpoly!



    Of course, that applies to squares and it will definatly make a few extra cuts when you use longer walls. But as you can see from the example below, it's only a small performance loss in comparisment to 128x128 textures and a big gain compared to 256x256 textures:



    Now, if you're doing this, you need to pay close attention to the scale size! If you fit a 240 texture on a 128 unit brush, you'd end up with a scale of 0,533333333333. As you can see, that number will never round up properly. It's a tiny difference but enough for the engine to make another cut in the face. So make sure you add 1 to the 3rd decimal.



    Interestingly enough, that tiny difference puts the cut at 16px from the edge. I guess that is because of the lightmap being 16x16px and the division snaps to that lightnap grid. That probably also explains why the subdivision shifts oddly along longer faces. Endless division results (like 0.333 or 0.666) might nudge it out of the expected spot.

    So, in conclusion, I'd say that 240x240 textures are the most efficient mix between quality and performance. It's quite a high resolution for Goldsrc and you can scale textures down to your liking without much wpoly loss! With modern video cards you don't ever need to go extremely low on wpoly, so that would make textures smaller than 240x240 pretty much obsolete.

  10. #10
    Registered User Unq's Avatar
    Join Date
    Feb 2011
    Posts
    9

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    So I don't know if Sven works differently than normal Goldsource, but usually there is a huge difference in quality between a 240x240 texture and a 256x256. As I understand it, the engine scales down to a power of 2 and then scales back up - that is, a 240 px texture is scaled down to 128 px and then back up to 240 assuming the texture is applied at a 1.0 scale. In contrast, a 256 px texture would no go through this process since it's already a power of 2.

    This is a good study and overview of wpoly and how to optimize, although I think it should be carefully applied and the visual quality should be examined while deciding on the tradeoff.

  11. #11
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by Unq View Post
    So I don't know if Sven works differently than normal Goldsource, but usually there is a huge difference in quality between a 240x240 texture and a 256x256. As I understand it, the engine scales down to a power of 2 and then scales back up - that is, a 240 px texture is scaled down to 128 px and then back up to 240 assuming the texture is applied at a 1.0 scale. In contrast, a 256 px texture would no go through this process since it's already a power of 2.

    This is a good study and overview of wpoly and how to optimize, although I think it should be carefully applied and the visual quality should be examined while deciding on the tradeoff.
    Thanks for that info. Is that a BSP function or some rendering technique for openGL?

    But yeah, if you want to focus on the visuals in certain area's where performance isn't very important then pick 256x256 for quality. As I mentioned in the misc. info, you can create cheap 240x240 versions of your 256-textures and replace them where necessary.

    For instance, in this map I'm working on, the is a long road which used to have a 256-texture. Because of the length, the wpoly increased quickly. Since it's a road there are not that many details on it, the quality decrease it hardly noticable. Especially because it's on the floor and you'll hardly ever directly look at it. Next to that, OpenGL rendering tends to make textures fuzzier the further away they are, so visuals were going to be less interesting in that area to begin with.

  12. #12
    Registered User
    Join Date
    Mar 2012
    Posts
    501

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by Hezus View Post
    With modern video cards you don't ever need to go extremely low on wpoly
    Doesn't matter if you have quad SLI GTX Titans, the HL engine is the limiting factor with its immediate mode rendering. It starts to choke around 1000 w_poly, especially on AMD and Intel GPUs and rapidly declines in performance the higher you go from 1000 w_poly.

    Quote Originally Posted by Hezus View Post
    OpenGL rendering tends to make textures fuzzier the further away they are, so visuals were going to be less interesting in that area to begin with.
    This is a function of the HL engine's mipmap rendering, not because of an issue with OpenGL.

    You can experiment with gl_texturemode to get various rendering modes:

    GL_NEAREST
    GL_LINEAR
    GL_NEAREST_MIPMAP_NEAREST
    GL_LINEAR_MIPMAP_NEAREST
    GL_NEAREST_MIPMAP_LINEAR
    GL_LINEAR_MIPMAP_LINEAR

  13. #13
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by GiGaBiTe View Post
    Doesn't matter if you have quad SLI GTX Titans, the HL engine is the limiting factor with its immediate mode rendering. It starts to choke around 1000 w_poly, especially on AMD and Intel GPUs and rapidly declines in performance the higher you go from 1000 w_poly.



    This is a function of the HL engine's mipmap rendering, not because of an issue with OpenGL.

    You can experiment with gl_texturemode to get various rendering modes:

    GL_NEAREST
    GL_LINEAR
    GL_NEAREST_MIPMAP_NEAREST
    GL_LINEAR_MIPMAP_NEAREST
    GL_NEAREST_MIPMAP_LINEAR
    GL_LINEAR_MIPMAP_LINEAR
    Alright, cool. I'll try to experiment with those setting a bit.

    With really low wpoly I meant like 400, what used to be an acceptable wpoly back in the early days. It's ok to peak at 1000 wpoly nowadays.

  14. #14
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,418

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Hezus - Good investigation into textures and w_ploy, leading to some very interesting questions & answers.

    Just a few points to consider (NB: It been a long time/years since I investigated this area, so this info could be outdated now, not applicable or simply wrong.)

    Write 'gl_wireframe 2' in the console and you can see the subdivisions.
    - Better to start with gl_wireframe 1 for this, since mode '2' will additionally draw "things behind" the wall you are looking at. (Player and engine views are different.) Then once you sort out the "player visuals and w_poly" move to gl_wireframe 2 (This tutorial is about "textures into w_poly", so you also do want to know the "what engine sees" because you probably want to vis-block/hide "other rooms". [For any newbies reading this, look/search for a "vis-blocking tutorial" for how to do this.])

    The engine fully supports those but there's a rendering limitation ...
    True we have engine support but compiler & wads also effect things:
    AFAIR:
    The maximum "texture size" (HL original wads) was 128x128.
    Specific "Naming conventions" inside wads were used to allow different treatment engine side.
    So recommend: Everyone use the latest "VL or SC-SDK compile tools", and be careful of "badly named textures".

    240x240 pixels (scale up & down etc.) Caution this is "a vague memory" but - Possibly/maybe the reason for this is due to "regularly tiling textures", I seem to remember that the aim was to "blur merge" and "smooth the join" edges for such textures.

    [EDIT New Info. Correction, 240 is used when tiling does not occur, 224 is used for Tiling. See Post #20]
    (i.e. It builds a side by side map of brushes and then looks at the textures. If adjoining brushes have similar texture names [ i.e. start with same name plus 0->9 or A->Z], then it Scales up to 240, Takes 16 pixels on each joining edge of the 240, blurs both 16 pixel edges, sharpens by scaling back down or creates a 8 pixel overlay or something, [Seem to remember ideas was to make the 16 pixels (per side edge) into 8 pixels (per side edge) somehow and thereby create "Seamless Joins"] -> If that is correct(ish)128 pixels textures will act differently to other sizes.
    [End EDIT]

    IDK if the nw.wad(s), follow the same naming conventions, as the "standard HL wads" or what has been done engine side and compiler side to avoid "un-necessary processing".) For example: I know that when I build my own wad files and name the textures, brown_wall1 and brown_wall2 are often completely different textures and not meant to be joined.
    In contrast see: HalfLife.wad "out_wall7" plus out_wall7A->E [all 96x128 pixels] which are the same wall but with slightly "different permanent decals?" and hence intended to be seamlessly joined.

    The 240 pixel lines drawn in gl_wireframe: "Brush size guide" or "pixel/texture scaling guide" ? IDK
    There Might be more than one 240 function going on here (i.e. Max expected Brush size merge with Max. expected texture stretch).
    For Clarity and so as to avoid confusion: Logically what you see "scale and texture wise" is what is what everyone should see in game (you are after all already "in game"), thus the "240 cuts shown" in gl_wireframe should be used to fix/adjust w_poly problems rather than texture scale issues.)

    @GiGaBiTe - Thanks for the gl_texturemode info. / Never knew about that. (If I ever get the time I will also experiment.)
    Last edited by wolf-3d; Yesterday at 07:11 AM. Reason: New Info. see Post #20
    Regards
    Wolf-3D

  15. #15
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,393

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Not sure if related, but the default face subdivide for the BSP compiler is 240. Has anyone tried using this option using 128 or 256 instead?

    Use the "-subdivide" option for SC-BSP/HLBSP and see if that makes a difference.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  16. #16
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by wolf-3d View Post
    True we have engine support but compiler & wads also effect things:
    AFAIR:
    The maximum "texture size" (HL original wads) was 128x128.
    Specific "Naming conventions" inside wads were used to allow different treatment engine side.
    So recommend: Everyone use the latest "VL or SC-SDK compile tools", and be careful of "badly named textures".

    240x240 pixels (scale up & down etc.) Caution this is "a vague memory" but - Possibly/maybe the reason for this is due to "regularly tiling textures", I seem to remember that the aim was to "blur merge" and "smooth the join" edges for such textures.
    (i.e. It builds a side by side map of brushes and then looks at the textures. If adjoining brushes have similar texture names [ i.e. start with same name plus 0->9 or A->Z], then it Scales up to 240, Takes 16 pixels on each joining edge of the 240, blurs both 16 pixel edges, sharpens by scaling back down or creates a 8 pixel overlay or something, [Seem to remember ideas was to make the 16 pixels (per side edge) into 8 pixels (per side edge) somehow and thereby create "Seamless Joins"] -> If that is correct(ish)128 pixels textures will act differently to other sizes.

    IDK if the nw.wad(s), follow the same naming conventions, as the "standard HL wads" or what has been done engine side and compiler side to avoid "un-necessary processing".) For example: I know that when I build my own wad files and name the textures, brown_wall1 and brown_wall2 are often completely different textures and not meant to be joined.
    In contrast see: HalfLife.wad "out_wall7" plus out_wall7A->E [all 96x128 pixels] which are the same wall but with slightly "different permanent decals?" and hence intended to be seamlessly joined.
    This is really interesting. We should test that naming rule and see if it really affects the cuts of the face subdivision. If it works you could save on wpoly in certain cases. As for the limitation in the HL.wad: I'm pretty sure there are a few textures surpassing the 128 pixel limit.

    @AdamR: You can -subdivide lower but that would just mostly increase wpoly. Setting it any higher than 240 you'll most likely crash RAD. I suspect this is because of the lightmap not being able to handle that. A 256 pixel division would have been great and far more practical.

    In general it would be really cool to find some indepth documentation about Goldsource's render techniques or someone who knows the ins and outs. So far I've been just scraping bits of information together.

  17. #17
    Registered User
    Join Date
    Apr 2018
    Posts
    2

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Thanks for sharing

  18. #18
    Administrator AdamR's Avatar  
    Manager
    Join Date
    Mar 2004
    Location
    Cardiff, South Wales [uk]
    Posts
    8,393

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by Hezus View Post
    @AdamR: You can -subdivide lower but that would just mostly increase wpoly. Setting it any higher than 240 you'll most likely crash RAD. I suspect this is because of the lightmap not being able to handle that. A 256 pixel division would have been great and far more practical.
    Maybe RAD can be updated to handle slightly larger light surfaces. Not sure what reason a 240 limit would have been imposed.
    Adam "Adambean" Reece
    Sven Co-op team

    Also on: Steam | Facebook | Twitter | YouTube | Twitch
    Released AMXX plug-ins: Bind number slots | NextMap with Sven Co-op fix | Sven Co-op administrator icons

  19. #19
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by AdamR View Post
    Maybe RAD can be updated to handle slightly larger light surfaces. Not sure what reason a 240 limit would have been imposed.
    That would be great but afaik it's hardcoded to 16x16. But since we own the code now, maybe there are possibilities.

    The 240 limit seems odd to me, too. Maybe the limit is virtually 256 but it allocates 16 units for something else? That would then push it over the edge.

  20. #20
    Still learning wolf-3d's Avatar  
    Tester
    Join Date
    Jan 2011
    Location
    Somewhere Warm.
    Posts
    1,418

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    In general it would be really cool to find some indepth documentation about Goldsource's render techniques ...
    Found some info (Cut and pasted, the "R_Speeds" bit in case the link ever goes down).

    "R_speeds
    There have been discussions about the 240/224 subdivide on faces to create wpolys, and how using a 224x224 or 240x240 texture scaled up to 256x256 can keep wpolys low with minimal stretching. That is true, a 224x224 or 240x240 size texture scaled up to fit a 256x256 brush will create less wpolys than a 256x256 texture unscaled.
    HOWEVER texture quality suffers as mentioned above - the engine resamples at 128x128, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. You may as well start with a 128x128 texture of good quality - remember 128x128 stays sharp looking - and stretch that to fit 256x256. (Btw, the 240 subdivide is used by the engine when there is not tiling, the 224 is used with tiling textures.)
    Moreover, rarely indeed will the few polys difference of using a 240/224 texture vs a 256 make or break a level's playability. If things are that tight, the whole map needs to be rethought.....

    If you are facing the problem of minimizing wpolys in a wide open area, stretching/scaling 9x is about the limit of the engine, more causes problems and errors. If you stretch a 256x256 texture 9x then the 224 subdivide will also be stretched 9x = a wpoly of 2016x2016. That is about the maximum wpoly you can have - regardless of what texture size you use. 9x (224x224) = 2016x2016, 9x (128x128) = 2016x2016, 9x (16x16) = 2016x2016 subdivide/wpoly size. The only difference is how many times the smaller textures will tile within that 2016.
    That is one of the vital things to realize. Texture sizes do not control the subdivide per se. A 16x16 will not make wpolys 16x16 if it is not stretched. Instead it will make the wpoly at the brush size or 224, whichever is smaller. It is texture stretching which stretches (or shrinks) the subdivide - not the texture size!

    note: to get the full effect of the 2016x2016 on the ground, you will also have to increase the maxnodesize in BSP compile from the default 1024 to 2048. HLBSP -maxnodesize 2048 is the command you need. However, be aware that changing the maxnodesize for leafnodes on ALL maps is NOT a good thing. On smaller maps, or maps with lots of corridors and no large open space it may INCREASE your r_speeds and lag, because the leafnodes will "see" more wpolys. For such maps DECREASING maxnodesize from 1024 down to 512 can reduce wpolys, sometimes. One needs to experiment to find the best mode - but all this is for compile experts. Finally, the maxnodesize does not really affect walls much, so if you are building a skyscraper you can pretty much ignore it.

    note2: the subdivide CAN be changed up from 240 to say 256. This will allow 1 wpoly for a 256x256 texture on a 256x256 brush face. The problem is that software video mode does NOT allow subdivide to be changed, so NO software video mode user can play your level. Also you cannot decrease subdivide below 240. Finally some compilers do not allow subdivide to be changed, and you will get a "bad surface extents" error during compile. But if you want to experiment, HLBSP -subdivide 256 is the command you need.


    More on lag and scaling relating to patches
    There is another matter you should be aware of. On older video cards like Voodoos, scaling down below 1.0 had worse effects for lag than you would expect from the additional wpolys. (example: voodoo3 didn't have hardware transformation and lighting.) Firebinder did some research and found that scaling down also affected the patches used by lighting up a level, so that fps (frames per second rate) dropped even when the wpoly count was not changing.
    Therefore when using a small brush, it is better to use a small texture and scale up, than to scale down a larger one. Even with the same wpoly count, the down scale might lead to lag on some players with older video cards or who are still using software mode.

    However, there is another way to deal with the problem besides only scaling up textures: HLRAD -notexscale. This stops the compiler from basing the patch sizes on the texture scale. But this -notexscale usually increases the number of patches in a map, as most maps have many walls scaled up 2x or 3x or even 9x to reduce r_speeds - as described above. So if you are shrinking textures/scaling down and having patches problems/lag in an area with an older video card/software mode, then experiment with -notextscale - but do not use it automaticly all the time.
    Furthermore do not forget HLRAD -sparse can also help with too many patches, even if the compile will be slower.

    BTW: You might think of shrinking textures down on purpose for more patches on a textures, hoping for better lighting. There are better ways to control patches:
    HLRAD -texchop # and HLRAD -extra to control texture "light giving" patches sizes, (default TEXCHOP is 32x32 x texture scale, unless -notextscale is on, and default EXTRA is 1/2 texchop/16x16 respectively. But EXTRA may do more than just 1/2 the texchop!);
    and HLRAD -chop # to control the size of general "lighted on" patches. (64x64 x texture scale is the CHOP default, unless -notextscale is on, in which case default is 64x64 only.) FYI: Chop larger than 96 generally looks poor.

    The combination of HLRAD -notexscale -sparse -texchop 16 -extra -chop 32 can be especially handy for lighting a level extra fine, but will be a slow compile due to the many, many extra patches."

    Not sure what reason a 240 limit would have been imposed.
    It appears it was due to a "Memory Constraint" (in/around 1999 era).
    "The larger the dimensions the more memory required. 256x256 takes 4x the memory of 128x128"

    Additional Information and Original Source: http://www.slackiller.com/tommy14/tex-dimensions.htm
    Regards
    Wolf-3D

  21. #21
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Really nice find Wolf!

    That site also sheds some light on the 240 unit subdivide. It reserves 8 px on the left and 8px on the right for the wrap-around method.

    Why is the max subdivide size 240, and not 256? Well, there is a very good reason for this.

    In software mode the world is split up into squares. As you move closer to a surface you see the squares get bigger. Quality suffers.

    In hardware mode, no matter how close you are to a surface it will always appear smooth. This smooth transition between pixel values is done by sampling the neighbourhood pixels and calculating an average at each point.

    The problem is what happens at the texture edges. The hardware uses a wrap-around method, so that the left edge pixels are influenced by the values of the right edge pixles, and vice versa. This explains the 'dirty border effect' you sometimes see at corners/edges in hardware mode, because left and right border pixels have no relation to eachother, but are still used in the same computation.

    It is to get rid of this effect that the subdivide size is 240. It means that you can have a 256x256 texture with an unused 8 pixel border all around. This left border area will contain the right border values and vice versa (same for the top and bottom edges).

    Of course, those that make textures tile, where the texture itself has border values that are the same on each side, will find the extra 8 pixel border unnecessary. But if you use non-tileable textures that must fit together (like a large surface covered with a set of textures that all come from the same image), then this unused 8 pixel border is very useful. It will contain the overlapping values.

    (That 8 pixel border is problably also the reason why 16 is the minimum texture border size.)
    I'll update the tutorial on the resizing issue later. Seems important enough to mention!

  22. #22
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    189

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by wolf-3d View Post
    Additional Information and Original Source: http://www.slackiller.com/tommy14/tex-dimensions.htm
    Ahh perfect, I remember this! Even have it in my bookmarks.

    On a different page of that same website, I found the (possibly outdated) info that BSP makes a default viscut every 1024 units: http://www.slackiller.com/tommy14/rspeeds.htm

    Edit: Also from that page (something I tried to explain earlier, Unq did a better job a few posts later though):
    "There have been discussions about [...] how using a 224x224 or 240x240 texture can keep wpolys low with minimal stretching.
    This is true, but texture quality still suffers - the engine resamples the 224 or 240 at 128x128, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. So resizing the texture to 224x224 or 240x240 does not make much of a difference in Wpolys, and causes severe losses of texture quality."
    In-game name:


    Administrator at the ModRiotGaming servers

  23. #23
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] Why 256 and 512 textures are bad and 240 is the ideal texture size

    Quote Originally Posted by Green Astronauts View Post
    Edit: Also from that page (something I tried to explain earlier, Unq did a better job a few posts later though):
    "There have been discussions about [...] how using a 224x224 or 240x240 texture can keep wpolys low with minimal stretching.
    This is true, but texture quality still suffers - the engine resamples the 224 or 240 at 128x128, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. So resizing the texture to 224x224 or 240x240 does not make much of a difference in Wpolys, and causes severe losses of texture quality."
    Did a test of this claim!




    First shot is the intented quality in-editor and second shot is the rendered result in-game. 240x240 surely looses some quality but still comes out on top over the scaled 128x128 texture, imho. It surely isn't "severe losses of texture quality" as stated on that website.

  24. #24
    snarks snarks snarks snarks snarks snarks snarks snarks Green Astronauts's Avatar
    Join Date
    Mar 2013
    Location
    Nijmegen, the Netherlands
    Posts
    189

    Re: [Tutorial] On textures and wpoly (128, 256 or 240, which is the best?)

    Loss of quality isn't that bad indeed but I guess the 240x240 texture was supposed to be compared to a 256x256 texture, not a 128x128 one.
    In-game name:


    Administrator at the ModRiotGaming servers

  25. #25
    Super moderator Hezus's Avatar
    Join Date
    Aug 2001
    Location
    The Netherlands
    Posts
    8,895

    Re: [Tutorial] On textures and wpoly (128, 256 or 240, which is the best?)

    Quote Originally Posted by Green Astronauts View Post
    Loss of quality isn't that bad indeed but I guess the 240x240 texture was supposed to be compared to a 256x256 texture, not a 128x128 one.
    Well, from that source the author says: "You may as well start with a 128x128 texture of good quality", but I would say that doesn't hold up compared to what a 240x240 texture can do.

    But if you want to ensure quality, you'd obviously have to go with the 256x256 texture. But I still stand by my point that 240 is the best mix between quality and performance.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •