[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"):

[Traindude]

Weter, on 03 May 2023 - 12:49 PM, said:

A very appropriate idea.

You define number in *.eng/*.wag -file ORTSBoardNumber (XXYYZZ) and program draws it.
Maybe Font () and Size () paarameters too.

Yes! Perhaps the Font ( x ) parameter could reference an appropriate *.ace file (Example: Font ( "loconums.ace" )), and the texture is scaled according to the "borders" between numbers, letters and/or characters.

You could even specify the number in a *.con file as well.

[Weter]

Yes, as You advising - its more sophisticated.

[pschlik]

Pardon me if this isn't actually on-topic, but I believe this is related to the code going into the new shape format-yesterday I jumped from New Year to the current unstable build to check on some air brake simulation changes, and I was surprised and pleased to notice some lighting changes. Though I noticed one immensely annoying thing...the light cone effect on the TrainSimulations P42DC flickers like mad (I must give a very real epilepsy warning for the video)! I did a bit of digging and determined that setting the conditions for a sphere of lights to use Headlight ( 0 ) or Headlight ( 1 ) [ie: the light will activate with the headlight switch off] causes the light cone to flicker. If I modify the sphere of lights activation to require dim or bright light settings, then the flickering just doesn't happen.

I put up a video to illustrate the flickering, but this is not good for eye strain: https://youtu.be/eOBvYwEOhBQ

I did a bit more investigating, and I'm pretty sure the flickering happens when a light beam is loaded in while its conditions are already true. Loading in to a P42DC spawns you with the lights off, which activates the dim sphere of lights immediately upon loading, causing flickering. Using Alt + F9 to take over an AI ES44DC causes flickering; the AI set the headlights to bright, which activates the bright sphere of lights immediately upon taking over. The only thing that doesn't cause flickering is loading in a state where none of the spheres of light will immediately activate. I don't know why that would be the case, but maybe the code needs some sort of delay to not turn the lights on instantly when their conditions are activated.


I also noticed some locomotives lighting up from the inside, the lights were configured with the sphere of light originating from inside the locomotive body. So, to anyone out there messing with lights, don't do that. While this might have worked in MSTS and looked okay in the old lighting model, it really is unsightly in the new lighting.

https://i.imgur.com/d1IqbaV.jpg

[ErickC]

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

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?

I don't; switchable additive lightmaps (a la MSFS) would look and work better.

With respect to auto numbering - that only works if one of two conditions are met:

1. The reporting marks for every railroad are in the exact same spot (they're not)
2. If we can define a large area for numbers and then provide x/y coordinates (sort of like how MSFS handles VC gauges)

If there was a way to implement some sort of positioning system, then this would save a lot of the headaches of the current ways of doing things (i.e., either road numbers are baked into the textures or defined with decal shapes).

[Traindude]

Another question about the new shape format--more aninated doors--are they a possibility? I know currently, we can only have 3 doors per side--DOOR_A, DOOR_B, and DOOR_C for the right side and DOOR_D, DOOR_E and DOOR_F for the left. However, some passenger rolling stock have more than 3 doors per side (our friends across the pond will understand!), so in adding additional doors, then given the labeling:

Right Side:
DOOR_G
DOOR_H
DOOR_J (deliberately skipping letter "I" to prevent it from being mistaken for a number one "1")
DOOR_N
DOOR_P (deliberately skipping the letter "O" to prevent it from being mistaken for a number zero "0")
DOOR_Q
DOOR_U
DOOR_V
DOOR_W

Left Side:
DOOR_K
DOOR_L
DOOR_M
DOOR_R
DOOR_S
DOOR_T
DOOR_X
DOOR_Y
DOOR_Z

That's a total of 24 possible individual animated door elements! We may not need this many doors but you never know!