GltfLoader issues

The recent changes to the GLTF loader have introduced several problems:

1. Duplicate Controllers: The new loader creates duplicate AnimComposer and SkinningControl controllers for each geometry in the model. (see here)
2. Nested Geometry: Each geometry is now encapsulated within two parent nodes, which can complicate scene hierarchy management.
3. Backward Compatibility: These changes may cause compatibility issues with existing code that relies on the previous behavior of the GLTF loader. (see here)

Other issues reported by adi.barda: (see here)

• Blured colors - maybe normal map is missing?
• Sometime missing animations - maybe related to 1

Please provide detailed instructions for reproducing this issue. Has anyone identified which recent changes caused this issue?

Maybe this: https://github.com/jMonkeyEngine/jmonkeyengine/pull/2103

Would reverting 2103 solve this issue?

Would reverting 2103 solve this issue?

Probably yes.

Please provide detailed instructions for reproducing this issue.

Here is the 3D Model for the test file

jME-3.7.0

jME-3.6.1-stable

Using a simple test app, I showed that the issue of YBot loading with multiple AnimComposers pre-dates PR 2103. I'll do a bisection search to find where the issue was introduced.

Here is the test app:

import com.jme3.anim.AnimComposer;
import com.jme3.app.SimpleApplication;
import com.jme3.scene.Node;
import com.jme3.scene.Spatial;
import com.jme3.scene.control.Control;
import com.jme3.scene.plugins.gltf.GltfModelKey;
import java.util.List;

public class TestYBot extends SimpleApplication {

    public static void main(String[] args) {
        TestYBot app = new TestYBot();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        GltfModelKey modelKey = new GltfModelKey("YBot.gltf");
        Spatial modelRoot = assetManager.loadModel(modelKey);
        int numComposers = countControls(modelRoot, AnimComposer.class);
        System.out.println("numComposers = " + numComposers);
        stop();
    }

    /**
     * Count all controls of the specified type in the specified subtree of a
     * scene graph. Note: recursive!
     *
     * @param <T> subclass of Control
     * @param subtree the subtree to analyze (may be null, unaffected)
     * @param controlType the subclass of Control to search for
     * @return the count (&ge;0)
     */
    private static <T extends Control> int countControls(
            Spatial subtree, Class<T> controlType) {
        int result = 0;

        if (subtree != null) {
            int numControls = subtree.getNumControls();
            for (int controlI = 0; controlI < numControls; ++controlI) {
                Control control = subtree.getControl(controlI);
                if (controlType.isAssignableFrom(control.getClass())) {
                    ++result;
                }
            }
        }

        if (subtree instanceof Node) {
            Node node = (Node) subtree;
            List<Spatial> children = node.getChildren();
            for (Spatial child : children) {
                result += countControls(child, controlType);
            }
        }

        return result;
    }
}

The issue was introduced by PR #2060.

With "master" branch at f915e56, the test app prints numComposers = 1. With "master" branch at 4c87531, the test app prints numComposers = 2.

2. Nested Geometry: Each geometry is now encapsulated within two parent nodes, which can complicate scene hierarchy management.
3. Backward Compatibility: These changes may cause compatibility issues with existing code that relies on the previous behavior of the GLTF loader. (see here)

As pointed out in the pr https://github.com/jMonkeyEngine/jmonkeyengine/pull/2103 , this is to solve several issue and inconsistencies with the scenegraph of imported models , it is not backward compatible, but the previous behavior was bugged and source of issues

The current behavior, with multiple anim composers per model, is clearly bugged. And that change appears to be unrelated to PR 2103.

I think there's just one unsolved piece to this issue: the "blurred colors" change, which occurred between v3.6.1-stable and v3.7.0-beta1.2.2. @scenemax3d sent me a copy of his test app, which I've now run with both releases. I hope to use a bisection search to identify the commit(s) that caused the change.

I simplified the test app so it doesn't require Minie:

package jme3test;

import com.jme3.app.SimpleApplication;
import com.jme3.light.AmbientLight;
import com.jme3.light.DirectionalLight;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Quaternion;
import com.jme3.math.Vector3f;
import com.jme3.scene.Node;
import com.jme3.scene.Spatial;
import com.jme3.shadow.DirectionalLightShadowRenderer;
import com.jme3.system.AppSettings;

public class TestApp extends SimpleApplication {

    public static void main(String[] args) {
        TestApp app = new TestApp();
        app.showSettings = false;
        AppSettings settings = new AppSettings(true);

        settings.setWidth(1024);
        settings.setHeight(768);
        settings.setGammaCorrection(false);
        settings.setSamples(4); // anti-aliasing
        settings.setVSync(true);
        app.setSettings(settings);
        app.start(); // start the game
    }

    @Override
    public void simpleInitApp() {
        flyCam.setDragToRotate(true);
        cam.setLocation(new Vector3f(5.809729f, 3.3733122f, 4.834249f));
        cam.setRotation(new Quaternion(0.0018560609f, 0.9064233f, 0.0039831875f, -0.42234766f));

        loadModel1();
        addLighting();
    }

    private void addLighting() {
        DirectionalLight sun = new DirectionalLight();
        sun.setColor(ColorRGBA.White);
        sun.setDirection(new Vector3f(-0.1f, -0.7f, -1.0f));
        rootNode.addLight(sun);

        final int SHADOWMAP_SIZE = 1024;
        DirectionalLightShadowRenderer dlsr = new DirectionalLightShadowRenderer(assetManager, SHADOWMAP_SIZE, 3);
        dlsr.setLight(sun);
        viewPort.addProcessor(dlsr);

        AmbientLight al = new AmbientLight();
        al.setColor(ColorRGBA.White.mult(0.3f));
        al.setEnabled(true);
        rootNode.addLight(al);
    }

    private void loadModel1() {
        Spatial mm = assetManager.loadModel("Models/boss/boss.gltf");
        final Node model = new Node();
        model.attachChild(mm); // add it to the wrapper
        mm.scale(3f, 3f, 3f);
        rootNode.attachChild(model);
    }
}

The "blurred colors change" had already occurred as of efbcd03 (29 May 2023 in the "master" branch), which means it wasn't related to PR #2060.

It hadn't occurred yet as of fec08b3f (11 Feb 2023 in the "master" branch). So now I've got a 15-week window to search...

The "blurred colors" change resulted from integrating PR #1980 into "master" branch on 11 March 2023. The colors are sharp at f51681a but not at f771f9b.

Here's how the test model looked in v3.6.1-stable:

And here's how it looks at 5f54eb2 (current "master" branch):

I don't understand the shader code in PR #1980, so I can't say whether it's correct or not. However, I believe the appearance of the test model with v3.7.0-beta1.2.2 is actually more correct than with v3.6.1-stable. In support of this belief, here is how the model looks in the glTF viewer at https://gltf-viewer.donmccurdy.com/ :

Note the smoothness of the skin on the model's face and arms. Allowing for differences in lighting and perspective, McCurdy's viewer renders the model a lot like JME's "master" branch and much less like JME v3.6.1-stable . I suspect this is because v3.6.1-stable ignores glTF texture scaling.

The test model makes extensive use of texture scaling. For instance, the "Skin_MAT" material is defined in the glTF as:

            "doubleSided" : true,
            "name" : "Skin_MAT",
            "normalTexture" : {
                "index" : 0,
                "scale" : 0.1400168091058731,
                "texCoord" : 0
            },
            "pbrMetallicRoughness" : {
                "baseColorTexture" : {
                    "index" : 1,
                    "texCoord" : 0
                },
                "metallicFactor" : 0,
                "roughnessFactor" : 0.6278957724571228
            }

In the current "master" branch, if I increase the scaling of the Skin_MAT normal texture (from 0.1400168091058731) to 1.0, the model's arms look about like they did in v3.6.1-stable:

which is what one would expect if v3.6.1-stable were simply ignoring texture scaling.

@scenemax3d: The bottom line: I believe the "blurred colors change" is a feature and an improvement, not a regression. If there are no other serious issues with the v3.7 branch, then it's ready for a stable release.

Also, this issue should probably be closed.

@stephengold I think there are much more details in the v3.6 version - the muscles, the clothing, face, everything but maybe as you say being it viewed more detailed (v3.6) is a bug? and the way it is rendered in v3.7 is actually the correct way.. Now , thanks to your investigation, we know the commit that caused this feature-bug and we can discuss it further later. I will move v3.7 to stable ASAP

@scenemax3d I would describe the enhanced details in v3.6 renders as a defect: those details don't reflect the intent of the artist who created the model.

If for your games you desire a model with exaggerated wrinkles, veins, and muscles, you can easily edit the glTF file in a text editor to tune the scaling of the relevant normal texture(s).

Thank you for your efforts guys. Let me know if I can close this Issue.

Like I said:

this issue should probably be closed.