Jump to content
  • Advertisement
Sign in to follow this  
Maddibob

(-)(-) Vertex crunching (-)(-)

This topic is 5403 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

Hey all I'm writing the next blockbuster which involves a rather large terrain map. I'm currently using a heightmap to generate the basic terrain and an Octree to display it. It all display superbly well and with 4 passes I can easily clack out 60fps. I started to think about adding other things to my setup and realised that things might slow down a bit. AT the moment, my terrain map contains for argument's sake, 100 polygons with vertices at varying heights creating the nice landscape. Currently, each polygon has it's own 4 vertices so when I go to draw the entire landscape [Octree culling ommitted here for clarity], I'm actually transforming 400 vertices. Now... If each polygon was sharing vertices, surely that would mean I'd only have to transform 100 vertices. Lovely thought.... This is where my question is cut - I can easily setup polygons to share vertices, but how would the texture mapping work if I wanted, for argument's sake, a texture per polygon? Surely all polgyons that shared vertices would also have to share their texture coords? I'd really like to know how the big boys do this type of thing (we haven't heard that before have we?!), so any help will be gratefully received. Also if anyone is seriously interested in a serious project which no other games company has even thought about, drop me a line. Rob

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Create a separate stream ?

Share this post


Link to post
Share on other sites
Quote:
Original post by Maddibob
... but how would the texture mapping work if I wanted, for argument's sake, a texture per polygon?

You must batch your polygons by texture since you can't switch textures in the middle of rendering a vertex buffer (unless you are doing something like texture splatting). You can reuse the vertex buffer, however.

As far as how the "big boys" do it... research "geomipmapping" and "Chunked LOD" .

Share this post


Link to post
Share on other sites
Thanks for the replies guys, but I'm not sure if I made my question too clear. My polygons are sorted by texture and it's not the actual drawing of the texture I'm asking about. Each vertex in a poly has it's own texture coordinates, tu and tv. If you have a vertex which is shared between 4 polygons like for example the centre vertex in the middle of 4 squares, the 4 polygons will have to share the texture coordinates of that vertex with each other.

If you had a texture with 4 images on it and you used that to give you 4 possible images per texture (i.e. one polygon could use one area of the texture and another polygon could use another area), then how would you specify that that particular vertex holds different texture coordinates for one polygon than it does for another?

a--b--c
| | |
d--e--f

Above, the left poly is a, b, d, e and the right is b, c, e, f. The two polys share b and e and will also have to share the texture coordinates. So if you wanted to stretch the same texture over these two polys, how would you do it?

Thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by Maddibob
If you had a texture with 4 images on it and you used that to give you 4 possible images per texture (i.e. one polygon could use one area of the texture and another polygon could use another area), then how would you specify that that particular vertex holds different texture coordinates for one polygon than it does for another?


In D3D, you can use "streams" to do what you want to do. In OpenGL, it depends on how you handle the vertex info.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
In D3D, you can use "streams" to do what you want to do.

No, you can't. I wish people would stop saying you could, so I can stop explaining that you can't. People say using streams and indices solves this issue. But all vertex streams are indexed by the same index, not an index per stream. If ANY vertex data (color, texcoords, normal, tangent vector, etc.) varies from one face using a vertex and another face using the vertex, you actually need completely seperate vertices. Just because they share position doesn't mean they can be the same vertex.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you will have to have seperate vertice data containing the different texture coords.

You may be able to still use indexes for sets that share the same texture.

I have been hearing more and more how the graphics cards are getting so fast that triangle lists often run almost as fast as indexed fans/strips -- so u might try brute force (no index set building beyond texture grouping of triangles).

Your octtree/quadtree mechanism may chop up the sets so much that groupings wont do much good (and simple texture sets will be sufficient)

Share this post


Link to post
Share on other sites
Thanks for all the helpful replies. It does seem a shame the the video cards have to recompute vertices that share the same coordinates, maybe they're working on this as we speak (some kind of caching of coordinates would be in order).

Cheers

Share this post


Link to post
Share on other sites
hmmm... im going to venture a guess here, but, why dont you crunch all the vertices together, so that they do have all the same position, normals and texture coordinates, and use a texture matrix on the 2nd set to displace it...?

Could'nt that work?

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!