HDR support

[hbeni]

HDR is the next FGFS renderer and we should make the plane compliant to it some time...

To start with it, add --compositor=Compositor/HDR/hdr to launcher.

Ref:

• How to PBR an aircraft? (FGFS Forum topic)
• https://wiki.flightgear.org/HDR_Pipeline

[TheFGFSEagle]

The compositor pipeline is called HDR, not PBR - maybe you could correct that as it might be confusing to others ! ;)

[CyberGamer224466]

I'm happy to help with that, I can do the PBR materials but I haven't figured out how to make screens or lighting compatible with HDR yet.

[hbeni]

Sure :)

if you need to touch the model, be aware that there are currently branches modifying that too.

[hbeni]

Question: how are we organizing this, should the pbr‘ed planes go into a separate branch or are they downward compatible so we can just merge into master?

[wlbragg]

@hbeni im not sure how to best organize a changeover. Here is what I have come across after starting on this with the c172p, j3cub and the Aircrane.

First, I don't know the details about how one is to use and organize PBR textures. Can or are we going to take the same textures we currently use and convert them to PBR textures, how? You have a texture sheet currently that has plastics, metals, rubber, etc., all on the same texture. The Aircrane interior, for example, I think is currently the farthest along of any aircraft so far that has had PBR texturing applied. What I have done so far, right or wrong, is to take a stand alone PBR ORM texture, typically 2048x2048 and uv map some interior object to it, like the interior cabin pole supports to scratched-shiny-metal. I do the same for say the leather seats using a different PBR black-leather texture. I continued doing this for many of the interior parts, panels, flooring, seat frames. Those PBR textures come complete with the other needed support textures types, shineness, normal, etc. Those are applied in the effects file. Now this would continue to be done with every object in that is the aircraft. This would leave you with a ton of textures and no way to organize paint kits and the likes. So what is another option? Take and existing standard texture and upgrade it to a PBR texture? How? Can that be done? Can you have black-leather, brown-leather, worn-shiny-metal, rusted-metal, rubber, plastic, etc. all on the same texture sheet and then make the shininess and normal map textures from that sheet? Can you leave the existing uv-mappings of multiple objects and apply all those supporting PBR textures using the effects definitions to the same multi-PBR-texture sheet? How much work will that be to edit and create the new multi-PBR-texture sheet and who is going to do it? That is the first questions that came to my mind as I started doing this?

[wlbragg]

Thought:

I guess if I were to test the idea of converting an existing texture, I would bring it into gimp with a uv outline map of existing mappings (can be created in Blender) as layer to use for a guide, then replace the existing image with the ORM texture of choice for each different texture mapped on that sheet. Once that is done, then make the shineness and normal textures to match? Is this possible, is this a reasonable way to do this? When done you would still be able to use things like paint kits, what kind of conversions would they need? It's going to require some thought on what is to be the best practice here.

[CyberGamer224466]

It'd be way easier to apply separate texture maps for different parts of the model. Then you just have to have different effect files for each object that uses a different texture but if some are using the same texture they can use the same effect files. I use this approach.

I think that for now it would be way more work if we'd try to fit all different texture maps on one map.

Also the PBR'ed aircraft aren't backwards compatible, at least for now. The ALS shader should be able to also display the same maps as HDR and then we could have real compatibility. Or the second option would be that the aircraft would detect when you're using HDR and when ALS and based on that swap effect files or models that it's using.

[CyberGamer224466]

Also, I think that if we're going to go PBR we would need to create a new PBR branch.

[wlbragg]

Yes, on the PBR branch. I don't think we will be able to merge it into master as they are going to likely be really different textures as we are discussing.

But so far the question of paint kits and liveries have not been addressed. So I agree somewhat with @CyberGamer about the separate texture maps for the different parts of the model, that is what I have been doing so far for all aircraft I am applying PBR to. But I still don't have a definitive opinion as to whether or not that is the best practice. It is the easiest as far as converting one of these existing aircraft to look good. But it is going to make everything else harder, we haven't even discussed what that does to the creation of lightmaps, if we even are going to have them. I think this all needs to be hashed out before anyone starts in ernest to convert any of these existing models to a production level PBR Rendered model. I did it the way I did it strictly to test it and see immediate results, not as a blueprint for others to follow or with any real though as to what issues it will raise for other disciplines.

[TheFGFSEagle]

Yeah, PBR is not backwards compatible at all, at least if you have to modify textures for it - in any case, using model-pbr is not since that effect is simply not available on non-PBR.

@CyberGamer224466 since you seem to know a whole lot about this whole PBR stuff - why do any textures even need to modified at all ?

[CyberGamer224466]

We need to modify the textures because current ones are just a bunch of smaller textures stuck together and what we need now is different ones for ORM, normal maps etc.

[wlbragg]

PBR is a specific type of rendering process requiring, as CyberGamer224466 stated, ORM and normal textures to go along with the base albedo texture. This is "PBR". Put that with HDR and we get some really good looking graphics. We can do the HDR without it, but were only using half of the capabilities of what icecode is creating for FlightGear.

[TheFGFSEagle]

but … we have normal maps already ? sorry, but I don't get it yet … :/ and what is ORM ?

[wlbragg]

In regards to a normal map, yes we do, for the exterior for example. If we convert the existing texture, (not the normal map), but the texture we use for the exterior and the ones for the livaries to PBR then yes the normal map we have would work. But if we have to break down the main single texture currently used into different PBR specifice textures such as one for rubber, one for shiny metal, one for plastic, one for fiberglass, etc., then the normal maps have to be made for each on as well. In our case a PBR texture is the base texture (albedo) + a ORM texture which is a shineness, roughness and reflectivity combined into a 3 channel RGB texture which is used in the effect definition and normal texture also applied in an effects definition.

See https://marmoset.co/posts/physically-based-rendering-and-you-can-too/

[wlbragg]

For example, how do you convert the rubber in this current default texture to a PBR, ORM style texture.

Current defaul texture for rubber tires.

PBR / ORM textures for rubber. albedo texture ORM texture normal texture

[HHS81]

It'd be way easier to apply separate texture maps for different parts of the model. Then you just have to have different effect files for each object that uses a different texture but if some are using the same texture they can use the same effect files. I use this approach.

I think that for now it would be way more work if we'd try to fit all different texture maps on one map.

Would make things easier, but would mabye needs much more RAM, if you have many different materials. You way was not recommended in the past, and creating texture maps isn't difficult, as Blender has the tools for it. Btw.: X-Plane uses HDR, pretty much the same way we do now (just much better- and much better framerates!). Can't tell for the Payware aicraft, but the default aircraft uses texture maps, organized in objects and not in materials. As an example: X-Planes A330

Or the second option would be that the aircraft would detect when you're using HDR and when ALS and based on that swap effect files or models that it's using.

I'm not sure if this possible, if so then maybe in the .eff-files.

[wlbragg]

Hi @HHS81

Looking at X-Plane flow, ie;

A330_fuselage_a_ALB, (albedo) A330_fuselage_a_MAT, (ORM) A330_fuselage_a_NRM, (normal)

That is what I am referring to as converting our existing texture to a PBR/ORM texture. My concern, in our texture the tires are relatively small, can we get the nice resolution if we change the rubber in that image to a representative sample of albedo 2048x2048 texture I posted above? What will that look like, will it be a high enough resolution to look good? And, someone has to modify all these textures. I guess someone just needs to try it. I think it is the proper way to do this even if we lose a bit of resolution detail. That is where the real work is going to be. But if we don't have to remap everything, then it's just texture modifications and effects definitions to do a decent conversion.

[wlbragg]

I'm not sure if this possible, if so then maybe in the .eff-files.

I could potentially see this being possible starting at the variant definition.

Variant ALS calls Model/c182s-als.xml Variant PBS calls Model/c182s-pbr.xml

The differences in these two models are the .ac, textures and the effects definitions applied to them. I'm pretty sure it can be done this way. But do we want to? In the future, we may not even care about anything but the PBR/ORM version. If we get to the point where we only care about the PBR version, then the other variant and its associated files are deleted. It wouldn't be that difficult if we keep the folders and files for each isolate from each other.

[HHS81]

I'm not sure if this possible, if so then maybe in the .eff-files.

I could potentially see this being possible starting at the variant definition.

Variant ALS calls Model/c182s-als.xml Variant PBS calls Model/c182s-pbr.xml

The differences in these two models are the .ac, textures and the effects definitions applied to them. I'm pretty sure it can be done this way. But do we want to? In the future, we may not even care about anything but the PBR/ORM version. If we get to the point where we only care about the PBR version, then the other variant and its associated files are deleted. It wouldn't be that difficult if we keep the folders and files for each isolate from each other.

Ideed, the better method! 👍

[CyberGamer224466]

For example, how do you convert the rubber in this current default texture to a PBR, ORM style texture.

EDIT: removed duplicate graphics.

Yeah, it'd be quite difficult to convert those texture to separate smaller ones as we need a lot of different maps like your examples show, ORM, normal etc. Also the resolution is a big issue cause if we'd do it this way it'd be way too small.

[wlbragg]

Also the resolution is a big issue cause if we'd do it this way it'd be way too small.

Right, but this appears to be what x-plane is doing. I don't know how large their textures are, but a 4096 would go a long way to alleviate the resolution issue. Also a possible remapping of some object may be needed so you can get higher resolutions on objects that need it.

[hbeni]

I have read about the gltf format which a recent blender should be able to produce out of the box. If I have read that correctly, that export would produce all that is needed, and the materials are defined in the blender file. That I think does not need new textures. So if i understand correctly, that may be a less work intensive way to convert to HDR/PBR.

But I'm really out of this 3D stuff, and as I have a ATI card I cant assist in testing (yet). Also I would suggest we don't do the variant way:

• In my view its easier to just maintain the "master" branch here and have the most compatible code here. For people using PBR, they can easily download the pbr'ed plane from here.
• Additionally we should have a "PBR-master" branch where we do the advanced stuff. New features to "master" can easily be merged into that branch.
• Finally, when HDR/PBR gets default in flightgear (which I strongly assume it will some day), we will be easily able to merge the PBR branch into master and drop it, at which point we just need to maintain one single branch again.

[TheFGFSEagle]

That sounds like a good plan; also I can assist with HDR testing since I got my external Nvidia Quadro K620 to work (need to find a way to correct the overexposure first, though)