Jump to content
  • Advertisement
Sign in to follow this  
Shanee

Chunked LOD Normals question

This topic is 2900 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I read an algorithm based on Chunked LOD but not exactly it where they suggested to have just one base leaf mesh and scale it and get the heights for vertices in the vertex shader.

I have 3 questions I hope someone could answer:

1. About retrieving vertices normals, I will need to make an additional texture to retrieve the normals in the vertex shader as well?

2. Will it be much of an impact to get both the heights and normals from a texture in the vertex shader?

3. Is the RAM needed big enough to justify using just one mesh/vertex buffer and getting the height and normals in the vertex shader? Should I just create multiple vertex buffers instead?

Thanks :)

Share this post


Link to post
Share on other sites
Advertisement
First GPU is a parallel architecture so like all parallel architecture you need some locking mechanism if multiple threads access the same data.
this applies for gpu too

1) you can compute your normals from the heightmap directly in vertex shaders
so no need for an extra texture but need of more fetching...alternatively in order to avoid the extra fetch for normals you could encode RED = H HeightMap GREEN = (H)dx(derivative in height along x axis) BLUE = (H)dy same for y axis.
but this will make the terrain static because displacement texture regeneration will cost you CPU time, locking against VB ect...

2) From what i know on DX9 hardware vertex texture fetch is slow (you can use PIX on PC in order to measure it to see if it's always true because this asumption was right on early DX9 hardware...) (except on Xbox360 wich has hardware shortcuts for it and perhaps modern PC cards )

3) For the VRAM , depends on your needs , if you want to render terrain only ok but not planet sized ? ;-) but what if you have several thousands of other geom data ?

Hopes this helps.

Share this post


Link to post
Share on other sites
Thanks!

Question though: How would you calculate the normal in the vertex buffer from the height map?

Share this post


Link to post
Share on other sites
Quote:
Original post by Shanee
Thanks!

Question though: How would you calculate the normal in the vertex buffer from the height map?


That's not a difficult thing all you have to do is sample your heightmap 5 times
in a diamond with texcoord being something lio(vertexNumOfThisPatch/numVertsPerPatch)

*x2

*x0 *x *x1

*x3

this way all you have to do , to evaluate the center pixel's normal is crossing vectors of all directions and average them ie :
N0 = cross(x-x0,x2-x)
N1 = cross(x1-x,x2-x)
ect.. and average them. you will end up with four normals so divide the result by 4 to average.

Border case will be the pbm ...
be sure to emulate or enable Mirror address mode in the shader for border case ...


Share this post


Link to post
Share on other sites
Thank you. I knew about that way but I was hoping for a less costy method as sampling so many pixels sounds like quite a performance hit. Although I might be wrong, am I?

For now I decided to create vertex buffers as needed, I will see how it works and see if I can improve it from there or go to a vertex shader solution. This also helps me as I can have the bitangets and tangets and it will save me operations in case I want to add more textures sampling on the pixel shader (at the moment I am sampling one blend map and the 5 textures I can blend, I will need to find a cheap way to do parallax mapping, probably add nosie map and shadow map so that's already pretty much 8 shaders without normals, 13 with normal mapping, 18 with parallax mapping unless I can pack it with the normal texture somehow?)

Share this post


Link to post
Share on other sites
Unless i missed something , if your patch of terrain is always the same but only shifted by an offset , the tangents and binormals are always the same

0,0,1 for binormal and 1,0,0 for normal ...

Consider u on tangent space ( you already sample your heightmap like this in the vertex shader...)

if you want to put it back to world space or object space just pass the matrices in the pixel shader.

For the number of slots required : generally for parallax mapping u encode the height value in alpha channel of the computed normal map.

if your terrain is static there will be no interest into computing normals this way... (this will be good candidate for destructible terrain or water ).

you can entirely precompute your normal maps associated with each patch?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!