So, I'm doing octree occlusion which means I have to generate an occlusion query for each node... Which at a depth of 6 is >16,000....
Once I glEndQuery() my 16256th query... It crashes.
Anyone have any clue about this?
So, I'm doing octree occlusion which means I have to generate an occlusion query for each node... Which at a depth of 6 is >16,000....
Once I glEndQuery() my 16256th query... It crashes.
Anyone have any clue about this?
I also suspected it's a driver/hardware bug...
Stack trace comes from GL driver which is basically useless:
#0 0x69e30a2c in atioglxx!atiPS () from C:\WINDOWS\SysWOW64\atioglxx.dll
#1 0x814e724c in ?? ()
#2 0x6994c4f8 in atioglxx!atiPPHSN () from C:\WINDOWS\SysWOW64\atioglxx.dll
#3 0x060f2910 in ?? ()
#4 0x6994b3c9 in atioglxx!atiPPHSN () from C:\WINDOWS\SysWOW64\atioglxx.dll
#5 0x064a4188 in ?? ()
#6 0x69088463 in atioglxx!atiPPHSN () from C:\WINDOWS\SysWOW64\atioglxx.dll
#7 0x814e7138 in ?? ()
#8 0x693f0577 in atioglxx!atiPPHSN () from C:\WINDOWS\SysWOW64\atioglxx.dll
#9 0x00000000 in ?? ()
Also, it's "hypothetically potential" that all octree nodes will be visible at one time - say you fly up into the air and look down onto the scene, or something... So I can't rely on a "workaround" like that.
Is it preferable to use the hardware for the occlusion queries? In several cases it has been stated that a software solution is actually better, although maybe more difficult to implement.
As far as I know, the problem with the hardware occlusion is that you'll have to wait some / several frames for the query results to arrive. Also, SLI/Crossfire requires separate queries created for each AFR unit.
Cheers!
Yeah, pre-generated "potentially visible set" stuff is better but much harder to implement... I might start seriously thinking about it. Also, I use the query result from the last frame so it's not much of a problem
You shouldn't be doing occlusion on each node.
First of all, use frustum culling to remove nodes that aren't in your view pyramid. Don't even bother testing these for occlusion.
Secondly, the way an octree is constructed, if any given node is occluded then all of it's child nodes are also occluded (because a node contains all of it's children). No need to test child nodes of an occluded node.
Your hypothetical case where all nodes are visible at the same time - that's a rare edge case. It's not going to happen unless all of your nodes are on the same plane and the viewpoint is sufficiently far away to bring them all on-screen together. I wouldn't even worry about that all.
Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.
If you're not going to do any stuff that exploits the hierarchical nature of the tree (including what mhagain said above), then you've basically just got a 3D grid, not a 3D tree
The simplest pre-generated PVS system can be extremely simple though. In one game demo that I made, I simply manually created bounding volumes for different sectors, and then manually wrote into a text file lists of which sectors could be seen from which other sectors
As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --
On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries in a fraction of a millisecond, on a GPU from 2006 (much, much faster than HW occluson queries, but slightly less accurate).
Stack trace comes from GL driver which is basically useless
So as long as your usage of the functions is perfectly compliant with the GL spec, then that means you can legitimately blame the driver and/or report a driver bug
Also, it's "hypothetically potential" that all octree nodes will be visible at one time - say you fly up into the air and look down onto the scene, or something... So I can't rely on a "workaround" like that.
You have posted a lot of threads all revolving around occlusion culling. In each you seem to target a problem, that isn't actually your problem.
Yes? That's what I'm focusing on implementing now and each post is aimed at a different specific issue. It's your opinion that "they're not my problem".
Have you done any profiling or performed any measurements, that actually tell you, that you need this sort of occlusion culling?
Yes. For example on a 200K polygon map, I would get a constant 40 FPS since all vertices were transformed. With my occlusion culling I get a varying 60-150 FPS throughout the map.
If your game is supposed to render just fine at 30 FPS even when everything is visible, why do you even care about culling?
I don't care so much that it's supposed to be *fast* in such a hypothetical situation - but that it still *works*.
Doesn't 16k occlusion querries also mean 16k draw calls?
No. Once an octree node is not visible, all of it's leaves aren't processed.
Why don't you try some LOD and pure frustrum culling and see, how far it gets you?
I tried frustum culling and my current octree occlusion works better.
If you are indoor, rather then outdoor, try portal culling.
It might be "easy" - but it puts a limitation on the mapping aspect, and makes thing less flexible.
You have posted a lot of threads all revolving around occlusion culling. In each you seem to target a problem, that isn't actually your problem.
Yes? That's what I'm focusing on implementing now and each post is aimed at a different specific issue. It's your opinion that "they're not my problem".
Have you done any profiling or performed any measurements, that actually tell you, that you need this sort of occlusion culling?
Yes. For example on a 200K polygon map, I would get a constant 40 FPS since all vertices were transformed. With my occlusion culling I get a varying 60-150 FPS throughout the map.
Doesn't 16k occlusion querries also mean 16k draw calls?
No. Once an octree node is not visible, all of it's leaves aren't processed.
If you are indoor, rather then outdoor, try portal culling.
It might be "easy" - but it puts a limitation on the mapping aspect, and makes thing less flexible.