Back to General and Gameplay Programming

Octree Frustrum Culling

Asmodeus · 2015-09-01T11:57:33

Hello, times came when i had to implement some culling into my engine. I started by reading some stuff and so far so good. I managed to create an octree which can effectivly divide my geometry's vertices (per mesh) into an octree. But here i have some Questions: Currently i am using immediate mode to test if the culling works. And it does work, i am recursivly traversing the tree's nodes and testing against the node's bounding box if the frustum intersects with it. Repeat untill leaf is found and render that leaf's geometry (with immediate mode for testing) But now i would like to use VBO/VAO's to render the geometry in the leaves and here i see two options: - 1.Each time the i traverse the tree push the leaves that intersect with the frustrum into a list then get the vertices out of them and construct a VBO and send it to be rendered. - 2.Pre build a VBO for each leaf then just rebind for each visible leaf and render. Anyway, which is the better option rebuilding a new vbo each time the frustum changes, or just rebinding multiple vbos (which is also expensive). Also is this even the right approach , maybe i am missing something. bool view_Culling(CFrustum& frusrum, COctree *node) { if (!node) return false; if (frusrum.CubeInFrustum(node->GetCenter().x, node->GetCenter().y, node- >GetCenter().z,(node->GetWidth()/2.0f))) { if (node->IsSubDivided()) { view_Culling(frusrum, node->OctreeNodes()[TOP_LEFT_FRONT]); view_Culling(frusrum, node->OctreeNodes()[TOP_LEFT_BACK]); view_Culling(frusrum, node->OctreeNodes()[TOP_RIGHT_BACK]); view_Culling(frusrum, node->OctreeNodes()[TOP_RIGHT_FRONT]); view_Culling(frusrum, node->OctreeNodes()[BOTTOM_LEFT_FRONT]); view_Culling(frusrum, node->OctreeNodes()[BOTTOM_LEFT_BACK]); view_Culling(frusrum, node->OctreeNodes()[BOTTOM_RIGHT_BACK]); view_Culling(frusrum, node->OctreeNodes()[BOTTOM_RIGHT_FRONT]); } else { //use prebuilded vbo here //or push these vertices here in a list later build a dynamic vbo //from them node->DrawOctree(node); return true; } } return false; }

General and Gameplay Programming Programming

Started by ????????? ????? August 27, 2015 09:38 AM

14 comments, last by ????????? ????? 8 years, 7 months ago

kalle_h

2,470

August 29, 2015 07:36 PM

"Simply not worth the cost just to avoid drawing a few off-screen triangles" - THAT

I do not agree. You cant say that because you may be sending 100% of the model when you are actually seeing 5%. If the calculations per vertex are expensive or you are GPU bound (saying that cause my GPU is not the greatest and doing extra stuff seems to be unnecessary

It's not very good for overall conversation that you split quote like that.

Actual quote should be:

Subdividing meshes at run-time is overkill and simply not worth the cost just to avoid drawing a few off-screen triangles.

Which has totally different meaning.

But back to the point. There was great presentation at siggraph from Ubisoft. http://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf

They are doing super precise frustum and occlusion culling on gpu. Using just 64 triangle strips as primitives. But the conclusion was bit disappointing because they didn't get huge overall gains even after all that effort.

????????? ?????

120

Author

August 30, 2015 08:20 AM

Yea but i specifically said in my first post that the octrees wont be created at run time cause we are talking about static geometry. I am sorry if the quote wasn't very accurate.

Anyway i was looking on a way to actually draw a specified range from a vbo, how would that work. Currently i am having the geometry of a given object split in the leafs of an octree. So i should be having some range from where i want to draw from the VBO in each leaf

You can store multiple meshes within one VBO. A VBO is just a memory allocation -- like malloc or new char[].
You don't have to draw the entire contents of a VBO -- you can specify an offset to start reading triangles from, and how many triangles to draw.

Also, you can use an index buffer.

In your situation, you can have the entire mesh stored in one VBO, and then every frame you would produce a new index buffer, which only contains the indices of the triangles that you would like to draw, and then issue one draw-call using all of those indices.

Alternatively, you don't need to dynamically create any data each frame -- just put all the triangles into one VBO, and all the indices into one IBO -- but with each 'leaf' occupying a different sub-section of that IBO. You then issue one draw-call per leaf, which specifies the IBO offset for that leaf, and number of vertices in the leaf.

L. Spiro

25,818

August 30, 2015 11:07 AM

Anyway i was looking on a way to actually draw a specified range from a vbo, how would that work.

VBO + IBO: https://www.opengl.org/sdk/docs/man/html/glDrawElementsBaseVertex.xhtml
VBO Only: https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml (Specify the offset into the VBO in the pointer parameter).

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

????????? ?????

120

Author

August 31, 2015 02:38 PM

Thanks , i was away for a while. But i was wondering, since my geometry is split between all leaves, so each leaf has some chunk of the terrain vertices (for now just vertices,no indices involved to avoid complications). So i am using flat out buffer where all vertices are ordered according to the indices, ready to be drawn. But since my geometry is split , how sould i specifiy offsets to the glVertexAttribPointer (or rather how would one obtain those offsets per leaf)

Thanks !

L. Spiro

25,818

September 01, 2015 08:49 AM

how sould i specifiy offsets to the glVertexAttribPointer

I told you. Pass the byte offset as the argument for pointer.


	::glVertexAttribPointer( X,
		X,
		X,
		X,
		m_ui32Stride,
		reinterpret_cast<LSUINT8 *>(null_ptr) + START_VERT_ELEMENT * m_ui32Stride );

(or rather how would one obtain those offsets per leaf)

That is up to you based on how you create the slices in the terrain, which I still heavily advise against doing.
Again, it’s just a poor man’s BSP tree. Simply less efficient and frankly an “abuse” of octrees.

And in regards specifically to terrain, you are way off the mark.

I already linked to GeoClipmap and GeoMipmap terrain methods and explicitly stated it is not only fine but encouraged to use a separate culling routine for terrain.

There is a reason games don’t do what you are trying to do, and as someone who specializes in optimizations and performance I feel dirty helping you in this topic because I know it will be your only implementation and thus your final implementation. You aren’t going to implement multiple methods and compare them, you’re just going to assume your way is best and never know reality.

I just feel dirty here.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

????????? ?????

120

Author

September 01, 2015 11:57 AM

As i told you above i have implemented the culling on object/mesh level , and i am sattisfied with it . I want to try and go deeper and see what i can do , if it does not work,if i dont see any performance gain i will not use it ofcourse. I think your attitude is a little passive aggressive , instead of an answer i get some bull and you are wasting your and mine time.

Octree Frustrum Culling

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Octree Frustrum Culling

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines