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. :)
Log In
Register Now!
Help
