[James Ross]

gpz, on 06 February 2022 - 05:07 AM, said:

Before, I would like to try to implement the ligths extension, I find that exciting, and that is a feature missing already from the possibilities. And for this I have to move the whole lighting calculation to the pixel shader, so I will be able to decrease the number of float4 slots of the vertex shader output back to be within the limits. However I already see that the next limit I run into is the number of used constant registers (31). I will see how far I can get in working around that, but I fear when I do so, there will be yet another kind of limit... DX9 is getting old...

Yes, it is. It would be very nice to drop feature levels 9_1 and even 9_3, moving the minimum up to 10_0.

btrs, on 13 February 2022 - 08:23 AM, said:

No, this is just great to finally being able to drop support for EOL'ed API's anyway. You already bit the hard pill when OR 1.4 dropped Win XP support, so Win 7 was needed as default anyway (which has DirectX 10 as standard). OK, I know that doesn't mean every GPU supports Direct3D 10, but do you really want provide support for 15+ year old hardware ? Heck, even GeForce 9000/Radeon HD3000 cards (from 2008) already had Direct3D 10 support, so I think it's time to move on and upgrade to Direct3D 10.

Too bad for those on Intel onboard graphics, but then you're not a serious OR user anyway (or just limit yourself to basic branch line operation with few requirements..)

I'm afraid to tell you that we support non-serious Open Rails users as well as serious ones. Intel integrated graphics are important to support, as many people use laptops these days and many laptops use Intel integrated graphics.

Luckily many Intel integrated graphics versions do support DirectX feature level 10_0, but the biggest problem we have here is a lack of data. We simply do not know how many people would be affected by dropping support for either 9_1 or 9_3.

The current (Jan 2022) data in the Steam hardware survey seems to say that 1.46% of people do not have 10_0-capable graphics, and I feel this could be biased towards game-centric machines.

Unfortunately, Unity removed their stats page, which would have been more representative, I think.

In any case, I would like Peter to finish implementing glTF 2.0 using whatever requirements it needs to work correctly. Only once we are at that point can we really figure out the way forward with shader versions.

[gpz]

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, I can't move much more forward alone. Normally at this stage a PR should go to the unstable release for having a wider test, and to wait for reviews. 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. I tried, there is in the committed shader some initiative of that work, but anywhere I tried to satisfy the compiler, I reached an other kind of limit. And at one stage I reached a limit where the error message returned was not even true anymore, leaving me in the field to guesses what could be the problem. (All this happened only while trying to make the multilight-allowed shader to work for .s objects, not even came to the part to try to fit the PBR part into the 9_3 limits.) After spending a couple of days with this problem I came to a conclusion that every hour I put into fitting this whole thing into the 9_3 limits is a waste of my own time. So I gave up on this "backporting" thing. I was able to make this PR to work only on Direct3D level 10.0 hardware. If anyone with the appropriate knowlegde could make it work on Direct3D level 9.3 graphics, that would be very welcome, but this seems to be beyond my abilities.

But the good news is, that for me it works pretty well! I have implemented the lights extension as well, so theoretically any glTF can carry light sources too. The infrastucture of displaying multiple light sources is in place, although I tested everything with only one-two models at a time, and to see how this all works in practice would need some extensive testing. I would also be interested in the speed. The fact that my one-two test models at a time run with 200-500 FPS on my mid-to-highend computer doesn't show much. I also limited the number of the total lights to 20 currently, but that is completely arbitrary, bacause I have no idea how much load an additional light puts on the GPU...

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)

[Genma Saotome]

Peter, it seems your situation is very similar to Carlo's work on Monogame. Perhaps a fork of OR is the right thing to do for testing until it is possible to merge it back into the "official" OR code and let us all hope it won't take 7 years. :lol2:

[Rj Zondervan]

Just an idea for the DirectX problem: would it be an idea to introduce a switch for older hardware to disable the DirectX10 functionality? If not, I would not have objections to breaking compatibility with DirectX 9, but that is not up to me.

Another part of the way forward: I would like some information about, i.e. how models should be prepared for export to glTF, most importantly: what should we do differently to preparing for export to .s, will we have to work with new naming conventions?

Furthermore, I'm curious to learn if there are plans for implementing extra possibilities for animations, i.e. animations that change due to inputs (for example steam engine gearings of which the behaviour changes depending on the position on the reverser).
However, I am perfectly happy for the moment with this, see this topic for an example of how I'm using PBR images for a new steam engine.

[Csantucci]

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?
Peter, if this can be of interest as test case, I could try to run your code on my computer, if ths is not complicated to set up.

 GeForce120.txt (9.21K)
Number of downloads: 266

[gpz]

Genma Saotome, on 05 March 2022 - 01:14 PM, said:

Peter, it seems your situation is very similar to Carlo's work on Monogame. Perhaps a fork of OR is the right thing to do for testing until it is possible to merge it back into the "official" OR code and let us all hope it won't take 7 years. :lol2:

I would not like to maintain my own fork, because that maent a lot of extra work, and given the examples of the current forks, there is a high chance that a fork will never ever be fully merged back, it is just diverging more and more by the time. I think there are at least 5 forks exist (if not more), and neither of them seems to be certain of ever wanting to get merged back. This is not my way.

Rj Zondervan, on 05 March 2022 - 01:15 PM, said:

Just an idea for the DirectX problem: would it be an idea to introduce a switch for older hardware to disable the DirectX10 functionality? If not, I would not have objections to breaking compatibility with DirectX 9, but that is not up to me.

Another part of the way forward: I would like some information about, i.e. how models should be prepared for export to glTF, most importantly: what should we do differently to preparing for export to .s, will we have to work with new naming conventions?

Furthermore, I'm curious to learn if there are plans for implementing extra possibilities for animations, i.e. animations that change due to inputs (for example steam engine gearings of which the behaviour changes depending on the position on the reverser).
However, I am perfectly happy for the moment with this, see this topic for an example of how I'm using PBR images for a new steam engine.

That is the point, I can't disable DirectX10, because it is not the functionality that steps up, but rather the number of used constant buffers, number of instructions in a shader stage, etc. So there is no new kind of functionality used, only more in numbers of the existing ones. Like if someone told me that I need to write a program that must fit into 1000 lines of code, and I can use only maximum of 10 variables. But if a program exceeds a certain kind of complexity, than it becomes impossible to fit within those limits, unless I am a genius like Steve Jobs.

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. 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? 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!

I see your new steam locomotive, it looks really impressive! The glTF metallic effect might indeed give an illustrious outlook to the shiny copper and ferric surfaces. They look special in glTF compared to the traditional MSTS outlook because they reflect the lights and the fake environment map, and this gives the illusion of being almost like real metals.

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?
Peter, if this can be of interest as test case, I could try to run your code on my computer, if ths is not complicated to set up.

Carlo, I would appreciate if you could test the code with your laptop. Your tests are always extremely useful, in any case, it had been proven to me during our many years of work together! I don't think it would be complicated to set this up, because I store all my relevant code in this github PR: https://github.com/o...nrails/pull/570
Setting up a test case is as easy as downloading a model from the net, e.g. one of my test models was this porsche: https://sketchfab.co...e59499f0dbed21e
I've just copied the gltf, bin and texture files to the KIHA31 folder in the trainset, and modified the kiha31.eng to reference the downloaded .gltf file instead of the original kiha31.s.

If the model has an animation defined, then the first of these can be played by hitting <Shift+,> (comma), as I temporarily assigned the first found animation clip to the "ORTSITEM1CONTINUOUS" command. Among others I played with this rhino's animaion: https://sketchfab.co...ea9e3fd421f55b4

By the spec level 10.0 should be enough for this to work, I haven't used any more advanced features. But we will see. :)

[Csantucci]

Hi Peter,
I made a first test by using the patched OR, but with the original Kiha.
I get following crash, before the logfile opens


By the way I got two rejected hunks by applying the patch. While there is no problem for the Shapes.cs hunk, I have a doubt for the other one, that is where to add the two missing lines. because in the actual Materials.cs file

                    ShaderPasses.Current.Apply();

is before

                    graphicsDevice.SamplerStates[0] = item.Material.GetShadowTextureAddressMode();

and not after, and the two lines to be added are just in between. I've put them before the Apply() line.

 Materials.cs.rej.txt (688bytes)
Number of downloads: 230
 Shapes.cs.rej.txt (343bytes)
Number of downloads: 232

[gpz]

For the latter issue see this bug fix: https://github.com/o...nrails/pull/580
Setting the sampler state has no effect if it is done prior to ShaderPasses.Current.Apply(), so the correct order everywhere is apply the passes, then set the sampler states.

[gpz]

Csantucci, on 06 March 2022 - 09:11 AM, said:

I get following crash, before the logfile opens

Regarding the shader compiler crash, I wonder if your GPU was able to go with standard vs_4_0 and ps_4_0 at all. By the spec you uploaded it would, but just as a quick test, could you maybe remove all "_level_9_3" and "_level_9_1" occurances from the SceneryShader.fx file in your unpatched, original branch, and try?

[Csantucci]

Peter,
removing the occurrences you mentioned from SceneryShader.fx in the master release still generates an OR which runs on my computer.
Re the Materials.cs.rej issue, my question is not about the sequence of setting the sampler state and ShaderPasses.Current.Apply(), but where to apply these two added lines

+                    if (item.ItemData is Matrix[] bones)
+                        shader.Bones = bones;

[gpz]

These lines are before the Apply(). I wanted to copy a github permalink to the "changed files", because it can be seen there, but I'm on mobile, and here it is just impossible to use such functions.

[James Ross]

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.

[Csantucci]

James,
I've already made a test, unfortunately with negative result, see here http://www.elvastowe...post__p__282910 , although 10_0 seems to work, see here http://www.elvastowe...post__p__282970 .

[James Ross]

Csantucci, on 08 March 2022 - 12:51 AM, said:

I've already made a test, unfortunately with negative result, see here http://www.elvastowe...post__p__282910 , although 10_0 seems to work, see here http://www.elvastowe...post__p__282970 .

I am waiting for a test on the official Unstable Version (once Peter allows the PR into it) :)

[gpz]

The biggest problem with the animation code is that SharedShape.Animations is linked directly to the stf animation class everywhere. So anywhere I want to inject the functionality, currently I need to do

if (PoseableShape.SharedShape is GltfShape gltfShape && gltfShape.GltfAnimations.Count > 0)
// This is the gltf animation handling
else if (PoseableShape.SharedShape.Animations?.Count > 0)
// This is the stf animation handling

And there are a lot of instances of this is needed. It would be good to make a virtual animation class both of them inherited from. Internal animations are more or less supported already (more than less, actually :) ), but we need to define a tagging method for externally handled animations, like the wheels. There are two methods how data can be injected into the gltf. First is by using a custom-defined extension, which if done right, is a bit more complicated, because it is required by the syntax to register all extensions used in a particular gltf to the toplevel "extensionsUsed" hierarchy. Or alternatively it is possible to use the "extras" structure, which is available everywhere in the glTF, for nodes, for animations, for textures, you name it, and which is suggested to be a simple "key": "value" type dictionary.

Actually an extension exists already for tagging externally handled animations: the AGI_articulations
My only concern with this is that it requires to supply more data than we need for a simple wheel for example, because it also requires to define the geometrical constraints, how a particular articulation is allowed to move. I don't know if we can morally "hack" this (because technically it is not a problem) in a way that we use only a part of it, while the spec explicitly says that the constraints MUST be provided too. (See the string "At the root level extensions object of the glTF, the extension must define articulations matching all of the articulation names requested by nodes in the model" in the specification. My life-long experience tells me that we should follow the spec, but I could actually sleep well if we didn't do that here... But I'm not working in this industry, so I leave the judging to others.