hello,
I thought about how you could render a scene with a large range of z values.
I had some idea and found out, that this idea is not new at all:
Some programmers devide a scene into different "ranges of z" and then render them incrementally by clearing the z-buffer between.
An example:
set z range
draw background objects.
clear z
set new z range
draw map/world objects
clear z
set new z range
Draw guns and stuff
(found this description on GameDev.net)
My question would be: Is something like that possible with jME?
Had some z-value issues already and solved them by using a dirty trick:
make an object (far away)
make a ZBufferState and set writable to false.
attach the ZBufferState to the object
make another object (not so far away)
make a ZBufferState and set writable to false.
attach the ZBufferState to the object
make a Node
attach the far object first
attach the near object thereafter
render the node (it obviously renders the first child first).
Any comments and suggestions on that would be appreciated …
Ok, wrote something of little use here first. I'll give it another try:
If I understand right, what you want to do is first render some far away objects (in their own z range), then some objects even closer in their range (in their own z range) etc. and you know which objects belong in what group.
Never done anything like that, but you can probably do this the easiest by making your own game extending from basegame (see Lesson2 of the flagrush tutorial). During render, you first set the camera up for the far away group (don't forget to update() the camera), then you let the renderer draw() that Node and then use renderQueue() to make sure everything is rendered. Call clearZBuffer(), then setup the camera for the next group, do draw() + renderQueue() for this node, clear zbuffer & setup cam for the final group, draw() it and call displayBackBuffer() (which will call the final renderQueue() for you).
No garantuee this will work, but you can give it a try. Some type of automated system for this (where you don't have to split everything into Nodes yourself) could perhaps be made with the Pass system.
Ah, thank you.
I was beginning to think in the same direction, but I'm not yet good at understanding jME ( or even using eclipse 
).
Of course, automated sorting might drastically lower the number of clipping calculations performed by jME.
Maybe I must implement a special quadtree / octree that automatically builds up a jME scene graph.
This is not too hard, actually I'm already working on something in that direction …
The benefit would be that you would have a little less z-buffer artifacts.
I can even imagine a more advanced version that makes imposters (with render to texture) - but that would need some advanced Z-sorting and more knowledge about render to texture in my head 
We already have render-to-texture imposters in jME (see jmetest.renderer.TestImposterNode)
As for the autosorting, that can be a good idea of course, but maybe you can start more simple, eg. split your scene into the "guns and stuff" and the rest as I described.
Ogli said:
Maybe I must implement a special quadtree / octree that automatically builds up a jME scene graph.
Something like CollisionTreeManager (from the stress tests)? That's not a quad-/octree but maybe easily adaptable for z-range.