Shapes "show through" terrain chunks

This may just be showing my ignorance, but my various shape objects are always visible provided they are within viewing distance, even if there’s a chunk of terrain between the camera and the shape.

My terrain scene is added before the shape scenes to my root scene.

I have no explicit “setForceView(true)” lines in my code.

            scene = new Node("Root node");



Is this expected behavior?


I tried setting a bounding box on my TerrainPage thinking maybe that was the problem.

In the process, I discovered another permutation of the bounding box center bug that needs fixing:

RCS file: /cvs/jme/src/com/jme/bounding/,v
retrieving revision 1.6
diff -u -r1.6
---   22 Apr 2004 22:26:23 -0000   1.6
+++   29 Apr 2004 01:38:08 -0000
@@ -299,8 +299,11 @@
             rVal.checkPlanes[4] = checkPlanes[4];
             rVal.checkPlanes[5] = checkPlanes[5];
             return rVal;
-        } else
-            return new BoundingBox(name+"_clone", (Vector3f)center.clone(), xExtent, yExtent, zExtent);
+        }else {
+            Vector3f newCenter = null;
+            if (null != center)  newCenter = (Vector3f)center.clone();
+            return new BoundingBox(name+"_clone", newCenter, xExtent, yExtent, zExtent);
+        }

However, all that did was cause large portions of the terrain object to disappear in blocks as the direction of the camera changed. Strange culling?

If you are seeing shapes “through” other objects (terrain for instance) you need to make sure z buffer is turned on. Are you using a ZBufferState on the root node? If so, is it enabled?

Boundings are set automatically for the Terrain, and due to some buggy issues with the setting of the TerrainPage boundings manually (as you saw), don’t use that currently. :slight_smile:

yeah, you don’t want to assume a new center point like that. If you get a npe it’s likely something in your scene doesn’t have a bound when it should.

Thanks. I’ll look into the ZBufferState tomorrow. If it wasn’t in TestTerrainPage, it’s not in my code.

As for the BoundingBox.clone, clone shouldn’t make assumptions about the state of the data. If the object was supposed to be cloned and it had a null center, the clone should have a null center.

I know the same issue was fixed the first day I used jME for one of the bounding objects (my first bug report).


I feel I should elaborate on this to insure it gets fixed. BoundingBox.clone should not have a side-effect of checking data integrity in other parts of the system.

If center should never be null, then the initializer and setters for bounding box should report the error on setup rather than hoping it gets caught if the user happens to clone the object.

Otherwise, at some future point, someone is going to depend on clone() actually working properly even if the center is null (perhaps in some unforseen subclass of BoundingBox), and the software will break.

I’ve been hit with this type of cloning bug in other non-open-source software where they didn’t make clone work in every possible circumstance, and when I needed to make a clone of a partially-initialized object in a subclass, it could not be done. And thus I was hosed.


Thanks. I'll look into the ZBufferState tomorrow. If it wasn't in TestTerrainPage, it's not in my code.

TestTerrainPage uses SimpleGame, SimpleGame sets the ZBufferState. So if you are using SimpleGame it's a bigger problem than not setting ZBufferState. If you are not using SimpleGame, you'll need to set the state yourself.

Thanks. I still probably won’t get a chance to look at this until this evening after my day-job, but that’s probably the problem. I am using FixedLogicRateGame, not SimpleGame.

Just got back to the board and reread this. I thought you were checking for null and adding a new center in if null. That would be bad. working around the null is fine, although still if it is null, you are likely doing something wrong. I guess that’s the programmers issue though. Anyhow, 'nuff said, I’ve added something similar to both bounding types that will do the job.

Mojo, thanks, as you suspected, it was a missing zBufferState problem. I copied the code in SimpleGame over and attached it to my root node, and everything works great.