[scottb613]

Hi Folks,

I don't know of TSRE is truly abandoned - Goku did post his source on Github - it might be a better move to utilize that code because it does so much - well. No sense reinventing the wheel. The last update was about a year ago.

Regards,
Scott

[Genma Saotome]

 ErickC, on 31 January 2023 - 04:01 AM, said:

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.

I'm curious. Could you provide an example please so I understand what you are doing.

[Genma Saotome]

 scottb613, on 31 January 2023 - 10:43 AM, said:

Hi Folks,

I don't know of TSRE is truly abandoned - Goku did post his source on Github - it might be a better move to utilize that code because it does so much - well. No sense reinventing the wheel. The last update was about a year ago.

Regards,
Scott

How much of the code is written in Polish?
It's not written in C# like OR is.
The UI is a hot mess.
Terrain editing uses a function common to non-real-world games (a vertical vortex). Various sculpting tools are needed (e.g., a variable size palette knife set to a user specified orientation).

[Weter]

Dave, see saving disk space.
http://www.elvastowe...post__p__293516
Erick said about his method of using one model, relative path to it from many RS folders with their own textures = one drawcall

[pwillard]

 Genma Saotome, on 31 January 2023 - 12:53 PM, said:

How much of the code is written in Polish?
It's not written in C# like OR is.
The UI is a hot mess.
Terrain editing uses a function common to non-real-world games (a vertical vortex). Various sculpting tools are needed (e.g., a variable size palette knife set to a user specified orientation).

The code is written in C++. There is no Polish. Even having POLISH comments would be better than what it is which is code with *NO* comments. Only lazy narcissists justify writing code with no comments and say it's a good thing.

Then -as-is- TSRE is just not good enough and the collective *we* deserve better and should do better.

[ErickC]

 Genma Saotome, on 31 January 2023 - 12:48 PM, said:

I'm curious. Could you provide an example please so I understand what you are doing.

Common textures, most often for trucks and cabs. You can download any NAVS release from recent history to see it in action. The Soo GP9R set is a good example, but any of the recent car kits use this method as well.

 gpz, on 31 January 2023 - 04:34 AM, said:

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.

Ah, okay. I misread you, my apologies. I still think leaving the capability in for future models is a good idea because having texture paths in models allows us to save a whole lot of space on common textures. 3D cabs are a particular application where this saves the user from having duplicates of a whole lot of hi-res textures. Trucks are another good example - I'd wager you probably have about as many identical copies of Ted Curphey's truck textures in your trainset folder as I do. It's a lot nicer to have one image in one place. I suppose there are probably alternate ways of accomplishing the same thing, though - FSX uses texture.cfg to allow the painter to set paths for common textures used on a model (e.g., wings).

Even still - if the viewers don't support it, then we have to ask ourselves - what is the priority? The quality and efficiency of the simulation, or how good the models look in external model viewers? I'd wager most people using viewers are utilizing them to paint models, and I'd rather not be able to see a couple of common textures than have to have a whole bunch of duplicates of the same textures (or the same model if the new model format requires us to have the textures in the same folder as the model, because then every single repaint would need to have a dedicated model instead of using common models like we can use now).

As models get more and more complex, that's going to become a whole lot more onerous as time goes on. We need to have some way of using the same model for a whole bunch of different repaints, and we also need a way of being able to tell the sim to read certain repeat textures from a common location. FSX accomplishes the single model task with different texture folder names for each paint variation, while common textures utilize texture.cfg as indicated above. Maybe a system similar to that could be implemented? That would work.

[gpz]

Erick, I could make up a theoretical analogue to this issue, that let's say the Huawei – I bring this name because the Americans like to beat it nowadays anyway – decided to produce a smartphone, where its camera saved format is switched from their proprietary format to the standard jpg. However the Chinese Intelligence Agency (CIA) requests them to deviate a bit from the common practice, and continue to save the geolocation data not to the end, but rather to the beginning of the file, how they used to before, and where their long-used sureillance software expects it. Unfortunately this makes the saved jpg-s incompatible with the Windows Paint, Photoshop and other jpg viewers-editors, but no problem, because you can still see them on the phone's screen. And they also provide a free "Huawei Enjoy My Pictures" jpg viewer software for the PC-s, which probably doesn't make you any happier, even if they say it is capable of displaying non-Huawei jpg-s as well. But hey, you can make the Huawei jpg-s compatible with the other viewers by opening them in a hex editor, cut the first 512 bytes from the beginning of the files, and move them to the end, save and done. Easy, right?

EDIT: Two other methods come to my mind that allow to access to any folder but still keeping the path in "forward" fashion: externally, creating a symlink with the Windows MKLINK command, or internally by virtual file system configuration. Both methods can make any folder or file available below the SHAPES folder.

[pwillard]

I'm looking forward to better graphics shaders and PBR materials and we can't ever get there if we hang on to the original formats.

[Rj Zondervan]

Hi all,

In the meantime I have updated the glTF models from the previous videos to adhere to the given folder structure, and edited the animation groups in the model.

As a result I now have the door and mirror animations separate from the continuous animation of the wheels.

https://youtu.be/MHvBKx1TGCY

Comments so far: the door and mirror animations are rather quick, and the bogie animation could be more fluent, but for the moment I am quite happy how this is turning out.

Robert

[gpz]

The glTF standard specifies, that the animation input values are actually time, measured in seconds. It is different from the s files, where the input is some kind of a "frame rate" or "frame count", in the code I saw somewhere a multiplier of 8 and a divider of 30, but I didn't go deep into understanding thats exact math... Your luggage car door animation has a 0.16 length IIRC, which means it is 0.16 seconds long, that's why it is so fast. There should be means in your authoring tool to change this before export.

I don't think the bogie animation is in connection with the glTF, once it is loaded, the same code moves that and the s file's bogie.

EDIT: I found this that would worth looking into, although I'm not too familiar with 3dsmax: https://knowledge.au...01ACAC-htm.html