I just have discovered a problem in LWJGLRenderer.clearZBuffer() respective .clearBuffers(): clearing the ZBuffer does not work if the current ZBufferState is not writable! That's why I added the following lines prior to calling glClear:
Spatial.clearCurrentState( RenderState.RS_ZBUFFER );
if (Spatial.defaultStateList[RenderState.RS_ZBUFFER] != null)
Spatial.defaultStateList[RenderState.RS_ZBUFFER].apply();
I recommend to put this in CVS - it cost me quite some time to fix :| so others should benefit from this, too :)
Or maybe one can make a fix that is more clever than applying the default state?
hmm, but it seems like if the current zstate is not writeable, there was some reason for that in your program or you need to simply set a writeable state. Maybe I’m just picky though. 
Yes I have things that need a non-writable zbuffer - some of them are drawn at the end of the rendering in a texture renderer. The next time the render to texture happens then, the zbuffer is not cleared, which results in quite a mess…
Would you suggest to change the current zbuffer-state by the application code?
I would only because it seems like it would leave things more up to the developer and act like an opengl standard. Just my opinion though obviously.
k, maybe add a javadoc comment then to explain the bahaviour instead?
Just out of curiosity: With what intent one would call clearZBuffer() with a current non-writetable ZBufferState? Wouldn’t it be better to omit the call instead?
So the Z-buffer is left in whatever state it was in when the last frame was rendered, and then clearZBuffer is called - so it depends on the Z-buffer state of the last Spatial rendered. Considering objects get put into different queues and sorted into Z-order, that means that almost any object could be the last one rendered, doesn’t it? The programmer then doesn’t have much control of the Z buffer state when clearZbuffer is called.
hmm, I was more thinking you were specifically calling clear zbuffer. If you check renderQueue in LWJGLRenderer you’ll see we already make sure the current zbufferstate is writable.
"renanse" wrote:
If you check renderQueue in LWJGLRenderer you'll see we already make sure the current zbufferstate is writable.
Yes but not in a LWJGLTextureRenderer (if you use more than one).
Hmm odd since texture renderer uses the renderQueue() method of the renderer. What am I missing here?
If you put
Box box = new Box( "test", new Vector3f( -10, -10, -10 ), new Vector3f( 10, 10, 10 ) );
ZBufferState zs = display.getRenderer().createZBufferState();
zs.setWritable( false );
box.setRenderState( zs );
box.getLocalTranslation().set( 10, 30, -30 );
box.setRenderQueueMode( Renderer.QUEUE_TRANSPARENT );
box.updateRenderState();
model.attachChild( box );
at the end of simpleInitGame of TestCameraMan you can watch one of the effects: The texture is not rendered correctly any more. If you then set the background color for the texture renderer to e.g. red you can see the zbuffer is the thing that's broken.
While testing this I even recognized another problem: The new box is flickering in the main view. If you comment out 'if (lastRend > .03f)' in simpleRender it vanishes completely. :?
The flickering/vanishing box is caused by the render queue problem already discussed here: http://jmonkeyengine.com/jmeforum/viewtopic.php?t=1811
But maybe it should not be a ‘feature’ that some spatials are not rendered if they were in a queue for the prior render (to texture)…
hmm, I think this needs more discussion before any "fix"…