[Rj Zondervan]

After playing around a bit I managed to solve the problem of the bogies: they were ignored as bogies if I didn't attach them to the root object before all other parts.
This also solves the alleged Z-fighting, as seen in the video below:
https://youtu.be/kc8gFd2x3L4

Now only remains that the second bogie of the luggage car behaves a bit clunky, it sort of looks like it tries to move in unison with the front bogie, and looks like it derails because of that.

@Peter, if it is of any help I will send over this corrected file to you once I have also corrected the last parts of the engine.

[gpz]

I have just committed a modification where I tried to sort out the bogie and wheel assignments. I also inverted the bogie animation, because your original car seemed to work correctly with inverted turning, but I'm not sure I did it right, because again I am not sure if it was the code doing it wrong previously or the model needed to be corrected. I need more testing. Btw I was able to make the bogie work in your previous model too, the problem is that your animation linked the root node too:

  "animations": [
    {
      "channels": [
        {
          "sampler": 0,
          "target": {
            "node": 0,
            "path": "translation"
          }
        },
        {
          "sampler": 1,
          "target": {
            "node": 2,
            "path": "translation"
          }
        },
        .
        .
        .

The problem is with the first channel with the target node 0. When I deleted that, everything started to move, although in the wrong direction: the wheels backwards, the bogies to the wrong side.

Are you using the gltf convention of +Z is forward in your models? Could you create a model of the car where you double-check if everything is using +Z forward, +X left, +Y up, both the frame, the bogies, the wheels? I could use that as a reference to check if every externally managed animation is turning in the right direction. I can test the animation clips with the Khronos-provided reference models, but I have only your model to test the openrails specific animations yet.

EDIT: Sorry, I have to revoke my last commit, because that is broken. :-( Tomorrow I will try again.

EDIT2: Found the problem, committed again.

[Genma Saotome]

 wacampbell, on 26 January 2023 - 06:54 AM, said:

.gltf is a perfect fit for Open Rails for so many reasons. Keep up the good work on this.

Wayne
Open Rails Founder

Please explain. I looked at the diagram and was able to take a guess at only 10% of what was there.

[Rj Zondervan]

 gpz, on 27 January 2023 - 11:14 AM, said:

I have just committed a modification where I tried to sort out the bogie and wheel assignments. I also inverted the bogie animation, because your original car seemed to work correctly with inverted turning, but I'm not sure I did it right, because again I am not sure if it was the code doing it wrong previously or the model needed to be corrected. I need more testing. Btw I was able to make the bogie work in your previous model too, the problem is that your animation linked the root node too:

  "animations": [
    {
      "channels": [
        {
          "sampler": 0,
          "target": {
            "node": 0,
            "path": "translation"
          }
        },
        {
          "sampler": 1,
          "target": {
            "node": 2,
            "path": "translation"
          }
        },
        .
        .
        .

The problem is with the first channel with the target node 0. When I deleted that, everything started to move, although in the wrong direction: the wheels backwards, the bogies to the wrong side.

Are you using the gltf convention of +Z is forward in your models? Could you create a model of the car where you double-check if everything is using +Z forward, +X left, +Y up, both the frame, the bogies, the wheels? I could use that as a reference to check if every externally managed animation is turning in the right direction. I can test the animation clips with the Khronos-provided reference models, but I have only your model to test the openrails specific animations yet.

EDIT: Sorry, I have to revoke my last commit, because that is broken. :-( Tomorrow I will try again.

EDIT2: Found the problem, committed again.

Hi Peter,

The model was the wrong way around, when I started work on them, and named the parts I was still using the 'old' MSTS convention with the -Z as forward, and because it is a carriage I didn't notice on export. In the new export I turned the carriage around also to correct this. I sent the corrected model in direct messages just yet.

[gpz]

Looks like the existing viewers have problems with the gltf-s having "../" in their texture paths. Historically the the MSTS content looks like this:

TRAINS
|–TRAINSET
   |–SHAPES – this folder may contain the .gltf file
   |–TEXTURES – this folder may contain the texture files

However with this structure the gltf needs to refer its textures by e.g. "../TEXTURES/sometexture.png". Although this can easily be supported within Openrails, but the existing gltf viewers have problems with displaying such a model. This includes

• the Windows built-in "3D Viewer" app,
  
• the VS Code's "glTF Tools" extension with all four engines: Babylon.js, Cesium, Filament, Three.js,
  
• the online Khronos glTF Sample Viewer,
  
• all the other online viewers I've checked so far.

Because of this I am thinking on invalidating this scenario for gltf-s. So the textures of the gltf-s will be needed to be stored either in the .gltf file's folder or in that folder's subfolder. What do you think?

[pwillard]

 gpz, on 31 January 2023 - 02:51 AM, said:

Looks like the existing viewers have problems with the gltf-s having "../" in their texture paths. Historically the the MSTS content looks like this:

TRAINS
|–TRAINSET
   |–SHAPES – this folder may contain the .gltf file
   |–TEXTURES – this folder may contain the texture files

However with this structure the gltf needs to refer its textures by e.g. "../TEXTURES/sometexture.png". Although this can easily be supported within Openrails, but the existing gltf viewers have problems with displaying such a model. This includes

• the Windows built-in "3D Viewer" app,
• the VS Code's "glTF Tools" extension with all four engines: Babylon.js, Cesium, Filament, Three.js,
• the online Khronos glTF Sample Viewer,
• all the other online viewers I've checked so far.

Because of this I am thinking on invalidating this scenario for gltf-s. So the textures of the gltf-s will be needed to be stored either in the .gltf file's folder or in that folder's subfolder. What do you think?

As an OPEN railsim... we should be adapting to OPEN standards, no? If using NEW formats, you would adapt to new requirements (or we continue to remain firmly stuck in 2001)

[ErickC]

 gpz, on 31 January 2023 - 02:51 AM, said:

Because of this I am thinking on invalidating this scenario for gltf-s. So the textures of the gltf-s will be needed to be stored either in the .gltf file's folder or in that folder's subfolder. What do you think?

That would break compatibility with models already using texture paths, as a majority of mine do. So I vote no. There's no reason that MSTS auxiliary tools should hold OR back - the TSRE shape viewer reads texture paths just fine.

[gpz]

It wouldn't break anything, because it applies only to gltf models (as I wrote), and there are no gltf models exist for Openrails yet.

[wacampbell]

 gpz, on 31 January 2023 - 02:51 AM, said:

... This includes

• the Windows built-in "3D Viewer" app,
  
• the VS Code's "glTF Tools" extension with all four engines: Babylon.js, Cesium, Filament, Three.js,
  
• the online Khronos glTF Sample Viewer,
  
• all the other online viewers I've checked so far.

Because of this I am thinking on invalidating this scenario for gltf-s. So the textures of the gltf-s will be needed to be stored either in the .gltf file's folder or in that folder's subfolder. What do you think?

This is a good catch and now is the time to address it. Open Rails must leverage all the outside tools we can. We don't have the resources to develop every tool we need. The proposed restriction in directory structure only applies to .gltf models and won't impact those who want to continue to use .s shape file based models. I think your proposal is reasonable.

[pwillard]

I get it... it's different. And it might change how we do things.

The ONLY way forward is that we have 2 side by side options for file formats. (It's not impossible as even TRAINZ does this... They accept legacy IM format without PBR support as well as modern-day FBX format that supports PBR. I mean in reality, TRAINZ literally breaks backward compatibility and content rules with EVERY release) Surely we can get past the limitations of MSTS at some point while also *accepting* the old formats as legacy support. Modern TRAINZ also converts legacy format files to Modern format behind the scenes... which we could do as well. It's not easy... I understand that.

Doesn't TSRE support it? Ok, we have the source so at least there is hope to ADD support for something new. GLTF is also an accepted International standard so tools and source code exist for post-processing without leaving us high and dry.

With TSRE being essentially abandoned now.... maybe we need to look deeper into integrating its capabilities into ORTS. Or what? Do we just give up on any improvements? That's a sure way to lose supporters knowing that things will never get better.