Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


Terrain render process


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Flicklizic   Members   -  Reputation: 566

Like
0Likes
Like

Posted 09 June 2013 - 06:29 PM

Hello, I'm in doubt about which method should I use to render my terrain.

 

First, some information about my terrain style:

 

 - My game came is like Diablo, torchlight type so I dont need to worry about LOD or anything like it.

 - Currently I divide my terrain into 9 parts, each part is divided using a quad tree, rendering only what I can see.

 - Im using a 128x128 heightmap for each terrain which occupies an area of ​​64 game units.

 - Each terrain has it own textures, up to 8, and 2 alpha maps (so I can "paint" the map).

 

So, these are the methods that I thought:

 

1) Store only the texture info, the heightmap and the 2 alphamaps, calculate all the other things at the runtime only when that terrain is needed. Store this data and sent it to the shaders when the render time comes.

 

2) Pré calculate anything on the "building" phase and store ALL data, when that terrain is needed, just load the data and send to the shaders.

 

3) Store the texture info, the heightmap, a pre baked normal map texture and the alphamaps, when render comes send ONLY the textures, on the shader, do something like this:

 

 - Calculate the position using the index, for a 128x128 heightmap will be like this:

// PRIMITIVE_INDEX is the primitive index provided by the shader (I dont remember the semantic now)

uint COUNTER = 0; // Global

-----------------------------------------
uint xPos;
uint yPos;
uint zPos;
uint currentX;
uint currentZ;

currentX = PRIMITIVE_INDEX%128;
currentZ = PRIMITIVE_INDEX/128;

if(COUNTER == 3)
{
   COUNTER = 0;
}

if(COUNTER == 0)
{
   xPos = currentX/2;
   zPos = currentZ/2;
   yPos = TextureLookUp(currentX, currentZ);
}
else if(COUNTER == 1)
{
   xPos = currentX/2 + 0.5;
   zPos = currentZ/2;
   yPos = TextureLookUp(currentX, currentZ);
}
else
{
   xPos = currentX/2;
   zPos = currentZ/2 + 0.5;
   yPos = TextureLookUp(currentX, currentZ);
}

COUNTER++;

 

 - Compute the normals using the normal texture (same idea that I used for the position, the normal texture NOT the same texture for the pixel shader, this is a pre baked VERTEX normal texture)

 

 - Compute the texture coordinates using the positions.

 

 - Compute the tangent and binormal using more texture lookups.

 

Currently Im using the first ideia, but my fps is at 30~20 and I need to improve this (ok, my GPU is not that good, but I can play SC2 normally and Im only rendering the terrain).

 

 

 

Sorry for my bad english.


Edited by Flicklizic, 09 June 2013 - 06:47 PM.


Sponsor:

#2 Krohm   Crossbones+   -  Reputation: 3262

Like
1Likes
Like

Posted 09 June 2013 - 10:36 PM

1) Store only the texture info, the heightmap and the 2 alphamaps, calculate all the other things at the runtime only when that terrain is needed. Store this data and sent it to the shaders when the render time comes.

No idea what "all the other things are".

If the textures are static, you might want to consider baking them together at level load. Is this your option 2?

Doing 8+2 texture lookups can sure be a problem on low-end adapters.

 

What about the code? Where is it executed? Assuming you're using PrimitiveID, D3D10 doc reads "The IA stage will add a primitive id to each primitive for use by the geometry shader or the pixel shader stage". So... it's a GS... moving a whole triangle?

 

It seems to me you're trying to do some kind of "world-space" terrain and I don't like it.

Terrain is a 1D function over a 2D domain. You put the vertices in its 2D domain in the [0..1][0..1] range and then scale this parametrized domain in the world using appropriate transforms. Doing the other way around is a bit of a problem. Come on, doing primitive index manipulation... Just have a tassellated plane with VTF.

 - Compute the texture coordinates using the positions.

You don't need to compute them if you use a parametric representation because the parametric position in "terrain space" is the texture coordinate to use. Sure you'll have to map those to world-space then, but it's a single matrix multiply.

quote name='Flicklizic' timestamp='1370824149' post='5068523']
ok, my GPU is not that good, but I can play SC2 normally and Im only rendering the terrain
[/quote]I guess it would be worth saying what GPU are you using, on what CPU, what's going on... I am inclined to believe you also have other problems.



#3 Flicklizic   Members   -  Reputation: 566

Like
0Likes
Like

Posted 10 June 2013 - 02:24 PM

No idea what "all the other things are".

 

Sorry, I mean by "other things" Tangent and Binormal.

 

If the textures are static, you might want to consider baking them together at level load

 

But as the terrain can change frequently this will generate alot of data processing, no? I will need to calculate the normals, tangent and binormals if they arent stored.

 

I could use just 2 textures for the pre baked data:

 

For the height, the x and y in the first texture (so i can have the height up to 65536 or +- 32,768)

For the normals, the z, w in the first texture and the x on the second

For the tangent, the y, z, and w in the second.

For the binormal I can calculate it in the shader w/ the tangent and normal.

 

2 texture lookups only...

 

I guess it would be worth saying what GPU are you using, on what CPU

 

GPU: GeForce 8400 GS (yeah I need a better one)

CPU: I5 (belive this is ok)


Edited by Flicklizic, 10 June 2013 - 02:25 PM.


#4 Krohm   Crossbones+   -  Reputation: 3262

Like
0Likes
Like

Posted 11 June 2013 - 11:10 PM

But as the terrain can change frequently this will generate alot of data processing, no?

I didn't read about this previously. How much processing will be required depends on how you map the textures.

 

If you map them as some terrain engines I've seen (which basically map texture as it's projected on the terrain from above) then nothing is required at all albeit there will be some swimming. Note most terrains don't really change drastically and when they do, it happens at well defined moments and often on a limited data subset. All those things put together imply it is viable to modify terrain at runtime, albeit not trivially.

Keep in mind that terrain is thing, dynamically displaced meshes are another, in both tech and use scenario. The most realistic example I can think about a "fully dynamic terrain" is about large displaced water. It's a different thing.

What is your game like? You mention Torchlight and Diablo. I played TL1 and sure there was nothing like dynamic terrain here. Heck, there's likely nothing even resembling an heightmap.
 

For the height, the x and y in the first texture (so i can have the height up to 65536 or +- 32,768)

Not really. As I said, use a parametric representation. Nobody cares about a terrain which does 64*1024 units in height when the player is often a few units high. Use this as a [0...1] range which scales a height vector. This way you can have arbitrarly positioned and scaled terrains with both range and accuracy depending on needs.

 

For the normals, the z, w in the first texture and the x on the second

Terrain normals are always pointing up in terrain-space (albeit not exactly up) so you can just rebuild the last component.

 

But seriously speaking, you can compute the terrain normal by just sampling height from nearby vertex-texture samples which is a small coherent kernel.

 

For the tangent, the y, z, and w in the second.

If the texture is not rotated per-triangle the tangent can be considered constant across the whole terrain. The whole TBN basis is really a function of height. That is, if you just do planar texcoord generation.

If not, I guess it's a good time to start elaborating on your needs properly.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS