Model loaded from glb displayed incorrectly


I’m a newbie in jmonkeyengine. Here’s an issue I encountered recently:

I loaded a model from threejs example: three.js examples

Code as following:

	public void simpleInitApp() {
		soldier = assetManager.loadModel("Models/Soldier/Soldier.glb");

	private void setUpLight() {

		AmbientLight al = new AmbientLight(ColorRGBA.White.mult(2f));

		DirectionalLight dl = new DirectionalLight();
		dl.setDirection(new Vector3f(1f, -1f, -1f).normalizeLocal());

		DirectionalLight dl2 = new DirectionalLight();
		dl2.setDirection(new Vector3f(-1f, 1f, 1f).normalizeLocal());

However, it looks the model doesn’t appear correctly where mesh is broken…(screenshot attached). More strangely, sometimes it appears correctly when I tried to enable/disable lights in my code. I don’t understand why lights may affect model mesh…any enlightenment?

1 Like

Two things:

  1. Part of the problem may be with “Soldier.glb”. The three.js site says it is from Mixamo, but Mixamo doesn’t provide models in GLB format, so someone must’ve converted it. Where did you get the GLB file from?

  2. Another part of the problem may be that the model uses PBR materials. In order for PBR materials to display properly, a LightProbe should be added to the rootNode. Ideally, the light probe should be customized to your 3-D scene. However, there’s a sample light probe included in jme3-core to get you started. Here’s how to use it:

        Spatial probeSpatial = assetManager.loadModel("defaultProbe.j3o");
        LightList lightList = probeSpatial.getLocalLightList();
        LightProbe defaultProbe = (LightProbe) lightList.get(0);

I hope that helps!

1 Like

Thanks for the reply.

I downloaded the glb directly from threejs example:

source code

loader.load( 'models/gltf/Soldier.glb', function ( gltf ) {

After adding your LightProbe code, I got following error:

com.jme3.asset.AssetNotFoundException: defaultProbe.j3o

Then I downloaded defaultProbe.j3o from jme3-testdata and copied it into my project. Now I have this result which is not very different from the previous one.

Btw, After a few tests, I was able to get the correct result once I have all three lights enabled regardless I added the defaultProbe or not. However, if I disabled one light (not adding it into rootNode), I got the issue.

1 Like

Here’s the screenshot when I have the correct result with defaultProbe added:


That is very strange behavior.

I pasted the GLB file from three.js into the Khronos glTF validator, which reported 1315 errors.

Perhaps try a different model?

I imported another model from here:
Looks good. Maybe the soldier one indeed is problematic.

However, one more question. It seems the AmbientLight doesn’t work for either Soldier or the above one. They’re always black until I added DirectionalLight. Any idea…?

1 Like

With PBR materials, ambient light modulates the light probe, so this could be an issue with the ambient light or the light probe.

  1. What’s the color of the ambient light?
  2. Is the model within the probe area of the light probe?

What’s the color of the ambient light?


Is the model within the probe area of the light probe?

I’m fairly new in 3D. In my extremely limited knowledge, ambient light literally means everywhere…so maybe some links on what is light probe and how it should work?

1 Like

It’s my bedtime.
Could someone please assist @azuresu with troubleshooting?


Here is a tech paper from the nehon that implemented pbr in jme:

Part three should cover light probes.

As a summary, PBR tries to do all light calculations as realistic as possible. Ambient light as used in Phong shading does not exist in the real world. Ambient light in the real world is the indirect lighting coming from light bouncing of other objects. Even at night you have indirect lighting that comes from the sun light bouncing of the moon.

The light probe tries to capture that indirect lighting. And it requires an area because it is exact only for the place it is beeing calculated, but can be interpolated to be plausible for a larger area.

Unfortunately the lightprobes are quite expensive to calculate and it is still an area of active research on ways to calculate indirect lighting at all.

1 Like

Thanks to @sgold and @zzuegg!

So let me rephrase it in a simplified way: Ambient light does NOT work for PBR material. Am I correct?

In addition to the light issue, I found the Soldier model worked extremely weird in my test. I added another gltf model from threejs:

And here’s the code:

public class HelloSoldier extends SimpleApplication {

	public void simpleInitApp() {
		Spatial soldier = assetManager.loadModel("Models/gltf/Soldier.glb");
		Spatial xbot = assetManager.loadModel("Models/gltf/Xbot.glb");

	private void setUpLight() {
		DirectionalLight dl = new DirectionalLight();
		dl.setDirection(new Vector3f(0f, -0.5f, -1f).normalizeLocal());

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

By playing comment/uncomment out rootNode.attachChild(soldier) and rootNode.attachChild(xbot), I got correct result sometimes but in most time, I have broken results when soldier is attached:

Like @sgold mentioned, Soldier model in threejs could be broken indeed. Or it’s a problem in jme loader?

What I don’t understand is why I can get correct result sometimes.

The reproduce steps are something like:

  1. Remove (or comment out) load and attach for both then run first;
  2. Add load and attach for Soldiar then run, I get correct result in most of times;
  3. Add load and attach for Xbot then run, I get correct result in most of times;
  4. All subsequent runs give me same broken result even without any code change. I have to go back to step 1 to get correct result.

Btw, I’m using IntelliJ and maven, not jMonkeyEngineSDK. Not sure if there’s any pitfall related with my environment.

1 Like

Ambient light does NOT work for PBR material. Am I correct?

That depends what you mean by “work”.

Ambient light affects different materials differently. On Phong-shaded materials, the effect of ambient light is proportional to the ambient color of the material. In a similar fashion, ambient light (if present) amplifies some aspects of a PBR material and not others.

And here’s the code:

The portion of your code you’ve shared with us doesn’t add a light probe, nor does it add ambient light.

When working with PBR materials, my advice is to include all 3 kinds of light in your test scene: ambient, directional, and probe.

What I don’t understand is why I can get correct result sometimes.

I don’t understand that either, but I can imagine many possibilities.

If the Soldier model is defective, it could have incorrect bounding boxes or incorrect normals or incorrect triangle windings. There are many possibilities.

Perhaps you should work with a known-good model until you’re more familiar with the workings of JMonkeyEngine.

I’m using IntelliJ and maven, not jMonkeyEngineSDK. Not sure if there’s any pitfall related with my environment.

Many people use JMonkeyEngine with Intellij and/or Maven. I doubt either of those is causing the difficulties you’re seeing.

is this possible that you try GLTF not GLB here?

If this is a mixamo model, perhaps @azuresu is suffering from Issue 2055? That might explain why the model appears stretched.

1 Like

Thanks to everyone here. The reason I’m using models from threejs is that animations there are much better than the one we have in jme documentation (sorry :stuck_out_tongue:, just try to learn animation a bit deeper). But for now I will follow @sgold suggestion to put this issue aside and try to get more familiar with jme with proved models. :slight_smile:


The Mixamo models are very nice, but importing them into JMonkeyEngine is tricky. I’m working to improve that process.


I’ve imported the Mixamo model in question and uploaded it to GitHub:

I hope that helps!


Sorry, I just noticed it. Thanks! I will definitely try the tool.

1 Like