Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualLambdacerro

Posted 18 April 2013 - 03:50 PM

Hello guys,

 

Right now i'm working on a game engine for a game i want to make, this is mainly for research and learning purposes.

 

I have most of the rendering base code done, loading meshes from a custom format aswell as materials and other stuff, however, in the last days i've been doing some research about what space partitioning method should i use for my world geometry.

 

I've been reading about KD-Trees, Octrees (and it's smaller variants) and BSP Trees, out of the three i guess i will stick with Octrees because it allows both outdoor and indoor efficient culling of geometry (or that's what i understood), the game will be mainly indoor but because of the nature of the project i wanted some generic way to make both types of scenes.

 

I've got the concept of octrees pretty well and i dont think i will have problems when implementing them (Im a self-taught graphis programmer), however there are some concepts that i dont get a clear view when i think about them, mainly precomputed visibility of nodes and what would be the most efficient way to render each visible node.

 

For the first i thought of the hardcore way, for each node check which nodes are visible (just like portals), this is kinda heavy for a complex scene but i dont mind to spend some time on precomputing visibility, the other i thought is to do the checking on the fly based on the camera frustum bounding box or the frustum planes themselves.

 

The other is once you determine which nodes are visible, what would be the most efficient way to render them.

 

The first approach i thought was to build a list of indices of the visible triangles and send them to the rendering API to be processed, main problem with this is that is kind of CPU intensive i guess since you would have to iterate over all the nodes, grab the indices of the polygons inside them and copy them over the active index buffer.

 

The second was to make a index buffer for each visible node and render each node manually, main problem with this is the memory overhead (i guess that DX/OGL uses extra memory per each created index buffer besides the memory needed to hold the indices itself) and the increased draw calls, both for the drawing itself and the switching between index buffers.

 

The third is to precompute a index buffer of the visible polygons for each node, same issue with memory as the second method.

 

I ask the help and opinion of the experts over here about what would you guys recommend me in order to create the best possible design.

 

Thanks!


#1Lambdacerro

Posted 18 April 2013 - 03:50 PM

Hello guys,

 

Right now i'm working on a game engine for a game i want to make, this is maily for research and learning purposes.

 

I have most of the rendering base code done, loading meshes from a custom format aswell as materials and other stuff, however, in the last days i've been doing some research about what space partitioning method should i use for my world geometry.

 

I've been reading about KD-Trees, Octrees (and it's smaller variants) and BSP Trees, out of the three i guess i will stick with Octrees because it allows both outdoor and indoor efficient culling of geometry (or that's what i understood), the game will be mainly indoor but because of the nature of the project i wanted some generic way to make both types of scenes.

 

I've got the concept of octrees pretty well and i dont think i will have problems when implementing them (Im a self-taught graphis programmer), however there are some concepts that i dont get a clear view when i think about them, mainly precomputed visibility of nodes and what would be the most efficient way to render each visible node.

 

For the first i thought of the hardcore way, for each node check which nodes are visible (just like portals), this is kinda heavy for a complex scene but i dont mind to spend some time on precomputing visibility, the other i thought is to do the checking on the fly based on the camera frustum bounding box or the frustum planes themselves.

 

The other is once you determine which nodes are visible, what would be the most efficient way to render them.

 

The first approach i thought was to build a list of indices of the visible triangles and send them to the rendering API to be processed, main problem with this is that is kind of CPU intensive i guess since you would have to iterate over all the nodes, grab the indices of the polygons inside them and copy them over the active index buffer.

 

The second was to make a index buffer for each visible node and render each node manually, main problem with this is the memory overhead (i guess that DX/OGL uses extra memory per each created index buffer besides the memory needed to hold the indices itself) and the increased draw calls, both for the drawing itself and the switching between index buffers.

 

The third is to precompute a index buffer of the visible polygons for each node, same issue with memory as the second method.

 

I ask the help and opinion of the experts over here about what would you guys recommend me in order to create the best possible design.

 

Thanks!


PARTNERS