[gpz]

If I understand well, your main issue is the flashing lights on the arm, right? I haven't ever checked how the level crossings implemented in the Openrails code, so I'm just speculating here.

Gltf's animations work a bit differently from the stf animations. Stf animations move one node at a time, while gltf animations are higher level. They are not directly node based, but rather each animation is an own entity that can target different nodes at different times, and any sub-animation can exist within independently, and of linear or step style. See here for example: https://github.com/K.../screenshot.gif

A complex animation clip can be predefined in the authoring tool like Blender before the export, and that clip can be played by Openrails e.g. from the beginning to the end, or backwards, or looped, or whatever. The lights (which are not real lights, just like filled red circles, right?) can be flashed by a "step" animation setting their node's scale to 0 at 0.5 second, and back to 1 at 1.0 second, and so on, till the end of the "closing" animation clip. "Opening" is played backwards. The only thing missing is the "loop at closed", which I'm not sure how is implemented in Openrails cuurently, since there are flashing reds at the closed state even at this time, aren't there? (Needs to be checked, in case changes are needed here.)

That said, I haven't yet tried to place an animated glTF into the world files, till now I've only played with animated rolling stock. But if there would be a test object, I could make the necessary changes to the code, which I wouldn't expect to be more than few dozen of lines. I'm commited to make the glTF support as complete within Openrails as possible.

[Laci1959]

gpz, on 15 April 2023 - 04:36 AM, said:

That said, I haven't yet tried to place an animated glTF into the world files, till now I've only played with animated rolling stock. But if there would be a test object, I could make the necessary changes to the code, which I wouldn't expect to be more than few dozen of lines. I'm commited to make the glTF support as complete within Openrails as possible.

Thanks. What exactly would it need?
I have a MÁV sign, which is the car sign next to the road. Max format. For this, there are lights that move back and forth a little. They act as a kind of two-bit blanket. I can even combine them into one object.
Make it again in Blender format, or try to convert it from max to glTF format. Remember, I'm a beginner at this, but I'm happy to learn new things.

[gpz]

I'm not sure I am the right person asking about the exporters, and also the animation keyframing in authoring tools is out of my expertise. But I can tell you that glTF animations involve the binary data part as well, so it is not something one can set up by a text editor. I'm not saying it is impossible with a hex editor, but don't think it would be straightforward. The workflow could be to keyframe the animations in an authoring tool (like Blender), then export it to glTF. But I'm sorry, but not I will be the person teaching how to do this. :-( But once the model is ready, I can adjust the Openrails program code to make it work within the simulator.

EDIT: I assume you are not looking for real working level crossings, because as I've just read in an other recent thread, they say they were never linked into the signalling to really open and close, and I also cannot fix that if this is the case. See http://www.elvastowe...ossing-signals/

[Traindude]

gpz, on 14 April 2023 - 11:44 PM, said:

In Openrails these tags don't have to be unique. You can have any number of wheels tagged ("named") WHEELS1 for example. The only difference is that single-digit wheels will rotate as the WheelRadius() defined in the Engine() section, while double-digit wheels as in the Wagon() section.

That may be true, but Peter has been working on something for an upcoming Unstable release in May (see post #56) that seems promising in the advancement of one-piece articulated locomotive models.

So with that in mind, naming two axles of different engines with the same number might screw this up. So it'd be better to have each axle numbered independently, and when there are 10 or more driving axles, we can treat the numbering hexadecimally, as my earlier drawing illustrates.

[gpz]

Traindude, on 15 April 2023 - 01:58 PM, said:

.
So with that in mind, naming two axles of different engines with the same number might screw this up.

Nothing one makes should screw up existing functionality, so because of this, especially because of a fear of something in the future MIGHT screw up something, no code changes are worth of making.

[Laci1959]

Unfortunately, it would be about modeling the real operation. There is a solution, but the real garage tuning.
There is a two-bit cover plate that is controlled by the train. If there is no train, it covers the red lights. If the train is coming, the covers move about 15 mm. They cover the flashing white light and make the two alternately flashing red lights visible. This is one shape. Object of type LevelCr.
The other is a light signal that signals cars. This also has its own animation, The two red lights flashing alternately, and the white light flashing in sync with one of the red ones. This is another shape. This is an object of type Static.
Although I write lights (out of habit), they are not.
The two must be copied together in the w file after placing them. Well, I wanted to save this duplication. It's extra icing on the cake when there's also a trap bar. The two yellow tiles must be placed on top of each other, and TSRE sometimes deletes one or moves it to another tile. That's annoying in itself, but that's the least of it. The worst thing is that you can't coordinate well. When the train comes, the flashing white light goes out, the two red lights start flashing alternately. After 12 seconds, the trap bar should start going down. When opened, the bar moves up, when it reaches the vertical position it turns off the red lights and turns on the flashing white light.
I thought this could be solved in an object if I used a glTF model.

[cesarbl]

Quote

That may be true, but Peter has been working on something for an upcoming Unstable release in May (see post #56) that seems promising in the advancement of one-piece articulated locomotive models.

So with that in mind, naming two axles of different engines with the same number might screw this up. So it'd be better to have each axle numbered independently, and when there are 10 or more driving axles, we can treat the numbering hexadecimally, as my earlier drawing illustrates.

If two axles are connected to different engines, using the same name for them doesn't look like a good idea, but if I understood Peter (gpz) correctly, you can use the same name for all wheels connected to the same engine. This means that you can have up to 9 independently-spinning animations, which should be enough I think. For the 2-10-10-2 locomotive, you just need 4 independent animations (2 of them for driven wheels).
Anyway, at the moment we are working on the physics of that, animations will come later, and the limit of 9 could be removed if required (e.g. adding some configuration in the .eng file which maps animation names to one of the engines).

So for models which are sensibly built, with different wheelsets having different names, the animations will still be valid to get independent wheelslips for each wheelset.

[Traindude]

Something I brought up in the new lighting conditions thread but I'll repeat it here. You know how some models have things like illuminated interiors and backlit number boards that utilize "Bright" textures so they're illuminated at all times? It would be nice if we could use headlight controls to change the texture mode from "normal" to "bright" (and vice versa). Who else agrees?

[gpz]

Laci1959, on 16 April 2023 - 02:28 AM, said:

There is a solution, but the real garage tuning. (...) I thought this could be solved in an object if I used a glTF model.

Yes, such a complex animation sequence can be configured in glTF. If the level crossing closing and opening triggers work correctly in Openrails, then such a pre-defined animation can be hooked onto them.

Traindude, on 17 April 2023 - 05:50 PM, said:

It would be nice if we could use headlight controls to change the texture mode from "normal" to "bright" (and vice versa). Who else agrees?

In glTF terms this bright texture mode is called "unlit", as defined here: https://github.com/K...unlit/README.md
Unfortunately this behavior cannot be switched on-off by an animation in a standardized way, so the only way this can be configured in glTF is that 2 primitives must be defined, one normal and one unlit. Then they can be scaled from 0 to 1 alternately by a pre-defined animation. (Of course, an OR-specific "extras" tag can always be defined, anywhere in the glTF schema, if desired.) Or, alternatively the "emissive factor" of the material can be changed by an animation (which is not yet implemented, but I am planning to add via the KHR_animation_pointer extension.

[Traindude]

Thinking out loud here, and I'm not sure if it's relevant to the new shape format discussion, but in regard to "dynamic numbering" of locomotives and rolling stock (so no two vehicles in the consist appear to have the same road numbers). Is it possible to treat the vehicle numbers the same way that Microsoft/Kuju originally treated the text on mileposts and speedposts? (Excerpt from the Kuju MSTS TechDocs "How to write a speedpost_dat file.doc"):