Strange DepthTest behaviour ( Test case )

Hi Guys,

I have experienced some very strange depth test behaviour… I want to draw a line mesh, that can intersect geometry and be drawn in the front. But I found that it may or may not be drawn depending on the COLOR of the geometry it intersects… That cannot be right…?

With no color set:

With a color set:

Test case below. Removing line 28 makes the lines draw correctly…

import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Line;
import com.jme3.scene.shape.Sphere;

public class TestDepthTest {

public static void main( String args[] ){
    SimpleApplication app = new SimpleApplication(){

        public void simpleInitApp() {

            Geometry line = new Geometry( "Line", new Line( new Vector3f( -100, 0, 0 ), new Vector3f( 100, 0, 0 ) ) );
            Material mat = new Material( assetManager, "Common/MatDefs/Misc/Unshaded.j3md" );
            mat.setColor( "Color", ColorRGBA.Green );
            mat.getAdditionalRenderState().setDepthTest( false );
            line.setMaterial( mat );

            Geometry line2 = new Geometry( "Line", new Line( new Vector3f( 0, 0, -100 ), new Vector3f( 0, 0, 100 ) ) );
            line2.setMaterial( mat );
            Geometry sphere = new Geometry( "Sphere", new Sphere( 10, 10, 10f ) );
            Material sphereMat = new Material( this.getAssetManager(), "Common/MatDefs/Misc/Unshaded.j3md" );
            sphereMat.setColor( "Color", new ColorRGBA( 0.2f, 0.2f, 0.5f, 1f ) ); // Removing this line makes the Depth Test work....
            sphere.setMaterial( sphereMat );
            this.getRootNode().attachChild( line );
            this.getRootNode().attachChild( line2 );
            this.getRootNode().attachChild( sphere );
            this.getFlyByCamera().setMoveSpeed( 10f );


Ps: I like look of the new website, but it sure is hard getting used to… An image upload service would be nice.

1 Like

Generally, the opaque bucket is drawn front to back. If you want the lines always on top then you can put them in the translucent bucket… or create another viewport and stick them in there.

It’s possible that changing the material just randomly causes them to sort differently… you shouldn’t rely on sort order for this and just make it explicit instead.

So setting
mat.getAdditionalRenderState().setDepthTest( false );
only means that the render order will dictate what is drawn? Does jME sort the render order on the run? Because I saw my mesh flicker a bit depending on view angle, when multiple meshes were added with setDepthTest( false ) materials.

Place my geometry in another bucket does solve the issue, but it seems a bit hacky. Is there not a method to give a geometry or material a Z-order offset?

If a geometry is behind another object then it is behind it…if in front then in front…

I guess you could do something with a custom shader to give a z order offset… or modify the sorting in the bucket to draw in the order you want always…

Or use the gui node…

What you are trying to do is innately hacky so I’m not sure what non-hacky solution you thought might be found? For what it’s worth the main purpose of buckets is controlling the sequence of rendering so you are using them correctly, if not for the intended purpose.

You want to make sure the lines always draw after the rest of the scene. That’s what buckets and viewports are for.

It’s not about the z-offset since the relative Z positions will change depending on which direction you are looking… plus you’ve take the z-buffer out of the equation by turning off depth testing.

If it helps… you are essentially saying “I want to ‘overlay’ this graphic on my scene.” Overlay = translucent bucket or another viewport. It’s not hacky… just vocabulary.

1 Like

Thanks pspeed. I have solved the issue, for now, by using the translucent bucket.

I am worried that I’ll need other translucent materials later, which may conflict with my lines. Maybe I’ll have to take your first advice and render them in a separate viewport…

The reason I wanted to use a z-offset, is that that is how I’d acheive this effect in a blender rendering. ( If for instance I want to overlay a wireframe on a geomtry ). I agree that the Z-position can be an issue with a dynamic viewport, I realize that now. ( This is easily solved for a single rendering in blender, but may not be generalizable. )


Yeah, but a wireframe on a geometry is different because you only need a really small offset. This is a completely separate geometry and the offset would have to be “total size of other object” to make a difference.