[Traindude]

 gpz, on 25 February 2023 - 02:29 AM, said:

Thanks for the test model, I will play around with it! About the bones you mentioned: I didn't find any skins (with bones and joints) in this gltf model with a text editor, but please note, skinning is already implemented in my PR. So if you used skinning and its animation for the flexible hose, that would already work.

The GLTF model (I have sent via PM) doesn't have any flexible steam pipes. It's in one of the included Blender files--"chal_test_iksteampipes.blend" It should've been included in the .zip files I linked earlier.

[Genma Saotome]

 gpz, on 25 February 2023 - 12:14 AM, said:

But how many of the models with shared textures are residing in separate directories?

You mean like locomotive and cars? My models? Very few. With models made by other persons? I've already edited them so many can be consolidated in a single directory.

 gpz, on 25 February 2023 - 12:14 AM, said:

Keep in mind, reusing textures are still possible per se. The only issue is where those textures are. Now your route is arranged in a traditional way, I assume:

MSTS/ROUTES/YourRoute/SHAPES/
MSTS/ROUTES/YourRoute/TEXTURES/

With this change you need to flatten this to (at least regarding to the gltf shapes):
MSTS/ROUTES/YourRoute/SHAPES/TEXTURES/

And you can continue to reuse all the textures.

I have no problems with that. The objection I raised was in regards to embedding the textures into the .gltf file. Did I misunderstand? I was trying to use the online viewers w/ no luck.

 gpz, on 25 February 2023 - 12:14 AM, said:

In any case you won't be able to share textures between .s and .gltf, because gltf base color textures must be in sRGB color space, while the .s textures are in linear RGB.

I don't think that would be a problem but I say that under the assumption the texture file format for the new standard is .png and/or .jpg and/or .dds; Is that correct? The IRFAN program has a batch function that will change formats and drop the resulting .png or .jpg when you specify. It'll do a couple of thousand files in a minute or two. AFAIK getting to .dds is different and AFAIK is more expensive, both in time and money.

[gpz]

I tried playing with the gltf (at this stage I don't really want to deepdive into Blender and its exporter), and I needed to make the following changes by a text editor:

1. All animations have to get their proper MSTS animation name. In the .s file one needed to name the nodes. Here one needs to name the animations. What you e.g. named as "WHEELS4Action", I needed to rename to "WHEELS4", "ROD19Action" renamed to "WHEELS", "DOOR_AAction" renamed to "DOOR_A", "ORTSBELLAction" renamed to "ORTSBELL", etc.

2. All nodes that you want to be animated by Openrails, at this stage need to be tagged by the "extras" I wrote here previously, e.g. one of the nodes look like this after the edit:

        {
            "mesh" : 10,
            "extras": { "OPENRAILS_animation_name": "WHEELS21" },
            "name" : "WHEELS21",
            "translation" : [
                0,
                0.020983219146728516,
                -1.0878195762634277
            ]
        },

I set up the code the way that naming the node is not enough (not even needed btw), mainly because at the beginning all the MSTS modellers will just name the nodes and expect they will move just like the .s file moved. But it is not the case, because nodes that are targeted by internal animations should not be tagged for Openrails-managed animation. In your case e.g. the node named as "WHEELS1" should not be tagged with "OPENRAILS_animation_NAME", because that is alredy animated in a different way, with a real animation clip.

Even with these modifications the majority of the rods are not moving correctly. I think it is because you did not include animations for all of them. Please note, it is not enough setting up constraints for them in Blender, because there are no means in the gltf to describe these constraints. You need to include keyframe animations to all of the rods. Did this work correctly by exporting to an .s file? I haven't actually changed how the animations are processed. You can debug the exported animations by the Windows built-in 3D Viewer. However you might want to merge all the rods-related animations in to a single one. There are currently 45 animations defined, as also shown in the 3D Viewer, which is hard to debug. The 3D Viewer would play for you the whole wheel-rods animation together, if you merged them into a single one.

I also tagged the bogies, and they turned into the right direction in Openrails as far as I noticed. The geometry is not exactly right in small-radius curves, like the one when starting at "columbia falls set out (traffic).pat", but this locomotive should not run these small curves anyway. I'm not sure if changes are worth in Openrails to align this more perfectly. Changing the relevant code might cause more problems than it solve, given that we do not have a test suit of various cars collected, to check if a change corrects problems everywhere, or while it fixes something, brokes something else at the same time...

Ah, and I forgot to mention some important things:

1. glTf is oriented in a way that +Z is forward, +X is left. This is different to the .s orientation.
2. The base color texture should be in sRGB color space. The .s file was linear RGB.

[Eldorado.Railroad]

I have been following this thread with some interest. It seems to be getting more abstract/messy very fast. For those of us who have been dealing with .s files for a decade or more, including exporting .s files from TSM/3DCanvas/3DCrafter/Blender this is all rather new and as such not very clear at all what is going on here. To make this "new" supported shapefile in OpenRails accessible some demonstration models that include the original source (Blender etc) finished product exported in this new format.

This will/should have to include:
-Locomotives with various degrees of complexity, wheels, rods, trucks/bogies, fans, wipers, doors, etc
-3D Cabs with all the expected if not more features included in the current .s file
-Wagons with much of the detail in Locomotives where warranted
-Static objects, with and without animations
-etc

I worry that this new file format will become a niche format, with few really understanding how it is supposed to work to achieve even at parity what we can and have done with the .s file format let alone move beyond it. If there is too much mystery with how this is implemented in OpenRails it risks "dying on the vine".

At this point I am reading this thread and not getting a clear picture of where to even start. I hope that this is not the intention.

Speaking of pictures, can we see what these models in the new file format look like in OpenRails now??? Please? As I recall the first exports in OpenRails did not work/look very well some time back.


Steve

[Genma Saotome]

 Eldorado.Railroad, on 25 February 2023 - 07:13 PM, said:

I worry that this new file format will become a niche format, with few really understanding how it is supposed to work to achieve even at parity what we can and have done with the .s file format let alone move beyond it. If there is too much mystery with how this is implemented in OpenRails it risks "dying on the vine".

Steve

There are a number of conversion utilities, something into .gltf. I even found several for Sketchup. And .gltf goes into Blender rather easily. It's the really old tools that are put at risk: TSM, GMAX, and 3dCrafter. If you can get to Collada's .dae format from any of those you can get to .gltf and from there into a modern 3d modeling tool.

As for the state of the vine... too many years w/o a route editor, too many years w/o getting to an interesting version of DirectX. Perhaps the rate of progress equals or even exceeds what could be realistically expected, I dunno. I do know the decline in daily appearances here by members has been 5%/year, every year, for at least 6 years and that says something too.

[gpz]

 Eldorado.Railroad, on 25 February 2023 - 07:13 PM, said:

Speaking of pictures, can we see what these models in the new file format look like in OpenRails now??? Please? As I recall the first exports in OpenRails did not work/look very well some time back.

Robert Zondervan's steam locomotive and its luggage car works without major problems, but it is not my call to publish either the models or pictures about them, I got them only for testing purposes. If you go back some pages you can see a video about it from a testing stage. This other recent locomotive is in a much earlier stage of development, don't expect to be published as a finished locomotive anytime soon.

And yet the animations are disabled in my PR, because there was no decision made yet if we want to keep the MSTS animation names, or define new ones. So I would like anyone not to publish "officially" anything yet based on this code, because it is still subject to change.

[Rj Zondervan]

I've no problem with sharing some pictures of the materials here :), the source files however are a different story.

However, I'm willing to write a manual for exporting the glTF file from my source files. The catch however is that it is 3D editor specific, and exporter specific. On the upside, the glTF standard is actually quite well documented online, and although I need to use a plugin for 3DS Max because the native glTF exporter of version 2023 is very limited, Blender, Sketchup, 3DS Max and Maya all support glTF to more or less extend (and with the Autodesk products needing a plugin for more complex exports).

But, before I can write this manual we need to have a decision about the definitive animation names, and there are a few things I haven't played around with and I'd like to dig in deeper before writing the manual:

• Lighting: can we use in-model lights and if so, how should we describe when they should be on or off? I seem to remember something about glTF lights being discussed, but I don't remember discussion about how to use them.
  
• Joints, bones and skins: do I understand correctly from the conversation above that we can use joints and bones to animate i.e. brake hoses, couplers etc.? If so, we would also need naming conventions for these extra animations etc.

Okay, enough written, some screenshots:




The engine, please note that the 3rd screenshot is a bit older (January) but somehow I seem to have more pictures from the right side of the engine than of the left side, probably something to do with my test station being orientated Southwest - Northeast and on the Southwest end of the route so far.
Here's also the latest video I made, with the steam special effects not longer disappearing underway: https://www.youtube....h?v=I1-uVuAQZDs




And the luggage car.

[gpz]

 Rj Zondervan, on 26 February 2023 - 01:40 AM, said:

But, before I can write this manual we need to have a decision about the definitive animation names, and there are a few things I haven't played around with and I'd like to dig in deeper before writing the manual:

• Lighting: can we use in-model lights and if so, how should we describe when they should be on or off? I seem to remember something about glTF lights being discussed, but I don't remember discussion about how to use them.
  
• Joints, bones and skins: do I understand correctly from the conversation above that we can use joints and bones to animate i.e. brake hoses, couplers etc.? If so, we would also need naming conventions for these extra animations etc.

Any glTF model can have active lights attached as defined in the KHR_lights_punctual extension, even the static shapes. ("Directional" type lights are disabled to be injected, they are preserved for the Sun and the Moon only. Use the "spot" type for the headlights.) In the current PR I have limited the total number of lights at 20, but it is an entirely arbitrary choice, because I don't know the graphics performance implications, I haven't performed measurements, maybe it can be increased to e.g. 200, maybe not, I don't know. The fade in-out is not yet implemented, because that potential is defined in the KHR_animation_pointer extension, but it is in the pre-ratification stage. But I don't think it would change much now, so maybe it can be safely implemented. Once it is implemented, the headlights definitions could actually be moved off-eng internally into-gltf by defining animation names for them, but it is to be discussed with the community if it would be desired.

Yes, you understand correctly that skinning is already implemented together with their animations, and I think at least for the sake of the discussion proposals are welcome how these brake-hose and couplers animations should behave, how they are expected to animate. I don't have much in my mind about these yet. And skinning can also be freely used elsewhere in the model, the curved objects may be a good candidate for these, but I am not really a modeling expert.

[pwillard]

Personally, I fail to see how adopting an industry standard format for an Open Rails file format could be considered 'niche' in fact I would call it "right in line" with the intention of keeping a certain train simulator software package relevant in the 2020s. Also note, I'm not advocating for NEW SHAPE FORMAT as a replacement and thus dropping .s file support. I am in support of our future potential and getting away from the limitations of a file format standard that was created and implemented last century.

Heck, if people are so concerned about a new open standard FORMAT being used in the *trains* folders we *could* have an internal compressed format created that ALL source models get converted to *by the sim* at the time of 'insertion' into the *trains* folder so it discourages reverse engineering (which is what Trainz currently does). This would mean there is a path for S file conversions to allow for better *lighting* options in the future as well versus being stuck where we are now.

[gpz]

 Genma Saotome, on 25 February 2023 - 10:36 AM, said:

I have no problems with that. The objection I raised was in regards to embedding the textures into the .gltf file. Did I misunderstand? I was trying to use the online viewers w/ no luck.
(...) but I say that under the assumption the texture file format for the new standard is .png and/or .jpg and/or .dds; Is that correct? The IRFAN program has a batch function that will change formats and drop the resulting .png or .jpg when you specify. It'll do a couple of thousand files in a minute or two. AFAIK getting to .dds is different and AFAIK is more expensive, both in time and money.

Maybe I was the one misunderstanding, sorry for that. On the other hand I don't see how the embedding might be an issue. Embedding can be undone, gltf-s can even have some textures embedded and others be external. It can be created and converted by anyone, as feels better.

The format list is correct. Dds has an indisputable merit over the other two that that is the only one capable of storing mipmaps, or having the texture in DXT format. For example Gimp can export to dds textures via a plugin, afaik.

For the online viewers to diplay the model you need to drag-and-drop the whole package: gltf, bin and the textures.