I would like to give a status report on this project. I started to implement the new model format as having a new geometry model in my head, that is more widely supported and used than our beloved .s format. But at this stage it turns out more to be a refresh of the whole 3D graphics subsystem, including the lighting shaders, LOD and animations.
I'm actually quite satisfied how the glTF models are appearing in the sim. The
test models are generally looking right, there are only one or two of them having some problems. Theese models are put here to help the engine developers to test and certify their glTF loader. There are some here that use extensions not supported by my loader, theese don't look right. But beyond theese I could name one, the
SimpleSkin, where one node is not animating as it should, and I couldn't figure out the reason yet. But anyway, the animations everywhere else I tested work alright, even at complicated models.
I have also added Image Based Lighting, which turned out to be an essential participant of the PBL lighting, because this is the part that enlightens the darkness of the scene. It involves using a fake environment map, that reflects on the mirroring parts and glasses, packed as a PNG in RGBD format, where the "D" channel acting as a divisor (in range 0..1) of the RGB channels to allow high dynamic range (HDR) lighting. This method was suggested in the
EXT_lights_image_based extension, although the extension itself is not implemented, because currently I use a sole central image for IBL, not allowing separate glTF-s to inject their own. But in the long-term future I could imagine to place IBL-only glTF-s in the routes for different places having different images reflected (an urban one, a rural one, a mountainous one, etc...). For now I donwloaded one with green plains, clouds and distant hills, this one will be fine for a start.
Btw the night illumination will need to be sorted out. Probably a different IBL image (actually two: diffuse + specular) will be needed for the night, and also we will need to agree how we want to use the glTF emission texture. FlightSim has a switch in the model whether the emission effect should follow the day-night cycle or should be in effect everytime. There is no "night texture" concept in the glTF, the PBL (with IBL) is a more advanced technique for lighting.
I've also implemented the LOD handling, according to the
MSFT_lod extension (node level LOD only yet, not material level, but I plan to add that as well). However I ran into a problem here: The glTF JSON deserializer I am using (The
sample loader from Khronos) is unfinished in regards of loading the "extras" field in the json structure. This field is used nowhere else as far as I know, only here in this extension, and I just couldn't figure out how to get the relevant data (the screen coverage array). The relevant piece is at around line 234 in the GltfShape.cs in my
PR, if someone has an idea, don't hold it back. (A sample model with MSFT_lod can be found
here, if someone wants to try it out.) Actually there seems to be an easy-like fix in the deserializer, but fixing that would mean we could no longer use the nuget package supplied, but rather we would need to maintain a copy of the lib in our own repository, and using the dll committed to the 3rdPartyLibs folder, as we do it with the openal-soft package currently with the increased number of sources.
Just an interesting fact regarding the screen coverage array: The MSFT_lod extension doesn't use distance-based lod-ding, it uses a different concept called screen coverage. As I figured out, probably it comes from the Unity, where the objects are lod-ded based on how much space is covered on the the screen by them. Actually Unity measures the height only, so I implemented it also this way: if the LOD level is set to have a screen coverage of e.g. 0.2, that means that it gets activated in case the object bounding box's visible height increases above 20% of the screen height.
There are quite a few of further extensions defined for the glTF specification. I've mentioned the EXT_lights_image_based and MSFT_lod above. But there are some more that is worth mentioning:
MSFT_packing_normalRoughnessMetallic,
MSFT_packing_occlusionRoughnessMetallic: Theese are different texture packings: what texture functions are packed together. Can easily be supported. Actually the shader support is already there, only the extension flag needs to be passed.
MSFT_texture_dds: glTF by its basic specification supports only jpg and png textures, this extension adds the dds. Because of MonoGame limitations, only BC1, BC2 and BC3 (DXT1, 3, 5) is supported, it is already implemented.
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.
KHR_lights_punctual: This extension adds the possibility to attach a light source to a model node. Supporting this would lead to really interesting scenery configurations, by allowing the random trackside objects to have real light sources attached, of 3 types: directional, point and spot. The spot light is in fact the same as is currently used as a headlight. Since supporting this would need the light receiving part to be "backported" to the .s objects, this would naturally bring the possibility of having more than one headlights (e.g. for AI trains) in the scene. This is not implemented yet.
KHR_materials_variants: This would allow for a mesh to have different materials with different textures. This would allow to have models with e.g. summer-winter textures, or a vehicle with multiple "skins". Exact usage is to be defined.
Those who interested can check the list and descriptions of the specified extension here:
https://github.com/K.../extensions/2.0
Unfortunately I had to elevate the GPU shader model version requirement to 4_0. In the last stable Openrails version it is 4_0_level9_1 and 4_0_level9_3, which is actually DirectX9.1 and DX9.3, but it was not possible to transfer enough data between the vertex shader and the pixel shader with those. So the glTF with PBR lighting minimum requirement is the major shader model 4_0 version, which is DX10 (or most probably DX10.1). This is why I had to pull the PR containing the glTF support from the unstable version, people were complaining that their shader compiler couldn't cope with the elevated requirements.
I think it's enough for today,
3 Votes
Log In
Register Now!
Help
