Weird lighting bug involving the order that assets are loaded

Troubleshooting General Help
1

Ive only discovered this to be the case with the ninja and the car, and the only reason i realized it was happening was because i was using them as test assets.

Bassicaly, if you load the ninja asset, then the car asset (from jme3-testassets), the lighting works fine, however if you load the car first then the ninja, the car’s material goes haywire and is much brighter than it should be. (or maybe the car is supposed to be that bright looking, and its too dark the other way around, not sure)

Loading ninja first (looks fine): http://i.imgur.com/Tsz5pKh.png

Loading car first (lighting issue): http://i.imgur.com/RoTirku.png

this is the code i used to construct the scene, only difference between to the two screenshots is swapping makeCar() and makeNinja() around. also outright removing makeNinja() will make the car appear very bright.

[java]
public class TestModelOrder extends SimpleApplication {

    public static void main(String[] args) {
            TestModelOrder app = new TestModelOrder();
            app.setShowSettings(false);

            app.start();
    }

    Node ninjaNode = new Node();
    Node carNode;

    @Override
    public void simpleInitApp() {
            AmbientLight al = new AmbientLight();
            al.setColor(ColorRGBA.White.mult(3));
            DirectionalLight dl = new DirectionalLight();
            dl.setColor(ColorRGBA.White.mult(2));
            dl.setDirection(Vector3f.UNIT_Y.negate().subtractLocal(Vector3f.UNIT_X).normalizeLocal());

            rootNode.addLight(al);
            rootNode.addLight(dl);

            makeCar();
            makeNinja();

    }

    private void makeCar() {
            carNode = (Node) assetManager.loadModel("Models/Ferrari/Car.scene");
            carNode.setLocalTranslation(-1, 0, 0);
            rootNode.attachChild(carNode);
    }

    private void makeNinja() {
            Spatial ninja = assetManager.loadModel("Models/Ninja/Ninja.mesh.xml");
            BoundingBox bounds = (BoundingBox) ninja.getWorldBound();
            ninja.setLocalScale(1.8f / (bounds.getYExtent() * 2));

            this.ninjaNode.attachChild(ninja);
            this.ninjaNode.setLocalTranslation(1, 0, 0);
            rootNode.attachChild(ninjaNode);
    }

}
[/java]

1 Like
2

I can confirm this. at it seems, makeNinja() removes the ambient light somehow…

rootNode.getWorldLightList() looks ok.

3
@zzuegg said: I can confirm this. at it seems, makeNinja() removes the ambient light somehow..

rootNode.getWorldLightList() looks ok.

Did you check the colors of the lights in the list, too?

I wonder if the car’s environment is doing something strange as the .scene file sets ambient to black. I’d have thought that would be ignored.

The other usual suspect (tangents) doesn’t seem to be at play here either but it’s always worth a try, I guess.

4

At least the result from a quick println debug looks identical. If you remove the directional light you would don’t see anything. The ambientlight is not rendered at all as it seems.

Tried the tangentgenerator too, no changes.

5

Add:

If you convert the ninja to j3o and load from that the issue is gone.

6

so the car supposed to look that bright/washed out with that lighting configuration, and somehow loading the ninja ogre file before it alters the lighting to look darker?

i feel like the darker tone matches better with how light is interacting with other stuff that would be in the scene. It almost looks like the brighter version is an unshaded material (which was the first thing i checked when i first discovered this)

its kind of hard to judge whats going on here as theres no baseline.

I havent had a chance to look at this again since i posted. im thinking it could help to home in on things to create a cube or teaport and then add a material to it with the same material/material parameters as the car chasis to compare it’s lighting appearance. (the car chasis contains a number of parameters IIRC, its not just a diffuse color and diffuse tex). I’ll try to do some expirementation on this too sometime in the next day or so.

7

From looking at the .scene file, I think the darker car is accurate to the original intent. I just don’t know if JME pays attention to the parts of the .scene that would have set ambient to black for that car.

8

quite interestingly. apparently both ninja and car dont even work with ambient lights period. if you remove the directional light, but not the ambient and just load the the ninja or the car (or both) you dont see anything. If you convert them to j3o they are visible with just ambient light

to fix the car issue overall, I removed the “environment” section of the Car.Scene and converted it to j3o, im going to do the same for the ninja for as long as i use it for a test asset just to stay away from the weirdness that is the ogre importer.

(still couldnt figure out why the ninja was impacting the car like so, clearly theres a bug/s in the ogre exporter causing several oddities)

9

That’s a weird issue…
If there is an issue in the ogre importer why would the order matter?
anyway. I keep this issue in the todo, maybe there is something more serious about it.

10

Turns out this is a valid bug. Originally I thought it was the renderer screwing up, but actually it is the material loader state not being reset between each material being loaded, so the black ambient color from the ninja was leaking onto the car which did not specify an ambient color.

11

That’s also why the normal process of converting assets to j3o before using them worked, I guess.