ORTS new shape format???
#321
Posted 15 April 2023 - 04:36 AM
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.
#322
Posted 15 April 2023 - 07:15 AM
gpz, on 15 April 2023 - 04:36 AM, said:
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.
#323
Posted 15 April 2023 - 10:44 AM
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/
#324
Posted 15 April 2023 - 01:58 PM
gpz, on 14 April 2023 - 11:44 PM, said:
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.
#325
Posted 15 April 2023 - 09:22 PM
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.
#326
Posted 16 April 2023 - 02:28 AM
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.
#327
Posted 16 April 2023 - 07:32 AM
Quote
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.
#328
Posted 17 April 2023 - 05:50 PM
#329
Posted 17 April 2023 - 10:51 PM
Laci1959, on 16 April 2023 - 02:28 AM, said:
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:
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.
#330
Posted 03 May 2023 - 10:25 AM