Jump to content
  • Advertisement
Sign in to follow this  
LordFallout

Geometry Batching for a planet

This topic is 3609 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'm currently writing a planet renderer that renders a realistically scaled universe, everything works really well, LOD, full culling (horizon and view frustum). I'm currently using a modified quadtree too calculate the LOD of a planet terrain chunk and too determine whether or not a chunk is visible. Since my terrain is all ready calculated in fixed sized chunks i just render them as such (each terrain chunk has its own VB and a global index into a LOD Index Buffer), which means each terrain chunk is rendered explicitly with a draw call. When my planets are at the highest level of detail there will be a lot of Draw calls since there will be a lot of terrain chunks I figured I'd be able to reduce the number of draw calls by grouping terrain chunks together into larger buffers, i was just wondering what type of systems do people use for situations like this, all the geometry is static and is created when the quadtree sub divides. Is there a maximum number of primitives a draw call should render at once? At the moment my draw calls are rendering 4225 verts in one draw call, if there is 50 terrain chunks thats 50 draw calls, if i batched two VB together there would be 25 calls which i would assume is quicker.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by LordFallout
each terrain chunk has its own VB and a global index into a LOD Index Buffer), which means each terrain chunk is rendered explicitly with a draw call.
I've had quite a lot of success going the opposite way around - single VB and many IB's. This makes LOD quite easy as you can have a heirarchy of LOD IB's, each skipping/stepping over different numbers of underlying vertices (for example) or you can simply stitch together multiple patches...

Quote:
Original post by LordFallout
i was just wondering what type of systems do people use for situations like this, all the geometry is static and is created when the quadtree sub divides.
Have you read Ysaneya's developer journal? It's OpenGL based but sometime ago he did cover in depth the various terrain rendering algorithms and his results are simply jaw dropping...

Quote:
Original post by LordFallout
Is there a maximum number of primitives a draw call should render at once?
Yes, there is a device cap for it and it doesn't behave properly in my experience. I forget the details, but you can get up to ~1m primitives in a single call on D3D9 hardware.


hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
I've had quite a lot of success going the opposite way around - single VB and many IB's. This makes LOD quite easy as you can have a heirarchy of LOD IB's, each skipping/stepping over different numbers of underlying vertices (for example)
Jack


This is the method I'm using at the moment for rendering the planet with no cracks and works very well, the only difference being i have multiple VB as well as multiple IB's, if i combined all the VB's into one VB and had separate IB's, i would still need to call the draw function multiple times since the IB's would be different like this

Set VB (Giant Buffer)
Set IB (Chunk 1)
Draw (Chunk 1)
Set IB (Chunk 2)
Draw ( Chunk 2)

as opposed to this (my current method)

Set VB (Chunk 1)
Set IB (Chunk 1)
Draw (Chunk 1)
Set VB (Chunk 2)
Set IB (Chunk 2)
Draw (Chunk 2)

Maybe there is a speed increase in calling set VB only once, but there should still be the same number of draw calls (please correct me if I'm wrong, I'd happily bang all these in a single VB if it would help). Would there be no performance increase if we put all the Indices in a giant IB (32bit Indices) as well?

Is rendering ~1M polygons in on call efficient, if so i'd happily throw all my VB's together :)

Quote:
Original post by jollyjeffers
Have you read Ysaneya's developer journal? It's OpenGL based but sometime ago he did cover in depth the various terrain rendering algorithms and his results are simply jaw dropping
Jack


I haven't but i will :)

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!