gpz, on 05 March 2022 - 12:32 PM, said:
I think I reached a state where my test models look satisfyingly on my computer, and I noticed that I am just doing some small modifications here, some there, but nothing "big" anymore,
This is a big achievement!
:fiesta:
:sign_thanks:
gpz, on 05 March 2022 - 12:32 PM, said:
But unfortunately I cannot just enable this for unstable, because I couldn't really make it work on our current 4_0_level_9_3 feature level of graphics shader.
That's okay. I think we've accidentally increased our minimum to feature level 9_3 and nobody noticed, so with a little luck we may be able to bump it to 10_0 without too many problems.
gpz, on 05 March 2022 - 12:32 PM, said:
Essentially I would like to ask what could be the way forward. I am happy to make changes on this PR if someone reviewed it, or we can enable this for the unstable, knowing that there will be complaints from the people with old hardware, that the cannot run the game. Or we can do the same thing as with my MonoGame port: wait 7 years and merge after. :) :) (Just kidding)
I am happy for you to allow the PR into Unstable Version, and we'll keep an eye on the forums.
I expect we'll want to let something as complex as this sit in Unstable Version for a few weeks, so hopefully that will also be enough time to spot any compatibility problems.
Csantucci, on 05 March 2022 - 01:37 PM, said:
I don't have the ambition that my more-than-10-year-old laptop is the gold standard for an old computer, but I had a check with dxdiag on the d3d feature level supported, and got the attached file (excerpt), that seems to state that my video card supports feature level 10_0. So can we assume that there aren't many computers around that don't support 10_0?
It is good news that something of that age supports feature level 10_0.
If Peter allows the PR into the Unstable Version, please could you test that?
While it is important for you to test merging the patch into your custom version, it would also be particularly helpful to test an unmodified Unstable Version :)
gpz, on 06 March 2022 - 03:58 AM, said:
With handling animations, I am also learning how to do that and what is possible, because I haven't touched the animation code before this. New, not currently existing functionality will have to go to another PR for sure. BBut what I see regarding the glTF is, that it is not the nodes that need to be named, unlike in .s. But rather animations have to be defined in their own hierarchy structure, where an animation can target (link to) nodes via animation channels.
As it appears we'll need to take some additional time to get animation support right, I propose that we do not include any animation support (expect using debug/experimental options) in this initial version; that way, people can start trying out glTF for purely static objects, getting used to the modelling and exporting process, while we figure out animations.
gpz, on 06 March 2022 - 03:58 AM, said:
In .s an animation is measured in number of frames, but in glTF it is in seconds. So e.g. in .s one may define an animation with 8 frames, but in glTF that must be defined as e.g. 20 second long (or any other number of seconds). It doesn't mean we cannot play an animation faster or slower than defined, or backwards for that matter, but this is the key idea behind this. If I understand well, there is also a default FPS defined for the .s files, isn't there? Maybe 1.5 FPS?
.s files define an animation with a frame rate and frame count, so in a sense they also define the animation duration pretty directly, but there are a bunch of special cases - both in terms of the frame rate (e.g. passenger views slow down the frame rate to 1/30th) and where the numbered frames are referenced explicitly (e.g. SignalDrawState.SemaphorePos defines the frame for that state) or implicitly (e.g. SwitchTrackShape uses frames 0 and 1 only).
gpz, on 06 March 2022 - 03:58 AM, said:
I'm not sure about it, it is also a learning curve for me. I learned, there are animations, like the wheels, that don't really have their own animation "clip", rather they're just tagged with certain names, and they just "happen to work", handled by the ORTS code internally. We need to define this tagging method for the glTF-s, it is not programmed yet, because I didn't have any real ORTS glTF content to test with, I've used only downloadable models (like a prosche and a rhino and a military ground vehicle, and all the Khronos test models, as I named a few in my previous posts). Actually it would be nice to have a real railways test model to do the final fine-tuning of the glTF handling with!
Yeah, wheels and bogies are special and, to a lesser degree, doors, pantographs and a bunch of others. There's probably more name-matches items than explicit matches (e.g. signal sub objects).
For glTF, everything should be done via a named animation in the glTF file. I believe we should match those names automatically. For most things (e.g. doors, wipers) it's clear how the game state should translate into animation state (e.g. doors = closed-to-open, wipers start out-of-the-way and loop).
But for some things (wheels, bogies, pantographs come to mind) we need a bit more data (wheel radius, correspondence to angle?, something to do with height, ...) which I'm not sure where we should put. Feels better to have it in the glTF file but I am not familiar enough to know how.