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
#331
Posted 03 May 2023 - 03:30 PM
Weter, on 03 May 2023 - 12:49 PM, said:
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.
#333
Posted 06 May 2023 - 01:23 PM
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
#334
Posted 06 May 2023 - 03:22 PM
Traindude, on 17 April 2023 - 05:50 PM, said:
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).
#335
Posted 10 May 2023 - 06:42 PM
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!