Issues in the jgltf-viewer example

[wolfgang-ch]

I'm very new to understand glTF/JglTF (2.0.3), so I tried to test this simle example https://github.com/javagl/JglTF/tree/master/jgltf-viewer with the Lwjgl platform.

Part of the duck is displayed but there are some issues in the log, how can these issues be solved?

Oct 22, 2022 10:34:15 AM de.javagl.jgltf.viewer.AbstractGltfViewer createRenderedGltf
INFO: Creating rendered glTF
Oct 22, 2022 10:34:15 AM de.javagl.jgltf.viewer.DefaultRenderedGltfModel lambda$createUniformSettingCommands$6
WARNING: No valid texture model found for uniform u_metallicRoughnessTexture: null
Oct 22, 2022 10:34:15 AM de.javagl.jgltf.viewer.DefaultRenderedGltfModel lambda$createUniformSettingCommands$6
WARNING: No valid texture model found for uniform u_normalTexture: null
Oct 22, 2022 10:34:15 AM de.javagl.jgltf.viewer.DefaultRenderedGltfModel lambda$createUniformSettingCommands$6
WARNING: No valid texture model found for uniform u_occlusionTexture: null
Oct 22, 2022 10:34:15 AM de.javagl.jgltf.viewer.DefaultRenderedGltfModel lambda$createUniformSettingCommands$6
WARNING: No valid texture model found for uniform u_emissiveTexture: null

[javagl]

The PBR-based rendering has never been fully implemented. The 'warnings' are not critical, but of course, they should not appear if everything was implemented correctly.

This is mentioned in the main README:

The libraries that are available here mostly support glTF 1.0 and glTF 2.0. Some special features that have been introduced in glTF 2.0 are not fully supported yet. This mainly refers to rendering glTF 2.0 assets in the jgltf-viewer, particularly the support of PBR (physically based rendering) and certain animation interpolation types. Support for these features will be implemented soon.

Now, the statement that this 'will be implemented soon' turned out to be wrong. It has been that way for several years now.

Iff I had the chance to try and implement full PBR support, I'd start with porting the https://github.com/KhronosGroup/glTF-Sample-Viewer to Java. But this would mean several weeks (or a few months) of unpaid work, so I cannot tackle this now ... unless I win the lottery or so.

[wolfgang-ch]

Thanks for the information

[wolfgang-ch]

I've found an alternative Java gltf2 loader + animation viewer https://github.com/MESLewis/SimpleGLTF2 which had used the same porting base (according to the readme) glTF-Sample-Viewer you also would use

https://user-images.githubusercontent.com/1283445/197697948-f2b8aa78-3b51-4d9e-a35c-a61afba4abc9.mp4

The above duck is displayed correctly

[javagl]

I have not yet looked at the SimpleGLTF2 repository. From a quick glance, it seems like that there have been ~100 commits, but all of them have been done within one week, ~3 years ago, and no activity since then. It looks like it is not really actively maintained and developed.

(I know, JglTF is also not very "active" in this regard, but I occasionally carve out a bit of time to work on it, and there are some larger updates/extensions "in the pipeline" of which I hope that I can finalize them at some point...)

Looking at the last comment in the issue in mytourbook, I have to emphasize: The current jgltf-viewer implementation is not a solid basis for applications!!!. I implemented this several years ago, originally only for glTF 1.0. And there, it worked quite well. This includes the important abstraction layer for JOGL and LWJGL (and there are even (experimental) abstractions for Android-based rendering). But when you look at the glTF-Sample-Viewer, you will see that the shaders for proper Physically-Based Rendering are rather complex.

Most rendering engines on the web, like three.js and babylon.js, already have Physically-Based Rendering and material models. So it made sense for glTF to use this model as the common denominator. But implementing this rendering functionality from scratch is a lot of work.

The only Java-based rendering engine that I'm aware of and that may already contain much of that functionality is jMonkeyEngine. They do have glTF support, as of https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-examples/src/main/java/jme3test/model/TestGltfLoading.java , but I don't know many technical details here. It may still be worth a look for you in the context of mytourbook.

But as an aside: The issue in mytourbook that you linked to looks interesting, so I may try to have a closer look at mytourbook as well...

[wolfgang-ch]

Yesterday I discovered, that LibGDX is also supporting glTF2. LibGDX is the base app for the 2.5D map but I also discovered that the required libGDX 1.9.11 is not yet supported by the map, it is based on libGDX 1.9.10. When I try to raise the version number to 1.9.11 then compile errors occure in https://github.com/mapsforge/vtm

2 days ago I also discovered jMonkeyEngine to support glTF2 but such a big engine may be too much what I want. MyTourbook is not a game, I just want that an animated figure can be moved along a tour track and for this, SimpleGLTF2 seems to be what I want for now.

[wolfgang-ch]

but all of them have been done within one week,

It was about 4 weeks of work

After testing some other glTF2 examples from https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0 some examples are only partly corretly displayed.

[javagl]

'papsforge/vtm' - another library that I should have had on the radar. Any plans to integrate 3D Tiles there? 😁

However, when you mention that not all models are displayed properly, then this might be caused by certain more sophisticated features. Earlier, you mentioned an "animated figure", which sounds like https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/CesiumMan , and if that works, then that could be a start (although this involves skinning, and from my observations, that's what most implementations seem to struggle with...)

[wolfgang-ch]

Any plans to integrate 3D Tiles there? 😁

Since 9 years, the NASA 3D map https://worldwind.arc.nasa.gov/java/ is integrated into MT https://mytourbook.sourceforge.io/mytourbook/index.php/documentation/show-tours/3d-map

This was 2 years before CesiumGS 3D started

Yesterday I tested some glTF examples with jMonkeyEngine and all worked as they should 😉

[javagl]

WorldWind is one of the projects that I already stumbled over quite a while ago, but I did not actively follow its development. I probably should have done that. And am somewhat surpised to see that they made a new release a few months ago, even though the project was said to be shut down...

WorldWind didn't doesn't support 3D Tiles, but ... maybe I should have a closer look at it, to see whether there's a reasonable way to integrate my (currently 'private') project called j3dtiles into that ...

(BTW: NASA also published https://github.com/NASA-AMMOS/3DTilesRendererJS a while ago)

Yesterday I tested some glTF examples with jMonkeyEngine and all worked as they should

That's good to hear. You know, on the one hand I think that it could be nice to have a project like the jgltf-viewer as a small, standalone, easy-to-use glTF viewer (for JOGL, LWJGL, Android...). On the other hand, people will then probably say: "Yeah, nice model. Now I want to draw coordinate axes, or some arrows, or apply a different color to one part of the model ..." - And ... that's the start of creating the greatest, most universally applicable, most versatile (and most complex) "small, standalone, easy-to-use viewer" in the world... 😕

[wolfgang-ch]

After jMonkeyEngine is also running an OpenGL main loop https://github.com/jMonkeyEngine/jmonkeyengine/issues/1862#issuecomment-1304867545, the code had to manage 2 different main loops -> too complicated for now

I will try now plan B by using https://github.com/mgsx-dev/gdx-gltf, libGDX is already the OpenGL main loop in my app

[javagl]

I don't understand all the technical aspects here, because I'm not really familiar with jMonkeyEngine. But when it is already using LWJGL, then I don't see why there should be "two main loops". Usually, everything that is related to OpenGL has to happen on the same thread. What exactly are the "different main loops" that you mentioned?

[wolfgang-ch]

I wanted to implement the animation with jME in my 2.5D map which is using libGDX as backend, so the main loops would be in jME and libGDX

[javagl]

I'll probably not be able to say anything profound or constructive here, as long as I didn't read more about the thread management and implementation of jME, and how it interacts with the underlying OpenGL binding. From what I understood so far, on a very shallow level, the scenario could be described with the pesudoest pesudocode ever:

class YourApplication {

    // The jME main loop, started and run by jME,
    // in a thread that is dedicatedly created by jME:
    void jmeMainLoop() {
        while (true) {
            jme.updateEverything();
            // This will trigger the rendering, which is doing the 
            // operations that are done on the "OpenGL thread"
            jme.triggerRendering();
        }
    }

   // LibGDX: The same, with 'libgdx' instead of 'jme' everywhere :-) 
}

So there are two threads that are running the jme.updateEverything() and libgdx.updateEverything() methods. These methods are supposed to represent things like "updating the positions of models", or "doing collision detection" etc. (Everything that has to happen each frame, but is not tied to the OpenGL thread)

A crucial question here is how the libGDX- and jME-rendering are intertwined on the OpenGL-thread. But assuming that there is something like

// This is called on the OpenGL thread, and does 
// the rendering operations from jME and libGDX:
void renderEverything() {
    jme.render(); 
    libgdx.render();
}

then I think the question of "where the animation is implemented" should not mater so much.

But again, I know this is a very naive and shallow way of looking at this, and that there are a bazillion caveats that are not reflected in this pseudocode...

[wolfgang-ch]

I'm now using https://github.com/mgsx-dev/gdx-gltf to load and rund glTF animations

The animation renderer is now integrated into the map renderer. This code contains still a lot of debug code which needs to be cleaned up when all is working.

https://github.com/mytourbook/mytourbook/blob/6c590780b31c569597697939ba6d18af72198f78/bundles/net.tourbook/src/net/tourbook/map25/animation/GLTFModel_Renderer.java#L279-L280

https://user-images.githubusercontent.com/1283445/204142511-ec7aabda-ea9e-4c7e-9b27-bf0db7f9ed08.mp4

https://github.com/mytourbook/mytourbook/issues/516#issuecomment-1328267295

[javagl]

Thanks for the pointer. The gltf subdirectory of library that you linked to looks like a "plain" structure of the elements in glTF 2.0. And and it appears that there is a general PBR material model. This seems to be part of libGDX, and the library ""only"" fills that PBR model with data from glTF, but I haven't looked at the surrounding infrastructure (like https://github.com/mgsx-dev/gdx-gltf/blob/master/gltf/src/net/mgsx/gltf/loaders/shared/material/PBRMaterialLoader.java and such) in all depth.

As long as this offers the sought-for functionality of easy loading, animating and rendering in the context where you need it, the implementation details may not matter.

(I considered closing this issue - but keeping it open, as a reminder that "the gltf-viewer does not support PBR" is fine, I guess...)

[wolfgang-ch]

As long as this offers the sought-for functionality of easy loading, animating and rendering in the context where you need it, the implementation details may not matter.

For now I'm very happy with gdx-gltf code 😄