PBR or Physically-based rendering

[icecode]

Which is why I think the argument of industry standards is misleading - we have no industry-standard art department to go along with the effort, nor any way to validate or enforce adherence to standards.

By that logic then we're wasting our time trying to implement a PBR workflow. The point of PBR is to unify material design so our aircraft developers can get a wide range of materials without tweaking physical parameters or any shader code. You either use it or you don't - it's not like the rest of the Effects/ folder is gonna get removed. It's 2017 and we are still using gl_Color. Standards get deprecated, and unless we move forward we're gonna have a bad time.

Whereas the 'industry' solution deferred rendering is not potentially but really unmaintained, so there's that - didn't really seem to help.

I don't buy that argument either since Rembrandt isn't a proper example of an "industry" solution. Deferred rendering doesn't inherently offer a worse performance than forward rendering, while Rembrandt does. The entire reason for lack of support from the community was its terrible performance, not its lack of potential.


Reiterating myself, you are probably right and any improvements are redundant. I'll try to adhere to ALS as much as I can, just as I have been doing until now.

[wlbragg]

The entire reason for lack of support from the community was its terrible performance, not its lack of potential.

I think the point is missed that the "lack of support" is really the lack of anyone willing to put their time into continuing and maintaining the code.

There really is only one person left dealing with rendering and that is ALS, until now. As soon as Icecode GL decides to take a break I think the continuance and maintenance of PBR code stops. At least until the next super PBR guru takes up the cause. If a "deferred rendering" guru came on board right now with proven updates and enhancements, we would see them included shortly in the code base.

I think Thorsten is absolutely correct in filtering everything rendering through a the FG use case. I also totally agree with the "special-purpose solutions" philosophy.

I'm not saying I wouldn't care to see a PBR implementation along side BOTH ALS and "deferred rendering". But I also know FG has something unique in ALS and that is nothing to scoff at either.

p.s. @Icecode GL, I am anxious to see what you come up with!

[Thorsten]

By that logic then we're wasting our time trying to implement a PBR workflow. The point of PBR is to unify material design so our aircraft developers can get a wide range of materials without tweaking physical parameters or any shader code.

Hm... my argument would be that we expand the toolkit available for developers, and that's worth the little overhead in maintenance this will create in the future (it's not a particularly invasive change). Also, it's closer to my personal thinking than Blinn-Phong.

What I mean is - you can solve some mechanics problem using Newtonian Mechanics, Lagrange Mechanics or Hamilton Mechanics - you always get a different set of equations - but the same solution in the end. Doesn't hurt to learn all three, so you can always pick the tool you like best for the problem at hand. As I said before, I don't think this can deliver you visuals you couldn't get otherwise - but it does so in a different description language, which makes some thing easier, other harder.

So - if we have aircraft developers who feel more comfy with a PBR workflow, it's a good thing (TM) to support it if the pain to gain ratio is reasonable - which it definitely is. I'm guessing some will prefer this workflow, others more artistic types will not - I don't have to take sides myself here.

Whether this is some 'standard' or not I don't really care - it doesn't factor into my considerations.

As soon as Icecode GL decides to take a break I think the continuance and maintenance of PBR code stops.

Nah... it's not magic, it's the same thing we're doing anyway in a different language. Internally the code generating the visuals is a variant of what we have anyway - there's only so many ways you can do reflection, roughness etc.

The entire reason for lack of support from the community was its terrible performance, not its lack of potential.

That's pretty much my entire point: If this were a game development environment where the whole code could have been designed / re-written to optimize deferred performance and contributors could have been ordered to deliver their models according to certain standards, it would have worked.

However, it is a messy OpenSource environment where manpower is scarce and temporary, you can't assign people to solve certain tasks, code develops organically into different direction and explores options and contributors do what they like. And thus performance remained a problem.

Reiterating myself, you are probably right and any improvements are redundant.

Look, I can't give a definite statement either way without actually examining an existing solution. But I can write my impression what the likely outcome of a pain to gain evaluation is (where pain includes everything from framerate hit over maintenance load for myself to maintenance requirements for users).

I see a lot of potential in the PBR effect based on what I understand about the technology, I don't see much point in burning some framrate in improving ambient light distribution based on my experiments with different ambient light distributions.

I may be wrong and may have missed a big thing (and in that case the challenge for you is to convince me that I'm wrong), but I honestly believe the weak spot of ALS that needs to be improved next is not the lighting computation.

(Big visual things we miss - can we render fog and clouds illuminated by city lights at night? I'd guess so... Can we find a cheap solution for building shadows like we do for trees? Probably... Can we do better with eye adaption to light? Likely... And so on...)

[icecode]

I'm guessing some will prefer this workflow, others more artistic types will not - I don't have to take sides myself here.

Anyone who calls himself an artist will prefer the PBR workflow. That's a fact.


Point well taken. As I said I'm going to adhere to ALS as much as possible, but sometimes it's hard since I don't have your background/ALS deep understanding. Perhaps you could take a look at the indirect lighting part of the PBR shader and tune it to your liking since it's probably terrible now.

[Thorsten]

Anyone who calls himself an artist will prefer the PBR workflow. That's a fact.

Funny - I always seem to get into arguments with the artistic minded people for stubbornly sticking to 'this is the equation, this is its solution, end of story'.

I guess we'll see how it goes once this is available.

but sometimes it's hard since I don't have your background/ALS deep understanding.

Which is the point where I offered to help with anything ALS-specific that's unclear. But I can also go over the code once it's done.

[Necolatis]

What parameters/textures are you planning to put in?

Will it be the basic stuff like?:
albedo, roughness, metallic, normal, light map

Our current ALS (ultra) shader does these, is any of these planned?
Reflection map
Fresnel/rainbow effect
Rain splashes


I noticed several PBR shaders out there use Ambient occlusion map and/or emission map, is that planned?

Sorry if it is too early to ask all this.

[icecode]

The shader forces the user to provide at least 5 main textures: albedo, normal, metallic, roughness and ambient occlusion. If they are not provided, default values are used, but that goes against the whole purpose of PBR.

Fresnel is already taken into account in the BRDF, so no need to hack it in like we did with Blinn-Phong.

Rain splashes and dirt effects from ALS can be easily copied-pasted into the PBR shader, so no problem there. Although you might consider adding them manually instead of procedurally, considering that now we have the option of controlling the specularity of the material at texel level via the roughness map.

Emission maps won't be supported due to FG current rendering limitations. Without Rembrandt there is no trivial way of adding other light sources to the scene.

About reflection maps... well, I've been quite busy with that lately. Some background:
Lighting in real time applications can be divided into direct lighting and indirect lighting. In the context of FG (or any other outdoor scene) we can consider the sun to be the direct lighting source and the sky to be the indirect lighting source. There are two ways for a surface to reflect light: diffuse and specular. In a diffuse reflection, the incoming light ray is reflected at many angles, while in a specular reflection the light ray is reflected at a single direction. Of course, the two types of reflections obey the conservation of energy: a really diffuse material will have a low specularity and viceversa, i.e. you can't reflect more light and you are recieving.

Direct lighting is sorted out. We just need the energy emitted by the sun at different times of day, which ALS already provides, and we can calculate the diffuse and specular components. However, in indirect lighting the diffuse component corresponds to the general light emitted in every direction by the sky. ALS already provides that too (I think). The problem comes with the specular term, which is the reflection of a single light ray coming from the sky, i.e. a perfect reflection of the environment. So for example a material with a roughness of 0 (really high specularity) will be a perfect mirror.

The current way environment maps are done in FG is "cheating", they reflect a pre-made cubemap. That cubemap doesn't correspond to the real environment, so it wouldn't make sense that an aircraft reflects a noon scene while the sun is actually setting. The proper and amazing solution would be to generate a low-res cubemap of the scenery and plug it into the shader, but that isn't an option considering again the state of FG rendering.

I've been racking my brains trying to find some magic solution but I don't see a satisfactory answer. I thought of the skydome shader reflection thing I mentioned in a previous post but Thorsten didn't like it too much.

Apart from these problems, the shader has been pretty much done for a while now, so don't worry about asking about it.

[Necolatis]

Cool, thanks.

What about light map(s)?

[icecode]

Oh sorry, I forgot about them! Yes, they'll be supported.

[Thorsten]

I've been racking my brains trying to find some magic solution but I don't see a satisfactory answer. I thought of the skydome shader reflection thing I mentioned in a previous post but Thorsten didn't like it too much.

Let me try to put out an idea.

What you actually see in reflections with the strength we need (which isn't really mirror-quality) is general color and contrasts, perhaps some structures. The most important thing is you see something reflected which changes with view position, then come the details.

The skydome is pretty involved to compute, and moreover it is most of the time blue with some haze fringes - not really high-contrast. It also won't show the main high contrast thing, i.e. clouds. Nor will it show any terrain.

I've been thinking on and off to create a procedural environment map. The shader knows where in relation to the main cloud layer we are and how many clouds there are already. So we can draw cloud layers from a texture atlas above or below as required. The shader knows the direct light color at aircraft position, so we can fringe the sunward horizon haze with reddish colors when needed.

It would be useful for more than one purpose to assemble a general picture of what terrain we overfly (think ambient sounds, think city lights illuminating fog,...) and assuming we had a low-cost routine which provides that information, we could select a terrain layer from the atlas and mix it into the environment map (and even fog it, since we have visibility information).

I believe GLSL side that would amount to some trigonometry and a couple of texture lookup/mix statements but be fairly flexible in covering the essentials of a changing environment as long as we don't ask for mirror-like reflections.

Would that interest you?

[icecode]

As long as it doesn't create a massive performance overhead and looks realistic enough for near perfect mirror surfaces, I'm open to anything. It'd definitely be nice to have some specular highlights from the city at night. My current code is at my git repo in case you wanna experiment. Also, indirect lighting is completely disabled there.

[Thorsten]

looks realistic enough for near perfect mirror surfaces

Nothing short of actually rendering the environment will do that.

It will look plausible enough for your run of the mill airplane fuselage, that's all.

Also, I have to admit that it's not high priority for me - I've been toying with the idea for over a year now - so this might appear at a timescale of a few months, but not within weeks.

[Necolatis]

I could not resist trying it out.

Do I need to add anything other than this:

Code: Select all

<parameters>
            <texture n="0">
                <image>Aircraft/JA37/Models/Effects/PBR/handle-albedo.png</image>
                <type>2d</type>
                <filter>linear-mipmap-linear</filter>
                <wrap-s>repeat</wrap-s>
                <wrap-t>repeat</wrap-t>
                <internal-format>normalized</internal-format>
            </texture>
            <texture n="1">
                <image>Aircraft/JA37/Models/Effects/PBR/handle-normal.png</image>
                <type>2d</type>
                <filter>linear-mipmap-linear</filter>
                <wrap-s>repeat</wrap-s>
                <wrap-t>repeat</wrap-t>
                <internal-format>normalized</internal-format>
            </texture>
            <texture n="2">
                <image>Aircraft/JA37/Models/Effects/PBR/handle-metallic.png</image>
                <type>2d</type>
                <filter>linear-mipmap-linear</filter>
                <wrap-s>repeat</wrap-s>
                <wrap-t>repeat</wrap-t>
                <internal-format>normalized</internal-format>
            </texture>
            <texture n="3">
                <image>Aircraft/JA37/Models/Effects/PBR/handle-roughness.png</image>
                <type>2d</type>
                <filter>linear-mipmap-linear</filter>
                <wrap-s>repeat</wrap-s>
                <wrap-t>repeat</wrap-t>
                <internal-format>normalized</internal-format>
            </texture>
            <texture n="4">
                <image>Aircraft/JA37/Models/Effects/PBR/handle-ambient.png</image>
                <type>2d</type>
                <filter>linear-mipmap-linear</filter>
                <wrap-s>repeat</wrap-s>
                <wrap-t>repeat</wrap-t>
                <internal-format>normalized</internal-format>
            </texture>
        </parameters>


[icecode]

Assuming you copied the files to their corresponding directories in FGData (model-pbr.eff, model-ALS-pbr.vert and model-ALS-pbr.frag), then you just need to create a local effect file for the aircraft that inherits from Effects/model-pbr and provide the 5 textures (albedo isn't needed since texture unit 0 is automatically provided by the model loader). You also need to provide the tangent and binormal vectors if you are using a normal map. It's almost exactly the same as the model-ALS-ultra shader.

Here is the effect file I use for the ec130 to test the shader:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

<PropertyList>
  <name>ec130_b4_reflect-uber</name>
  <inherits-from>Effects/model-pbr</inherits-from>
  <parameters>
    <texture n="1">
      <image>Aircraft/ec130/Models/Effects/pbr/normal_map.png</image>
      <filter>linear-mipmap-linear</filter>
      <wrap-s>repeat</wrap-s>
      <wrap-t>repeat</wrap-t>
      <internal-format>normalized</internal-format>
    </texture>
    <texture n="2">
      <image>Aircraft/ec130/Models/Effects/pbr/black.png</image>
      <filter>linear-mipmap-linear</filter>
      <wrap-s>repeat</wrap-s>
      <wrap-t>repeat</wrap-t>
      <internal-format>normalized</internal-format>
    </texture>
    <texture n="3">
      <image>Aircraft/ec130/Models/Effects/pbr/dark_grey.png</image>
      <filter>linear-mipmap-linear</filter>
      <wrap-s>repeat</wrap-s>
      <wrap-t>repeat</wrap-t>
      <internal-format>normalized</internal-format>
    </texture>
    <texture n="4">
      <image>Aircraft/ec130/Models/Effects/pbr/white.png</image>
      <filter>linear-mipmap-linear</filter>
      <wrap-s>repeat</wrap-s>
      <wrap-t>repeat</wrap-t>
      <internal-format>normalized</internal-format>
    </texture>
   
  </parameters>

<!-- ####################
### NORMALMAP INCLUDE ###
######################### -->

  <generate>
    <tangent type="int">6</tangent>
    <binormal type="int">7</binormal>
  </generate>

  <technique n="4">
    <pass>
      <program>
        <attribute>
          <name>tangent</name>
          <index>6</index>
        </attribute>
        <attribute>
          <name>binormal</name>
          <index>7</index>
        </attribute>
      </program>
    </pass>
  </technique>

  <technique n="7">
    <pass>
      <program>
        <attribute>
          <name>tangent</name>
          <index>6</index>
        </attribute>
        <attribute>
          <name>binormal</name>
          <index>7</index>
        </attribute>
      </program>
    </pass>
  </technique>

  <technique n="9">
    <pass>
    <program>
      <attribute>
      <name>tangent</name>
      <index>6</index>
      </attribute>
      <attribute>
      <name>binormal</name>
      <index>7</index>
      </attribute>
    </program>
    </pass>
  </technique>

<!-- ########################
### END NORMALMAP INCLUDE ###
############################# -->
</PropertyList>


[Johan G]

Quick question: How related is this to principaled (or "Disney") shaders, for example in Blender (like demonstrated in this short video)?