Normal maps can't handle LoD properly; you need to generate a different normal map for each LoD.
The normal map is generated by making a very high definition model and using that as a template; you trace a bunch of rays along the normal of the low definition(ingame) model and store the normal of the surface they hit on the high definition model in the corresponding pixel in UV(texture) space of the low definition model.
The format of the stored normal is a coordinate in tangential space(since it's normalized, you only need the coordinates in the tangential and binormal directions to reconstruct the full normal, since the length must be one, but you need some additional math in the pixel shader if you omit the coordinate in the normal direction).
Tangential space is the space spanned by the vertex tangent, binormal and normal, interpolated between the vertices that make up a triangle; the basis vectors will be different if you omit a bunch of vertices so the specular and lighting effects will be different. I'm not sure just how bad it will look, but it could potentially look very bad under some circumstances.
<!--quoteo(post=1822918:date=Jan 9 2011, 01:53 PM:name=sypro)--><div class='quotetop'>QUOTE (sypro @ Jan 9 2011, 01:53 PM) <a href="index.php?act=findpost&pid=1822918"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But Spark completely handles occlusion culling yeah? I mean you don't have to cut up your map manually as a mapper.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, you don't have to add any hint brushes or sillyness like that, but obviously you still need to take steps to accomodate occlusion culling as a mapper. If you can see from room A to room B, C, D, E, F and G then obviously room B, C, D, E, F and G must be rendered whenever they are in view.
<!--quoteo(post=1822917:date=Jan 9 2011, 06:52 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Jan 9 2011, 06:52 PM) <a href="index.php?act=findpost&pid=1822917"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Normal maps can't handle LoD properly; you need to generate a different normal map for each LoD.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm pretty sure this is not correct. AFAIK, as long as the lower LOD models keep the same UV layout (which they have to, in order to use the same texture map as the original model), the original normal bump will look fine.
<!--quoteo(post=1823024:date=Jan 9 2011, 07:59 PM:name=zex)--><div class='quotetop'>QUOTE (zex @ Jan 9 2011, 07:59 PM) <a href="index.php?act=findpost&pid=1823024"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->AFAIK, as long as the lower LOD models keep the same UV layout (which they have to, in order to use the same texture map as the original model), the original normal bump will look fine.<!--QuoteEnd--></div><!--QuoteEEnd-->
This is correct. In fact, one popular method of generating normal maps is actually to create a very high poly, sculpted version of the model first and then bake that model's details onto a normal map for a lower-poly, playable version.
<!--quoteo(post=1823069:date=Jan 10 2011, 07:08 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Jan 10 2011, 07:08 AM) <a href="index.php?act=findpost&pid=1823069"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->This is correct. In fact, one popular method of generating normal maps is actually to create a very high poly, sculpted version of the model first and then bake that model's details onto a normal map for a lower-poly, playable version.<!--QuoteEnd--></div><!--QuoteEEnd-->
what the guy i replied to was saying is that normal bump is calculated relative to the lower poly version's normals ("tangent space" refers to the orientation of the low poly's faces). So technically when you change the lower poly geometry, the normal map will be less mathematically "accurate," but in practice it doesn't make any difference in a LOD model since loss of detail is expected.
<!--quoteo(post=1823070:date=Jan 10 2011, 12:19 AM:name=zex)--><div class='quotetop'>QUOTE (zex @ Jan 10 2011, 12:19 AM) <a href="index.php?act=findpost&pid=1823070"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->what the guy i replied to was saying is that normal bump is calculated relative to the lower poly version's normals ("tangent space" refers to the orientation of the low poly's faces). So technically when you change the lower poly geometry, the normal map will be less mathematically "accurate," but in practice it doesn't make any difference in a LOD model since loss of detail is expected.<!--QuoteEnd--></div><!--QuoteEEnd-->
I know the difference between normal and tangent space mapping. I was just pointing out that the same principle that makes baking normals onto lower poly models possible as a normal mapping technique also holds true for LOD work. Because (like you said) it's normal space, the same map will continue to work on models of similar size and roughly similar shape. Unless the LOD model is severely deformed, normal space ensures that the map will continue to function.
That's why normal maps are so great to begin with -- they simulate high detail on low-polygon models. Obviously you have to keep the same UV layout.
<!--quoteo(post=1823072:date=Jan 10 2011, 07:53 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Jan 10 2011, 07:53 AM) <a href="index.php?act=findpost&pid=1823072"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I know the difference between normal and tangent space mapping.<!--QuoteEnd--></div><!--QuoteEEnd-->
ehhhhhhhh i think both you and the other guy have probably read something about it in a gaming magazine or something and think you know what you're talking about. There is no "difference between normal and tangent space mapping," that statement makes no sense. "Tangent-space normal mapping" is a method of rendering normal maps based on polygon tangents. Normal maps can also be rendered in world-space and object-space but this isn't as useful for games.
Again, the other dude is saying that by altering the geometry in a LOD model, you alter the polygon tangents, and therefore the original basis that the normal map uses is no longer valid. This is correct in theory but the difference isn't noticeable in practice especially considering that LOD's are only meant to be viewed at a distance.
<!--QuoteBegin-zex+--><div class='quotetop'>QUOTE (zex)</div><div class='quotemain'><!--QuoteEBegin-->AFAIK, as long as the lower LOD models keep the same UV layout (which they have to, in order to use the same texture map as the original model), the original normal bump will look fine.<!--QuoteEnd--></div><!--QuoteEEnd-->
It should look fine if your adjacent triangles point in nearly the same direction and are nearly the same size. That's not a general case; in the general case T, B and N vectors may end up quite different at the same texel in the UV map for different LoD models.
<!--quoteo(post=1823069:date=Jan 10 2011, 02:08 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Jan 10 2011, 02:08 AM) <a href="index.php?act=findpost&pid=1823069"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In fact, one popular method of generating normal maps is actually to create a very high poly, sculpted version of the model first and then bake that model's details onto a normal map for a lower-poly, playable version.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I specifically mentioned this. This exactly tailors the normal map for the T, B and N vectors expected at that texel when using that level of detail. If you were to repeat normal map generation using the same high detail reference model but with a lower LoD model as the target, the normal map would be almost identical over large regions, but not everywhere.
It's not at all clear to me that there wouldn't be places where it would look noticably bad.
<!--quoteo(post=1823077:date=Jan 10 2011, 08:25 AM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Jan 10 2011, 08:25 AM) <a href="index.php?act=findpost&pid=1823077"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It's not at all clear to me that there wouldn't be places where it would look noticably bad.<!--QuoteEnd--></div><!--QuoteEEnd-->
Just stop, dude. You've clearly read the wikipedia page on "normal mapping" and are coming to incorrect conclusions based on what you read. Yes, changing the tangents means the normal map is mathematically "incorrect," but the difference would not be significant at all in the scenario we're talking about.
You could just as easily say that the original texture map will not be valid for the LOD model, because there will be texture stretching if polygons are altered and you might introduce new seams by changing geometry. Which is equally true and equally irrelevant, because both the texture and the normal map will look adequate at the distance that LODs are rendered and (optimally) the loss in quality won't even be noticeable.
You can even disable normal map in such cases. Vertex shader probably already computes tangent space and pixel shader cost of LODed model is already low (few pixels) so it might be simpler to just have the same shader combo even if normal map vs no normal map makes no difference.
BTW it's normal, tangent and bitangent not binormal. Look up Wolfram. (Microsoft didn't)
Anyway back to graphics: I think I saw Max mentioning LPVs somewhere. I'm curious if it gets added to NS2. At the moment it seems to be using very primitive 0 bounce dynamic lighting. It's all bright, shiny and unnatural. I'm not sure if LPVs were used in any commercially released game (Crysis 2 isn't there yet).
There also seems to be an issue with aliasing of specular component. I might be seeing things that are not there though.
<!--quoteo(post=1823097:date=Jan 10 2011, 10:55 AM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Jan 10 2011, 10:55 AM) <a href="index.php?act=findpost&pid=1823097"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->For someone who is amazed at the workings of a collision box on models, you have a lot of "knowledge" here zex.<!--QuoteEnd--></div><!--QuoteEEnd-->
you mean someone who is amazed that nobody on this forum is able to answer the simple question "how does collision work in Spark?" Or are you trolling? Or are you seemingly surprised at the idea that someone who knows how to create normal-mapped models would not magically know how an engine with no documentation works? My money is on trolling.
McGlaspiewww.team156.comJoin Date: 2010-07-26Member: 73044Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester
<!--quoteo(post=1823085:date=Jan 10 2011, 03:58 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Jan 10 2011, 03:58 AM) <a href="index.php?act=findpost&pid=1823085"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Anyway back to graphics: I think I saw Max mentioning LPVs somewhere. I'm curious if it gets added to NS2. At the moment it seems to be using very primitive 0 bounce dynamic lighting. It's all bright, shiny and unnatural. I'm not sure if LPVs were used in any commercially released game (Crysis 2 isn't there yet).<!--QuoteEnd--></div><!--QuoteEEnd-->I can't speak on the details, but recall reading Spark does not calculate any light bounce / radiosity. It's part of its deferred rendering pipeline and how it uses the typical G-buffer in the lighting process as "volumes" of light. Multiple lights can be applied to a surface but it does bounce to any other surfaces. Basically a single pass lighting method (yes, I know..that's not technically accurate).
<!--quoteo(post=1823104:date=Jan 10 2011, 11:35 AM:name=McGlaspie)--><div class='quotetop'>QUOTE (McGlaspie @ Jan 10 2011, 11:35 AM) <a href="index.php?act=findpost&pid=1823104"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Multiple lights can be applied to a surface but it does bounce to any other surfaces. Basically a single pass lighting method (yes, I know..that's not technically accurate).<!--QuoteEnd--></div><!--QuoteEEnd--> I don't understand what "it does bounce to any other surfaces" mean. Light bounce is about light hitting 1st surface on its way, bouncing from it and hitting another. For instance precomputed radiosity in Source does around 50 bounces and Crysis 2 tries to simulate 1 in real-time.
Deferred has not much to do with it. Applying lights in screen space doesn't make anything easier. If anything I'd expect that this optimization would be invalid with anything simulating bounce(s).
<!--quoteo(post=1823119:date=Jan 10 2011, 02:17 PM:name=McGlaspie)--><div class='quotetop'>QUOTE (McGlaspie @ Jan 10 2011, 02:17 PM) <a href="index.php?act=findpost&pid=1823119"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ahhh the semantics responses. Love it.<!--QuoteEnd--></div><!--QuoteEEnd-->
OT: I don't like that post with 1 line of text has height as if it had 20 due to info about author on the left side.
You can spend hours "discussing" topic with different definitions arguing without understanding each other. Every real discussion starts with definition and semantics. :)
Almost every gameplay/balance discussion makes no sense because people don't understand each other.
<!--quoteo(post=1823119:date=Jan 10 2011, 01:17 PM:name=McGlaspie)--><div class='quotetop'>QUOTE (McGlaspie @ Jan 10 2011, 01:17 PM) <a href="index.php?act=findpost&pid=1823119"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ahhh the semantics responses. Love it.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah there's four or five different people that have sprouted up on the forums as of late which are as I put it, arguing the toss for arguments sake. Either that or they're still at school and have ADHD, however they seem "too smart" to still be at school or have the Google skills of a King.
<!--quoteo(post=1822917:date=Jan 9 2011, 05:52 PM:name=Soylent_green)--><div class='quotetop'>QUOTE (Soylent_green @ Jan 9 2011, 05:52 PM) <a href="index.php?act=findpost&pid=1822917"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Normal maps can't handle LoD properly; you need to generate a different normal map for each LoD.
The normal map is generated by making a very high definition model and using that as a template; you trace a bunch of rays along the normal of the low definition(ingame) model and store the normal of the surface they hit on the high definition model in the corresponding pixel in UV(texture) space of the low definition model.
The format of the stored normal is a coordinate in tangential space(since it's normalized, you only need the coordinates in the tangential and binormal directions to reconstruct the full normal, since the length must be one, but you need some additional math in the pixel shader if you omit the coordinate in the normal direction).
Tangential space is the space spanned by the vertex tangent, binormal and normal, interpolated between the vertices that make up a triangle; the basis vectors will be different if you omit a bunch of vertices so the specular and lighting effects will be different. I'm not sure just how bad it will look, but it could potentially look very bad under some circumstances.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually you can also just run a photoshop filter over your texture, which is what you usually do for stuff like rocks because trying to actually model rocks at high detail to render a normal from them is nigh impossible.
Ah, but the most important questions remain: who has the biggest epeen in uv space? Is the normal map not sufficient to render it properly? Or, are the texels too large at LOD-0?
McGlaspiewww.team156.comJoin Date: 2010-07-26Member: 73044Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester
<!--quoteo(post=1823137:date=Jan 10 2011, 10:57 AM:name=juice)--><div class='quotetop'>QUOTE (juice @ Jan 10 2011, 10:57 AM) <a href="index.php?act=findpost&pid=1823137"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ah, but the most important questions remain: who has the biggest epeen in uv space? Is the normal map not sufficient to render it properly? Or, are the texels too large at LOD-0?<!--QuoteEnd--></div><!--QuoteEEnd-->LOL I don't think a rendering method has been invented that can handle some of the epeens on this forum =P
j/k j/k Hey, sometimes we have to make fun of ourselves.
<!--quoteo(post=1822839:date=Jan 9 2011, 08:39 AM:name=BAshh)--><div class='quotetop'>QUOTE (BAshh @ Jan 9 2011, 08:39 AM) <a href="index.php?act=findpost&pid=1822839"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've developed content for games. What I mean is I've done my own small scale non-definitive tests on LOD's vs no LOD's and noticed no tangible difference. Thanks for playing though.<!--QuoteEnd--></div><!--QuoteEEnd--> Well then, I misunderstood. Looks like I also forgot to fini
<!--quoteo(post=1822767:date=Jan 9 2011, 12:08 AM:name=-Diesel-)--><div class='quotetop'>QUOTE (-Diesel- @ Jan 9 2011, 12:08 AM) <a href="index.php?act=findpost&pid=1822767"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Honestly.. Just buy new computers.
If you are serious about video games then you should have a computer that can atleast run NS2.
This game isn't crysis or anything, don't ask the developers to dumb the games down so people who are too cheap to buy a comp can play it without lag.<!--QuoteEnd--></div><!--QuoteEEnd-->
Comments
The normal map is generated by making a very high definition model and using that as a template; you trace a bunch of rays along the normal of the low definition(ingame) model and store the normal of the surface they hit on the high definition model in the corresponding pixel in UV(texture) space of the low definition model.
The format of the stored normal is a coordinate in tangential space(since it's normalized, you only need the coordinates in the tangential and binormal directions to reconstruct the full normal, since the length must be one, but you need some additional math in the pixel shader if you omit the coordinate in the normal direction).
Tangential space is the space spanned by the vertex tangent, binormal and normal, interpolated between the vertices that make up a triangle; the basis vectors will be different if you omit a bunch of vertices so the specular and lighting effects will be different. I'm not sure just how bad it will look, but it could potentially look very bad under some circumstances.
Yes, you don't have to add any hint brushes or sillyness like that, but obviously you still need to take steps to accomodate occlusion culling as a mapper. If you can see from room A to room B, C, D, E, F and G then obviously room B, C, D, E, F and G must be rendered whenever they are in view.
I'm pretty sure this is not correct. AFAIK, as long as the lower LOD models keep the same UV layout (which they have to, in order to use the same texture map as the original model), the original normal bump will look fine.
This is correct. In fact, one popular method of generating normal maps is actually to create a very high poly, sculpted version of the model first and then bake that model's details onto a normal map for a lower-poly, playable version.
what the guy i replied to was saying is that normal bump is calculated relative to the lower poly version's normals ("tangent space" refers to the orientation of the low poly's faces). So technically when you change the lower poly geometry, the normal map will be less mathematically "accurate," but in practice it doesn't make any difference in a LOD model since loss of detail is expected.
I know the difference between normal and tangent space mapping. I was just pointing out that the same principle that makes baking normals onto lower poly models possible as a normal mapping technique also holds true for LOD work. Because (like you said) it's normal space, the same map will continue to work on models of similar size and roughly similar shape. Unless the LOD model is severely deformed, normal space ensures that the map will continue to function.
That's why normal maps are so great to begin with -- they simulate high detail on low-polygon models. Obviously you have to keep the same UV layout.
ehhhhhhhh i think both you and the other guy have probably read something about it in a gaming magazine or something and think you know what you're talking about. There is no "difference between normal and tangent space mapping," that statement makes no sense. "Tangent-space normal mapping" is a method of rendering normal maps based on polygon tangents. Normal maps can also be rendered in world-space and object-space but this isn't as useful for games.
Again, the other dude is saying that by altering the geometry in a LOD model, you alter the polygon tangents, and therefore the original basis that the normal map uses is no longer valid. This is correct in theory but the difference isn't noticeable in practice especially considering that LOD's are only meant to be viewed at a distance.
It should look fine if your adjacent triangles point in nearly the same direction and are nearly the same size. That's not a general case; in the general case T, B and N vectors may end up quite different at the same texel in the UV map for different LoD models.
<!--quoteo(post=1823069:date=Jan 10 2011, 02:08 AM:name=cmc5788)--><div class='quotetop'>QUOTE (cmc5788 @ Jan 10 2011, 02:08 AM) <a href="index.php?act=findpost&pid=1823069"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In fact, one popular method of generating normal maps is actually to create a very high poly, sculpted version of the model first and then bake that model's details onto a normal map for a lower-poly, playable version.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, I specifically mentioned this. This exactly tailors the normal map for the T, B and N vectors expected at that texel when using that level of detail. If you were to repeat normal map generation using the same high detail reference model but with a lower LoD model as the target, the normal map would be almost identical over large regions, but not everywhere.
It's not at all clear to me that there wouldn't be places where it would look noticably bad.
Just stop, dude. You've clearly read the wikipedia page on "normal mapping" and are coming to incorrect conclusions based on what you read. Yes, changing the tangents means the normal map is mathematically "incorrect," but the difference would not be significant at all in the scenario we're talking about.
You could just as easily say that the original texture map will not be valid for the LOD model, because there will be texture stretching if polygons are altered and you might introduce new seams by changing geometry. Which is equally true and equally irrelevant, because both the texture and the normal map will look adequate at the distance that LODs are rendered and (optimally) the loss in quality won't even be noticeable.
BTW it's normal, tangent and bitangent not binormal. Look up Wolfram. (Microsoft didn't)
Anyway back to graphics: I think I saw Max mentioning LPVs somewhere. I'm curious if it gets added to NS2. At the moment it seems to be using very primitive 0 bounce dynamic lighting. It's all bright, shiny and unnatural. I'm not sure if LPVs were used in any commercially released game (Crysis 2 isn't there yet).
There also seems to be an issue with aliasing of specular component. I might be seeing things that are not there though.
you mean someone who is amazed that nobody on this forum is able to answer the simple question "how does collision work in Spark?" Or are you trolling? Or are you seemingly surprised at the idea that someone who knows how to create normal-mapped models would not magically know how an engine with no documentation works? My money is on trolling.
I don't understand what "it does bounce to any other surfaces" mean. Light bounce is about light hitting 1st surface on its way, bouncing from it and hitting another. For instance precomputed radiosity in Source does around 50 bounces and Crysis 2 tries to simulate 1 in real-time.
Deferred has not much to do with it. Applying lights in screen space doesn't make anything easier. If anything I'd expect that this optimization would be invalid with anything simulating bounce(s).
OT: I don't like that post with 1 line of text has height as if it had 20 due to info about author on the left side.
You can spend hours "discussing" topic with different definitions arguing without understanding each other. Every real discussion starts with definition and semantics. :)
Almost every gameplay/balance discussion makes no sense because people don't understand each other.
Yeah there's four or five different people that have sprouted up on the forums as of late which are as I put it, arguing the toss for arguments sake. Either that or they're still at school and have ADHD, however they seem "too smart" to still be at school or have the Google skills of a King.
The normal map is generated by making a very high definition model and using that as a template; you trace a bunch of rays along the normal of the low definition(ingame) model and store the normal of the surface they hit on the high definition model in the corresponding pixel in UV(texture) space of the low definition model.
The format of the stored normal is a coordinate in tangential space(since it's normalized, you only need the coordinates in the tangential and binormal directions to reconstruct the full normal, since the length must be one, but you need some additional math in the pixel shader if you omit the coordinate in the normal direction).
Tangential space is the space spanned by the vertex tangent, binormal and normal, interpolated between the vertices that make up a triangle; the basis vectors will be different if you omit a bunch of vertices so the specular and lighting effects will be different. I'm not sure just how bad it will look, but it could potentially look very bad under some circumstances.<!--QuoteEnd--></div><!--QuoteEEnd-->
Actually you can also just run a photoshop filter over your texture, which is what you usually do for stuff like rocks because trying to actually model rocks at high detail to render a normal from them is nigh impossible.
I don't think a rendering method has been invented that can handle some of the epeens on this forum =P
j/k j/k Hey, sometimes we have to make fun of ourselves.
Well then, I misunderstood. Looks like I also forgot to fini
If you are serious about video games then you should have a computer that can atleast run NS2.
This game isn't crysis or anything, don't ask the developers to dumb the games down so people who are too cheap to buy a comp can play it without lag.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nice attempt, troll. Go away