KungFuSquirrelBasher of MuttonsJoin Date: 2002-01-26Member: 103Members, NS1 Playtester, Contributor
edited March 2003
Ugh. Yes, I'm sure it's a myth. I'm surprised you aren't sure - you disproved it with your own post!
Yes, faces split. Do they split according to the texture's border? <b>no</b>. Do they split into triangles for HL purposes? <b>no</b>.
Face splits come at every 240 or 224 units * texture scale. If you have a 512x512 face and scale a 128x128 texture to fit, it'll be 1 wpoly. If you put the same 128x128 texture at a scale of 1, the faces will NOT split every 128 units as is (for reasons beyond my comprehension) commonly believed. It instead will wrap across almost 2 full times before the first face split, and then continue at that interval until the face intersects something else. This is also why a 256x256 texture on a 256x256 face creates 4 wpoly - there's 1 240x240 poly, then on two of the edges 2 more wpolys, 16x240 and 240x16, and then a fourth in the corner where those previous two intersect, 16x16.
This has been demonstrated, proven, discussed, debated, confirmed, and written about at about every editing site known to man, yet the incorrect information and assumptions about poly split behavior are still out there. It's mind-boggling.
KungFuSquirrelBasher of MuttonsJoin Date: 2002-01-26Member: 103Members, NS1 Playtester, Contributor
Well, no. The lightmaps are notably smaller than the BSP face splits. Default patch size is 64x64 compared to 240x240 for a single face. I shudder to think what a map would look like with a -chop value of 240. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
But the smaller the patch size, the sexier the lighting.. although it would take a friggin long time to run RAD <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
<!--QuoteBegin--KungFuSquirrel+Mar 31 2003, 06:14 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (KungFuSquirrel @ Mar 31 2003, 06:14 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Well, no. The lightmaps are notably smaller than the BSP face splits. Default patch size is 64x64 compared to 240x240 for a single face. I shudder to think what a map would look like with a -chop value of 240. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Actually, the lightmaps <i>are</i> what cause the splits where they do.
Specifically a combination of support for software rendering and making sure lightmaps have a multi-pixel 'border' (one pixel when the lightmaps are rescaled down to 16x16) that can be used to guarantee that 'wrap-around' errors in filtering and mipmapping don't occur. Anyone that's worked with 3D hardware accelerators much should be familiar with the hazards of trying to use non-tileable textures anywhere. This 'filtering error' is also where the well-known 'lines' on skyboxes come from in many game engines as well, for instance.
Ok so am I correct in assuming the 240 limit comes from
min_patch_size * (max_lightmap_size - 1)
or
16 * (16 - 1) = 240
thus assuring a poly never spans more than one lightmap? Would it be safe to raise this limit in hlbsp provided the patch size was raised proportionally?
would these quotes relate? <!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <b>FYI: Why is the max subdivide size 240?</b> Originally by Rhett on the ERC forums. <i>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. </i> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> (That 8 pixel border is probably also the reason why 16 is the minimum texture border size.)
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <b>FYI: Why tiling makes wpolys occur at (224 x texture scale) instead of (240 x texture scale)?</b> Originally by Merl on the ERC forums. <i> From the code in the zhlt source the formulae for subdivisions basically boils down to the following line of code:
plane.dist = (mins + g_subdivide_size - 16) / v;
that is, basically, the subdivide size minus 16. Do the math on 240 - 16, and you get 224. </i>
(Zoner is also reported to have said that too many 240x240 wpolys may cause some wpolys to not appear, later in that same thread.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Comments
<img src='http://silencegreys.com/sa/wpoly1.jpg' border='0' alt='user posted image'>
As you would expect, 6 wpolys.. one for each wall of the cube. Here is the same map with textures half the scale:
<img src='http://silencegreys.com/sa/wpoly2.jpg' border='0' alt='user posted image'>
24 wpolys.. 4 for each wall. Also, the wireframe lines clearly show that the walls are being divided.
Yes, faces split. Do they split according to the texture's border? <b>no</b>. Do they split into triangles for HL purposes? <b>no</b>.
Face splits come at every 240 or 224 units * texture scale. If you have a 512x512 face and scale a 128x128 texture to fit, it'll be 1 wpoly. If you put the same 128x128 texture at a scale of 1, the faces will NOT split every 128 units as is (for reasons beyond my comprehension) commonly believed. It instead will wrap across almost 2 full times before the first face split, and then continue at that interval until the face intersects something else. This is also why a 256x256 texture on a 256x256 face creates 4 wpoly - there's 1 240x240 poly, then on two of the edges 2 more wpolys, 16x240 and 240x16, and then a fourth in the corner where those previous two intersect, 16x16.
This has been demonstrated, proven, discussed, debated, confirmed, and written about at about every editing site known to man, yet the incorrect information and assumptions about poly split behavior are still out there. It's mind-boggling.
But the smaller the patch size, the sexier the lighting.. although it would take a friggin long time to run RAD <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Actually, the lightmaps <i>are</i> what cause the splits where they do.
Specifically a combination of support for software rendering and making sure lightmaps have a multi-pixel 'border' (one pixel when the lightmaps are rescaled down to 16x16) that can be used to guarantee that 'wrap-around' errors in filtering and mipmapping don't occur. Anyone that's worked with 3D hardware accelerators much should be familiar with the hazards of trying to use non-tileable textures anywhere. This 'filtering error' is also where the well-known 'lines' on skyboxes come from in many game engines as well, for instance.
min_patch_size * (max_lightmap_size - 1)
or
16 * (16 - 1) = 240
thus assuring a poly never spans more than one lightmap? Would it be safe to raise this limit in hlbsp provided the patch size was raised proportionally?
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
<b>FYI: Why is the max subdivide size 240?</b>
Originally by Rhett on the ERC forums.
<i>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. </i>
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
(That 8 pixel border is probably also the reason why 16 is the minimum texture border size.)
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
<b>FYI: Why tiling makes wpolys occur at (224 x texture scale) instead of (240 x texture scale)?</b>
Originally by Merl on the ERC forums. <i>
From the code in the zhlt source the formulae for subdivisions basically boils down to the following line of code:
plane.dist = (mins + g_subdivide_size - 16) / v;
that is, basically, the subdivide size minus 16. Do the math on 240 - 16, and you get 224. </i>
(Zoner is also reported to have said that too many 240x240 wpolys may cause some wpolys to not appear, later in that same thread.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->