[gpz]

Thanks, I'm doing this hoping that most people will like the results!

James Ross, on 05 February 2022 - 06:00 AM, said:

When you're happy with the glTF 2.0 support we can come back to this and see if there is a way to address it, or degrade the glTF visuals slightly for older hardware.

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

[pwillard]

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

DX9 is getting old...

It sure is...


Man, this is great,,, don't stop... I'm loving the idea of this being a real thing.

[ErickC]

Will we be able to control the intensity of the reflection map? The reflection map feature in MSTS was pretty much useless because it was either no intensity or full intensity across an entire material.

MSFS does this by controlling the opacity of the reflection map with the alpha channel on the diffuse map (lighter=less reflection, darker=more reflection), but since diffuse alpha is commonly used as a transparency map in OR models, maybe the alpha channel of the specular map could be used? In FSX you can elect to use the alpha channel of the specular map to control both the sharpness of the highlight and the reflection intensity (which is logical because these are pretty closely tied together in real life). The colour channel of the specular map then controls the specular colour (which is absolutely necessary for any kind of meaningful specular highlights on a weathered model).

Anyway, promising stuff! Can't wait to see the end result!

[gpz]

I found this tutorial with a quick search on the matter: https://marmoset.co/...ture-conversion

Just for information: glTF PBR defines two distinct workflows: the metallic as a standard, and the specular via an extension. (KHR_materials_specular) In the current state of my PR only the standard metallic is supported, but later the other one may also be added.

[Genma Saotome]

Visually, this all sounds like something the automobile manufactures would love for their advertising of never-been-outside-the-showroom new cars but how much is relevant to the filthy, sun-bleached world of railroading?

[gpz]

As I see, this technology is already out of the showrooms, seems like this is the now-trendy way of doing the lighting in modern engines, including the FlightSim. PBR, what else? - as George Clooney would say. :)

[Weter]

@ErickC
Some posts earlier, clear coat feature was described.
This is a quotation of #189:

Quote

KHR_materials_clearcoat: This would add 3 additional textures to the model (beyond the current 5). Actually this would need to be supported, because how the people more aware of the math behind describe, metallic texture alone is only for showing the metalness of the material, but vehicle "metallic polishing" adds another layer to the material. This "metallic polishing" is what they call "clearcoat" in PBR terms. So if want to make this kind of effect visible, then we need to add support for clearcoat.

And it seems to me, this is about the question, You have announced.

[Genma Saotome]

wacampbell, on 02 February 2022 - 08:52 AM, said:

Regarding the LOD's using screen coverage vs distance. The advantage of screen coverage is it works independent of the field of view settings on the camera. With distant based LODs, when the user sets up a telephoto camera, those distant items disappear while they are still visible. What we really want is for them to disappear when they get too small to see on the screen. The screen coverage method does this. I suppose it might work to have a distance based LOD where the distance gets multiplied by some factor depending on camera fov.

Ohh. that's a good feature.

It does seem there isn't a solution to monitors operating at different resolutions; If you set the LOD for a very short height for a 4k monitor it will never kick in on monitors using lower resolutions.

[gpz]

Genma Saotome, on 06 February 2022 - 05:57 PM, said:

It does seem there isn't a solution to monitors operating at different resolutions; If you set the LOD for a very short height for a 4k monitor it will never kick in on monitors using lower resolutions.

I tried to explain some posts earlier, that the monitor resolution is not a factor in the lod calculation, these have nothing to do with each other.

[btrs]

James Ross, on 05 February 2022 - 06:00 AM, said:

Ah, this is unfortunate.

When you're happy with the glTF 2.0 support we can come back to this and see if there is a way to address it, or degrade the glTF visuals slightly for older hardware.

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..)