Undesired culling when using Lighting materials

Hi everyone,



I’ve been playing with the engine for a while now, and recently ran into this odd problem. Right now what I have is a terrain quad on which mouse picking is used to spawn in objects where you click. The model is just a cube with UV coords I slapped together in blender. This was working fine as long as I used unshaded materials, but as soon as I switched to a Lighting material only one of these objects would render at any given time; where as before you could just keep spawning and seeing them all until your framerate hit single digits.



I’m reasonably sure that the model and textures are loading in more or less properly because a.) enabling physics debug will show all the boxes where they should be, and b.) whichever box the camera is “closest to” will generally be the one that it decides to render.



I’m not sure if this is a materials problem, a frustum problem, or some problem with the way I’ve got the scene graph setup, so here are the relevant code snip-its:

[java]

public void initialize(AppStateManager stateManager, Application app) {

super.initialize(stateManager, app);

this.app = (SimpleApplication)app;

rootNode = this.app.getRootNode();

punchablesNode = new Node(“punchablesNode”);

assetManager = this.app.getAssetManager();

bulletAppState = app.getStateManager().getState(BulletAppState.class);

cam = app.getCamera();



initMaterials();

initFloor();

initBoxhead();



DirectionalLight sun = new DirectionalLight();

sun.setDirection(new Vector3f(0f, -1f, 0f).normalizeLocal());

AmbientLight ambient = new AmbientLight();

ambient.setColor(ColorRGBA.White);

rootNode.addLight(sun);

rootNode.addLight(ambient);

rootNode.attachChild(punchablesNode);

}



private void initMaterials(){

head_mat = new Material(assetManager,

“Common/MatDefs/Light/Lighting.j3md”);

head_mat.setTexture(“DiffuseMap”, assetManager.loadTexture(

“Textures/untitled.png”));

}



private void initFloor(){

groundNode = new Node(“groundNode”);

rootNode.attachChild(groundNode);

Spatial testTerrain = assetManager.loadModel(“Scenes/testArea.j3o”);

testTerrain.setName(“Terrain”);

groundNode.attachChild(testTerrain);

groundNode.move(0f, -4f, 0f);

groundPhys = new RigidBodyControl(0f);

testTerrain.addControl(groundPhys);

bulletAppState.getPhysicsSpace().add(groundPhys);

}

//This first one works fine initially

private void initBoxhead(){

Spatial head = assetManager.loadModel("/Models/BOXHEAD.obj");

RigidBodyTickListenerControl boxheadPhys;

boxheadNode = new Node(“boxheadNode”);

punchablesNode.attachChild(boxheadNode);

head.setMaterial(head_mat);

head.setName(“boxhead”);

boxheadNode.attachChild(head);

boxheadNode.setLocalTranslation(new Vector3f(0f, 0f, 0f));

boxheadPhys = new RigidBodyTickListenerControl(1f);

head.addControl(boxheadPhys);

bulletAppState.getPhysicsSpace().add(boxheadPhys);

bulletAppState.getPhysicsSpace().addTickListener(boxheadPhys);

}



//As soon as this function gets called on mouse click, if the new box model

//is closer to the camera than that model will be shown, but the first model

//will be culled, otherwise this function adds an invisible box to the scene!

public void spawnBoxHead(Vector3f location, Vector3f normal){

Spatial head = assetManager.loadModel("/Models/BOXHEAD.obj");

head.setMaterial(head_mat);



Node temp_node = new Node(“boxheadNode”+boxheadNode.getChildren().size());

boxheadNode.attachChild(temp_node);

temp_node.setLocalTranslation(location);

temp_node.attachChild(head);



BoundingBox bounds = (BoundingBox)head.getWorldBound();

Vector3f extents = new Vector3f();

bounds.getExtent(extents);

head.setLocalTranslation(normal.mult(extents));



RigidBodyTickListenerControl boxheadPhys = new RigidBodyTickListenerControl(1f);

head.addControl(boxheadPhys);

bulletAppState.getPhysicsSpace().add(boxheadPhys);

bulletAppState.getPhysicsSpace().addTickListener(boxheadPhys);



}

[/java]



Also, I am using the default fly cam controls, with the frustum set with:

[java]

cam.setFrustumPerspective(45f, (float)cam.getWidth()/cam.getHeight(), 0.01f, 1000f);

[/java]



Hopefully I am right and the problem is in there some where. Otherwise I would be glad to provide additional information. Thanks in advance!

And this is the only difference between working and not working?

head_mat = new Material(assetManager,

“Common/MatDefs/Light/Lighting.j3md”);



Can you be sure by changing that to the unshaded material (and changing nothing else) and verifying that behavior changes?



Also, what version of JME are you running?

Thanks for the reply!



I double checked just now, and confirmed that changing only the initMaterials() function to read:

[java]

private void initMaterials(){

head_mat = new Material(assetManager,

"Common/MatDefs/Misc/Unshaded.j3md");

head_mat.setTexture("ColorMap",

assetManager.loadTexture("Textures/untitled.png"));

}

[/java]



alleviates the problem. With the code as above all models render properly when new models are added to the scene. Switching back to lighting material with the texture set to DiffuseMap causes the problem again.



As for the version, the SDK reports it as being jMonkeyEngine SDK 3.0beta.

Just in case… if you haven’t already… make sure you are up to date with the latest stable in the SDK’s update center. (Tools->Plugins or something like that.)



I don’t know what’s going wrong but having this information will help the people that might have an idea.

No problem. Just ran “Check updates” and all seems to be up to date. The plugins tool lists my jMonkeyEngine3 Library as: Version: 3.0.0.9083.



To further verify the issue I just coded in a quick switch to swap the materials on all spawned objects from unshaded to Lighting based materials and vice versa, and took some before and after screenshots:



Unshaded material:





Lighting material:





The wire frames of course being the physics debug shapes, just to make sure they are still there.



Thanks again for the help.

Ooooh… I just noticed you are using a box model instead of a regular JME box.



It’s quite possible that your model is complicit in this. Does it have normals?

1 Like

Ha! You are absolutely right. For anyone running into this in the future, it turns out checking “High quality normals”, is not the same as checking “Normals” in the .obj export dialog in Blender. Hopefully that helps someone in the future.



Thank you once again, pspeed, for the quick and informed troubleshooting.