I am wanting to try this in 3D (can really exist in 2D with out some shadowing going on). I have read many things online but am very worried about diving into it. Does anyone on here have any experience with it? Any tips before diving in? Is it worth it? ???
Hi
I just looked at this before trying to answer your question. I implemented occlusion culling based on cells and portals in a simplified case several years ago. I have tried to create a more general implementation for years, it doesn’t work yet. A very few engines provide efficient culling except frustum culling. Octrees are supported by JMonkeyEngine 2, Tesseract uses BSP trees as far as I know. What do you want to achieve?
It might be shocking to some - but some modern AAA-grade engines use a seriously low-res software renderer (just a depth-buffer) to see how many samples get through for a certain shape.
What you are trying to achieve with occlusion culling? Performance or just some effects?
For occlusion culling, software rastersation with heavy threading and SIMD optimizations is going to be really fast. There are optimized version of Intel test sample with lot of info. http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/
These are a few of the many things I have read but there are not code examples just a bunch of theory which is what it sounds like.
http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html
I want to “render” (not actually but loaded in memory) 60 million cubes at 60 frames per a second. On my desktop I am at 9-10 million at 10-12 fps. I want more. I can still do greedy meshing but I am hitting a fill rate limit which greedy meshing won’t help. So I need to simply only render what is visible.
I know it’s offtopic, but please…! No more cube world threads…!
For the love of God NO! I am not making another cube world. I just wanted to see if I could squeeze a bunch of voxel cubes out. There is no adding/removing cubes, infinite worlds or anything just some 3d noise. I am learning 3D via cubes. If this does go anywhere, it is to use the voxels as data for generating a polygonal mesh similar to Voxel Farm which EQ Next is using. I think cube worlds are nice for dipping into 3D as you do not need to have to worry about real asset loading because you just use textured cubes. By dipping I mean more then a rotating shape.
Back on topic, from what I have read I think I will try the portals/doors/windows idea as it is more in my ballpark.
This is the kind of thing that I have tried to achieve:
http://geck.bethsoft.com/index.php/Occlusion_Culling
If you need some help, let me know. I use quads to represent the portals and I advise you not to use polygons. I store the cells in a graph.
Unless terminology has changed, occlusion culling refers to quite something different then cell-and-portal style PVS determination.
The simplest (which is far from the most efficient) way to implement cell-and-portals is to render (at least the depth-buffer) of the cell which contains the camera and objects within that cell (at least ones that can potentially occlude). Then render all portals with writes disabled and asking a counter for number of pixel rendered. If not zero, then mark that cell to be rendered…repeat.
You could probably do something like cull chunks based on using an occlusion test with a cube that encases that chunk.
- Draw the closest X chunks since they’re most likely to be visible anyway.
- Fire occlusion tests. The farther away the chunks are, the bigger your occlusion cubes to cull multiple chunks with a single cube to avoid heavy depth overdraw and CPU overhead.
- Read the occlusion results from the previous frame. Although this will delay the results from your occlusion queries by a single frame, it’ll prevent a performance killing CPU and GPU stall while waiting for occlusion results.
- Render the remaining chunks that passed their occlusion tests.
Like I said my quick-to-hack-together sketch is far from ideal but if you’re drawing N portals in a stage you don’t need to query the first until after you’ve submitted them all. If the first one passes you can start rendering that cell before you query the 2nd portal for it’s result, etc. Smartly choosing the ordering (say smallest screen coverage) and not blindly submitting all portals (such a CPU side back-facing test, etc) lowers the burden.
Ok but it seems to be unclear in Wikipedia and the wiki of the Geck engine.
I start in the (current) cell in which I am, I render it. For each portal of the current cell, if it is in the view frustum, then I render the other cell bound to this portal, I compute another view frustum from this portal that I use to visit this other cell (its portals) and so on…
Sorry…I’m not intending to be a stickler for terminology in this case. I’m simply not clear what OP is really asking. For highly occluded scenes a well implemented cell-and-portals is approaching optimal. But if the case if different: say along the lines of “can I see that hill ahead of me through the trees” then the answer is different.
Clipping the contents of cells starting with the frustum and modifying the bounding volume as it passes through portals is a very good way to lower the PVS and consider much fewer “distant” portals, etc.
I knew some people on here knew stuff thanks. Yes I know that the cells/portals are not real Occlusion culling. I was mainly just wanted to hear some peoples ideas/experience with occlusion culling or similar strategies so I may avoid common hickups/mistakes. I think the portals will be a good start before trying real occlusion culling. From what I understand this technique is rather complex and considered “advanced” but that really is all a matter of perspective.
Thanks gouessej for the link that will help.
The idea I had was that I find the “closest” cube to start with and then build a frustum based on its location and add it to a list of frustums. These frustums are from objects that we know/hope are visible. Before rendering a volume we check it against these frustums to see if it is completely contained in any. If it is, we do not render as it is occluded, else we had its frustum to the list.
I could pick the starting objects by first sorting things out by distance from camera and then proceed by starting with the closes objects. Or, I could do a few ray casts to pick a bunch of objects I know are visible and start with them. I am not sure how costly building frustums and checking if a volume is completely contained in said frustums is. This is all conjecture at this point with no experience which is where y’all come in and tell me I am crazy.
Obviously for the cube world thing (sorry riven) it is too costly to do every single cube but maybe do it based off of large faces from sets of cubes as the near face of the frustum. Oh all of the directions of these frustums will be based on their direction to the camera.
I would rather use the empty space in which the player can move to compute the cells and the portals which should be easier than in the general case as you only have cubes. You have to attach each cube to (at least) one cell.
See this depends if you are using something like opengl because that can support occlusion culling by just enabling it.
No it doesn’t.
Face culling isn’t occlusion culling. I think that’s what you’re thinking of.
Potentially visible set determ & occlusions are high level constructs so you can have your low-level (OpenGL in this case) consider drastically less data.
Ignore that entirely forgot D: