This is a diff patch that allows you to use a new render queue: QUEUE_EX_OCCLUSION_CHECKED, which draws the spatial only if it's bounding volume is visible (passes at least 1 depth test).
http://www.fileden.com/files/2007/1/6/603056/occlusion2.zip
The new mode is still in alpha, probably has bugs, etc.
HPOcclusionTest code was commented out since it doesn't really fit with the rest of the API.
Lens flare renders a small box and then sees if the box was occlused. It makes a ray between the camera and the box and uses ray collosion detection. But right now it's using per triangle collision detection which gets very slow when the ray crosses many objects.
So what are we doing with this?
Throw in a use case (a test) and I can start modifying lens flare occlusion because I need it to work fast for my project. And I'll share the results when it's done.
It won't work for lens flare because ortho queue had issues with bounding volumes.
Hm, actualy nevermind. This will work with lens flare as well, but you won't be able to use the customized queue mode. You have to use the renderer method getOcclusionTool and make your own query for the small box.
I updated the link above with a new version, fixes bug in front to back rendering, also makes the occlusion samples variable mutable.
Here's a test case for this:
import com.jme.app.SimpleGame;
import com.jme.bounding.BoundingBox;
import com.jme.bounding.BoundingSphere;
import com.jme.math.Vector3f;
import com.jme.renderer.RenderQueue;
import com.jme.renderer.Renderer;
import com.jme.scene.SharedMesh;
import com.jme.scene.TriMesh;
import com.jme.scene.shape.Sphere;
public class TestOcclusionQueue extends SimpleGame {
private Sphere base;
protected TriMesh makeSphere(Vector3f pos){
SharedMesh m = new SharedMesh("sphere"+pos.x+"_"+pos.y+"_"+pos.z, base);
m.setLocalTranslation(pos);
return m;
}
protected void simpleInitGame() {
display.getRenderer().getQueue().setMinOcclusionSamples(1000);
base = new Sphere("spherebase", 30, 30, 1);
Vector3f pos = new Vector3f();
for (int x = 0; x < 25; x++){
for (int y = 0; y < 25; y++){
TriMesh s = makeSphere(new Vector3f(x * 2f, y * 2f, 0));
// boxes are rendered faster than spheres
s.setModelBound(new BoundingBox());
s.updateModelBound();
rootNode.attachChild(s);
}
}
rootNode.setRenderQueueMode(Renderer.QUEUE_EX_OCCLUSION_CHCKED);
rootNode.updateGeometricState(0, true);
}
public static void main(String[] args){
TestOcclusionQueue test = new TestOcclusionQueue();
test.setDialogBehaviour(ALWAYS_SHOW_PROPS_DIALOG);
test.start();
}
}
Move behind one of the spheres and you will notice an increase in FPS (not too big since occlusion checking also requires hardware rendering, the benifits will be greater with a more complex mesh)
Did anybody try this yet? I might try to make Lens Flare use the system to replace software occlusion checking.
Im fixing a skydome that includes lens flare and I'm half way there before I get to flare occlusion.
fwiw, part of the current 2.0 rewrite involves making the RenderQueue system a pluggable/extensible system (among other things) and this looks like a good plugin candidate. 
I'll test it soon !
My apologies for digging up this old post.
Is this still patch available anywhere?
Has any thought gone into thinking how this sort of feature could be multithreaded.
The general idea is that at the start of a render cycle, two threads do the work. One thread will only sends commands to OpenGL and perhaps also check for what is in the frustrum, the other thread can perhaps then start preparing the rendering for each scene item. Both threads will be in a complete state at the end of one render cycle.
Argh… this is what I get for not using my own server.
Okay, I was able to recover some stuff:
http://www.radakan.org/paopao/occlusion.zip
Has any thought gone into thinking how this sort of feature could be multithreaded.
I am not sure, but I think it's best if the occlusion queries are done on a Pbuffer/FBO, that way the video card processes less pixels. You might also be able to create that buffer at another thread, but then the issue is that you have to do a context switch between threads and that's not a recommended thing to do..
I still think it's best for stuff like lens flare, and an indoor FPS. You render the rooms' bounding boxes in the Pbuffer and then you know which rooms the player can see and which not, and then draw the ones he can see.
Those diff patches included in the zip seem to be a little odd. maybe missing something?
Well if you need the modified RenderQueue I could get you that. Though it's not really useful as of now. Really you should only be using the included occlusion tool. Use Renderer.getOcclusionTool to get it.
Ah. I was trying to run the above test code. I didnt jump into the code in the zone to poke around.