[copperpen]

 Genma Saotome, on 23 February 2023 - 12:41 PM, said:

Curiosity here... would the new format allow modelers to craft large steam locomotives as a single model instead of the MSTS practice of dividing it into two?

The practice of splitting articulated engines was started by NALW IIRC. Jon Davis I think it was, made two sets of GN articulated steam as one piece models. Therefore the ability to have large single piece articulated engines has always been possible but workarounds had to be made to get around limitations such as number of bogies and wheels per bogie. Open rails has removed those restrictions so we can have large single model articulated engines, but only one experimental model has been made so far/

[scottb613]

 copperpen, on 24 February 2023 - 04:46 AM, said:

The practice of splitting articulated engines was started by NALW IIRC. Jon Davis I think it was, made two sets of GN articulated steam as one piece models. Therefore the ability to have large single piece articulated engines has always been possible but workarounds had to be made to get around limitations such as number of bogies and wheels per bogie. Open rails has removed those restrictions so we can have large single model articulated engines, but only one experimental model has been made so far/

Hi Folks,

Aside from articulated locomotives - locomotives used to be split for poly count - I recently asked Wayne about this in Blender - he stated poly count is no longer a reason to split locomotives and we can export whatever size will still run in ORTS.

Regards,
Scott

[Weter]

Hello.
You might be mean TSM limitation, when some details were attached as freight animation then?

[Genma Saotome]

 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?

This causes me great concern but before I raise objections I need to be sure I understand: Are you speaking of the process to create the .gltf or to display them? If the later, do you mean something along the lines of:

foo.zip
-- foo.gltf
--\textures\foo_1.png
--etc.

[gpz]

(Not sure how the zip came here, but) of course the display, that's what I'm implementing. The texture path should be written in the gltf file without the leading backslash, and replacing the other backslash with a forward slash. I am aware of the concern about the need of changing the traditional directory structure, but I believe the Openrails should be compatible with the other gltf viewers, becuase those will be the new shape viewers.

[Genma Saotome]

Peter, the problem here seems to be the unspoken assumption that every model is small and it's textures are not used elsewhere -- a monster, a man, a gun, a tank, an aircraft, or more specifically, a locomotive. Small, one-of models. OTOH, here in our environment there are routes. Consider there are almost 2000 Scalerail shapes, each with a minimum of 4 identical textures. If 3dtrains had been faced with the same requirements the storage requirements for SR would have greatly increased in size.

For my own projects I have 5400 models in one route, 1300 in another, almost all are custom built and reuse textures LOTS of textures*. Open any of my models and the odds are very high every texture (10-15 of them) therein will be found in many other models, and the models are large: I just picked one at random and its bounding box was a 100m cube. The \Textures directories total 3800 files, just over 1.5gb compressed, 3.5gb uncompressed. You are talking about a rather large increase in the size of routes built to this new standard.

I expect the OR program will continue to support the old ways and so most models will live on as-is which certainly solves much of this issue. What's left are people like me, few of us now, still building entire routes. The choice for us will be a very large increase in the size of the routes vs. staying as-is and not using any new shaders.

* Almost all of my textures were designed for reuse -- fully tiling up/down, left/right: Brick, concrete, rust, steel, wood siding, stucco, steel siding, roofing materials and so on.


p.s. A thought just occurred: Doesn't embedding the texture in the model file close the door on reskinning?

[Traindude]

 gpz, on 23 February 2023 - 09:44 PM, said:

Actually it would be challenging to bring this together. But I surely needed a test case for that. Would it be possible that you tried to export your most challenging locomotive to gltf for me in one piece? I could try to see what can be done, but this for sure would not go into this actual PR.

I'm in the process of doing that right now, but I want to know what to tell Blender to export it as: "glTF Binary (.glb)", "glTF Separate (.gltf + .bin + textures)", or "glTF embedded (.gltf)". Which one is correct?

[Genma Saotome]

For my own education, could some one post a simple .gltf file that has a couple of textures? Thanks in advance.

[gpz]

 Traindude, on 24 February 2023 - 06:34 PM, said:

I'm in the process of doing that right now, but I want to know what to tell Blender to export it as: "glTF Binary (.glb)", "glTF Separate (.gltf + .bin + textures)", or "glTF embedded (.gltf)". Which one is correct?

Either one would work, but for testing purposes the best would be the .gltf + .bin + textures. That is the easiest one to open with a text editor in case of problems. But as the others are saying, everything should work already, even with an .s file. ;-)

 Genma Saotome, on 24 February 2023 - 08:21 PM, said:

For my own education, could some one post a simple .gltf file that has a couple of textures? Thanks in advance.

You can find a bunch of these in the repository I mentioned above somewhere: https://github.com/K...tree/master/2.0
These are the ones I am using as a test suite for the implementation.

 Genma Saotome, on 24 February 2023 - 05:46 PM, said:

For my own projects I have 5400 models in one route, 1300 in another, almost all are custom built and reuse textures LOTS of textures*.

But how many of the models with shared textures are residing in separate directories? 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.

 Genma Saotome, on 24 February 2023 - 05:46 PM, said:

* Almost all of my textures were designed for reuse -- fully tiling up/down, left/right: Brick, concrete, rust, steel, wood siding, stucco, steel siding, roofing materials and so on.

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.

 Genma Saotome, on 24 February 2023 - 05:46 PM, said:

p.s. A thought just occurred: Doesn't embedding the texture in the model file close the door on reskinning?

Since it is an open standard, anyone can unembed the textures and store the whole model in a different gltf form, if that suits better for him.

[gpz]

Traindude, on 25 February 2023 - 01:05 AM, said:

-A demonstration of something we could potentially use in ORTS gltf files--the use of armatures, bones and constraints to animate parts of the model. In this case, I am using it to demonstrate the flexible steam pipes that connect between the front engine and the boiler.

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.