Board index FlightGear Development Effects and shaders

PBR or Physically-based rendering

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: PBR or Physically-based rendering

Postby Icecode GL » Sun Jul 30, 2017 9:33 pm

Very related, they are in fact almost the same thing. I based the shader on Unreal Engine's approach, which is heavily influenced by Disney. The only major difference between Disney's and Epic's is the diffuse shading model, but the differences in the result are negligible.

Also note that Blender and Disney use path tracers, so even if the BRDFs are the same, the results in a traditional rasterizer are worse by default (no global illumination, caustics, etc etc.)

EDIT: A material rendered in Blender Cycles using the Principled Shader will share the same look in FG, of course with the limitations of being a rasterizer as I said before.
Last edited by Icecode GL on Mon Jul 31, 2017 1:42 am, edited 1 time in total.
Icecode GL
 
Posts: 506
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: PBR or Physically-based rendering

Postby vnts » Mon Jul 31, 2017 12:35 am

Thorsten wrote in Sun Jul 30, 2017 5:02 am:the strength we need (which isn't really mirror-quality) is general color and contrasts, perhaps some structures

Icecode GL wrote in Sun Jul 30, 2017 12:41 am:and the sky to be the indirect lighting source

Just a thought: If it is possible to render a skydome to a very low-res texture that can be then mixed in a procedural environment map (automatically update with skydome shader improvements). Can be infrequently updated (frame spacing may still be affected). Maybe better to precompute in one go at intervals & altitudes for the entire day. Leaves clouds and terrain colour & shape detail to be added. Maybe overkill. Thought about previously, but did not know terminology to express, just a conceptual understanding.
Icecode GL wrote in Sun Jul 30, 2017 12:41 am: indirect lighting the diffuse component corresponds to the general light emitted in every direction by the sky

Wondered about this for skydome light through each -major- 'window like gap' for aircraft cockpit interiors.

Perhaps (?) every major segment can have an average radiance and light colour assigned. This may be calculated by masking a procedural floating point skydome map, then averaging it and scaling by % covered.

The mask may need a texture to define each region, or maybe rough angles subtending gaps can be defined via text file and masked algorithmically.

Each major gap region would need a light map channel. The channel would contain results of offline raytracing similar to that used in some cockpits assuming a 'uniform emissive brightness' for each major 'window like gap' surface. Each lightmap channel would be coloured and scaled by radiance appropriately.

Very shiny surfaces may need (?) a procedural part of the cockpit environment map combining with the external environment map where there are window like regions.

This may be too expensive and not worth pain. It may be (?) that better radiosity from glass surfaces at day time could be a major missing step as opposed to needing improved textures or surface shading, similar to effectiveness of raytraced shadows & illumination at night from cockpit lights. I'm not sure, or even if this level of approximation would be effective. Just a thought.

For external procedural environment maps, just procedurally colouring grey concrete/tarmac when landed, or changing ambient occlusion factor on undersides may be noticeable as people are more likely to look closely at external models.

Kind regards
vnts
 
Posts: 82
Joined: Thu Apr 02, 2015 12:29 am

Re: PBR or Physically-based rendering

Postby Thorsten » Mon Jul 31, 2017 5:52 am

This may be too expensive and not worth pain. It may be (?) that better radiosity from glass surfaces at day time could be a major missing step


There is support for irradiance mapping in the interior shaders and has been for quite a while. You can select between three different map types (airliner - windows in front, fighter - canopy transparent above and GA - windows around you) and specify the map strength, and for artificial light e.g. from instruments you can define a residual ambience with its own maps. We could even add more maps if needed.

All this is documented, but the number of developers interested in using it seems... limited.

In the space shader family, you can force in a third component (I did that mainly to go from 'atmosphere' to 'no atmosphere' for ambient lighting) and in fact the Shuttle has a very detailed ambient light model taking into account orientation (do we have Earth-facing windows), things like plasma glow during entry as well as artificial lighting.

If you wanted, you could use this to generate a colored ambience like for a gondola hanging underneath a semi-transparent gas bag.

Since you can change all the options runtime, you can generate quite a varying lighting environment at hardly any framerate cost.

or changing ambient occlusion factor on undersides


Now that's a neat idea - should be easy to do.
Thorsten
 
Posts: 10636
Joined: Mon Nov 02, 2009 8:33 am

Re: PBR or Physically-based rendering

Postby Icecode GL » Mon Jul 31, 2017 10:20 am

All this is documented, but the number of developers interested in using it seems... limited.


The difference in using irradiance maps or not is not that noticeable. With these features an important factor to consider is the "pain-gain ratio", i.e. is it worth for the aircraft developer to document himself on all of that stuff just for such small change?
Icecode GL
 
Posts: 506
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: PBR or Physically-based rendering

Postby Thorsten » Mon Jul 31, 2017 10:37 am

The difference in using irradiance maps or not is not that noticeable. With these features an important factor to consider is the "pain-gain ratio", i.e. is it worth for the aircraft developer to document himself on all of that stuff just for such small change?


I dunno... flat interior lighting without irradiance map:

Image

Irradiance map for light from the sides brings out aircraft interior much better.

Image

The difference is two lines in the effect declaration. As far as I'm concerned that's a lot of bang for the buck, but to each his own.
Thorsten
 
Posts: 10636
Joined: Mon Nov 02, 2009 8:33 am

Re: PBR or Physically-based rendering

Postby Necolatis » Mon Jul 31, 2017 2:44 pm

Icecode GL wrote in Sun Jul 30, 2017 4:44 pm: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.


Ok, did all that. Cannot get the normal map to show. And get a bluish coloring of the object.

I probably did something stupid.
If your interested in seeing what I input here it is:

Albedo
Image

Ambient occlusion
Image

Metallic
Image

Normal
Image

Roughness
Image

UV map for reference
Image

AC3D model
https://drive.google.com/open?id=0B49qi ... mZSR0dpNUk

XML to load the AC3D and load the textures into the PBR shader
https://drive.google.com/open?id=0B49qi ... EQ5Ulc3ajQ
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore


Hangar: https://sites.google.com/site/fghangar/
User avatar
Necolatis
 
Posts: 1907
Joined: Mon Oct 29, 2012 12:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2018.3.2
OS: Windows 10

Re: PBR or Physically-based rendering

Postby vnts » Wed Aug 02, 2017 4:34 am

Icecode GL wrote in Mon Jul 31, 2017 10:20 am:The difference in using irradiance maps or not is not that noticeable. With these features an important factor to consider is the "pain-gain ratio", i.e. is it worth for the aircraft developer to document himself on all of that stuff just for such small change?

From reading the wiki, irradiance from transparent surfaces is done algorithmically in the shader where only rough dominant light directions specified. It has the potential to affect lighting in different ways in different situations. Potentially changes with orientation relative to sunsets/terrain, can mixes with cockpit/sunlight sources in complex ways, not easily shown in one screen shot.

This is my understanding -so far- on radiosity & irraddiance maps:

Irradiance from the environment [sky dome,clouds,terrain] is a very large part of daytime cockpit. Lot of gain.

When the sun is overhead, and no canopy, >100%< of the daytime illumination comes from the environment. It's everything, a very notable % the time people fly. Glass regions are like area lights and can be considered as direct illuminators, casting soft-shadows.

Mixing of light colours from environment & cockpit sources, and light spectra competing for dominance is a factor. Skydome light is actually blue during day (even after 1 Rayleigh bounce). Terrain & clouds have their own spectra. It's only the vision systems' colour constancy that helps keep the scene mostly legible, but this is not perfect & reproducing how it fails is a part of achieving realism. I suspect the quality of the illuminant is consciously perceived as well e.g. being able to tell time based on daylight quality.

With glass regions facing the horizon, illumination can be reddish at sunset (google image). It will change as the pitch changes becoming bluer&dim, or as the glass regions face away from the sun. An overhead canopy means competing spectra, same with cockpit lights.

Taking light from glass surfaces as first bounce, the 2nd, 3rd, etc. produce ambient effects. Light from say a green surface close to a meeting point can colour a 2nd surface green. Google image showing bounces and light from nearby surfaces. Human vision also uses gradients in light to guage 3d depth&structure.

A substancial portion of percieved difference between a realtime 3d render and a photo are the multiple bounces, even when there is direct sun illumination (wiki image). That's what I meant when I suggested that more might be achieved by better radiosity, than modest improvements to textures or shading..2nd wiki image is more photolike even with minimal texture detail, the first is very recognisable with 'realtime 3d render' look. When there is no sun illumination, environmental irradiance dominates.

As I understand, modern realtime 3d applications goto quite some lengths - using grids containing precomputed environment radiance maps linearly decomposed into vector spaces with spherical harmonic basis functions (light probes IIRC). This assists with non-static geometry moving around in a static lightfield. For cockpits geometry is static or restricted (switches with limited states etc.), so accuracy is easily achievable without going to such lengths.

Doing the full raytrace, or numerical solution of Maxwell's equations, would give powerful impact. Involves looking at flux through each point in glass surface in every direction and including multiple bounces around the cockpit. Specifying rough directions of glass regions as done currently is a big improvement for a text file change.

Treating each glass region as a area light is an approximation. The light is given 1 uniform intensity and brightness, doesn't cover light variation across the skydome, or the rays passing at different angles at each point (transmission pattern). It does include the average intensity and hue/sat of each area light. So it accounts for average colour of the environment each surface points at, including asymmetries in glass surfaces. Calculations used in ambient occlusion maps are a rough approximation that records hemispherical exposure to light at points on a surface, these become unnecessary with raytraced lightmaps. The full benefit of raytrace is available for each area light: soft shadows/multiple bounces off surfaces with different properties/occlusion effects without ambient occlusion approximation.

Each area light is approximated to be uniformly white and can be assigned a raytraced lightmap containing intensity, but won't include colouring effects of neighbouring surfaces unless more space is assigned. Calculating the average hue/sat and floating point intensity for each area light can be calculated by using an opacity map to mask an environment map. Floating point environment intensity can give extremely delicate, realistic competing light sources like in the first image where it's possible to intuitively get a feeling for the offscreen yellow-ish light environment. Possible to split up large surfaces like canopies into multiple area lights.

That's as much as I know/can say on precomputed irradiance mapping (from a conceptual view). The notion of treating glass regions as area light is an approximation, cannot think of a closer way to approach raytraced quality in real time. Not sure how close the approximation gets to the full soln., what is lost, or the pain to gain factors involved compared to other approximations. Thorsten has looked into all this and is better positioned to say.

Kind regards
vnts
 
Posts: 82
Joined: Thu Apr 02, 2015 12:29 am

Re: PBR or Physically-based rendering

Postby Thorsten » Wed Aug 02, 2017 5:25 am

Doing the full raytrace, or numerical solution of Maxwell's equations, would give powerful impact.


That is almost doable right now (just, as usual, someone has to do it).

* use the radiosity solver of your choice to compute lightmaps for each window / major orientation
* lightmap intensity can be driven runtime, so solve for orientation of the windows relative to the environment light sources (the Shuttle lighting code exemplifies that)
* force the native ambience to zero and use the lightmaps instead

(due to the way the lightmap colors are specified as vec3, we can't make them runtime configurable at the moment, but this can be changed by inputting three floats instead - or alternatively let ALS solve the light)

I'm happy to make the changes to the interior shader to accept arbitrary colors into the lightmaps someone wants to try.

Thorsten has looked into all this and is better positioned to say.


I have to say, I am pretty happy with the Shuttle flightdeck indirect lighting. You have all the subtle factors in - it changes color (Earthlight is blue, sunlight bouncing is white, instrument light or plasma light orange, artificial light bouncing yellow-white), it changes directionality dependent on dominant light source, it changes a lot going from in atmosphere to out of the atmosphere...

I'd like to have more AO in, but due to the way texture space is organized and close to the limit, that's currently very hard to do and we decided not to push it.

Maybe you just fire it up and take a look what we can already do (and how much code is supporting it) before discussing what else we may need.
Thorsten
 
Posts: 10636
Joined: Mon Nov 02, 2009 8:33 am

Re: PBR or Physically-based rendering

Postby Icecode GL » Wed Aug 02, 2017 11:19 am

Ok, did all that. Cannot get the normal map to show. And get a bluish coloring of the object.


Sorry for the late reply, I haven't been able to fire up FG these days. I think you should do a separate effect file (.eff) with the effect definition, and then do the <effect> declaration in the model xml. I haven't done anything related to aircraft development in a while so I'm not sure.


In the topic of interior irradiance mapping, I'm personally not that interested for now.
Icecode GL
 
Posts: 506
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: PBR or Physically-based rendering

Postby Necolatis » Wed Aug 02, 2017 12:47 pm

I tried that too Icecode GL, same result.
It should also be the the same, only difference should be that when you declare the effect in the xml instead of separate effect file, you have the advantage that you don't have to restart FG every time you make a change, you can just go into debug menu and reload model.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore


Hangar: https://sites.google.com/site/fghangar/
User avatar
Necolatis
 
Posts: 1907
Joined: Mon Oct 29, 2012 12:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2018.3.2
OS: Windows 10

Re: PBR or Physically-based rendering

Postby Thorsten » Wed Aug 02, 2017 1:08 pm

In the topic of interior irradiance mapping, I'm personally not that interested for now.


For the exterior, let me suggest to take the ambient light (sky-blue) color and the haze color and make a lookup function blending the haze in at the horizon - that should get you where we are now - and I can go and refine that function to include clouds and terrain as needed.
Thorsten
 
Posts: 10636
Joined: Mon Nov 02, 2009 8:33 am

Re: PBR or Physically-based rendering

Postby Necolatis » Sat Sep 23, 2017 9:49 pm

Will the PBR shader take into account that lightning is completely different with Advanced weather versus basic weather?

Image
Image
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore


Hangar: https://sites.google.com/site/fghangar/
User avatar
Necolatis
 
Posts: 1907
Joined: Mon Oct 29, 2012 12:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2018.3.2
OS: Windows 10

Re: PBR or Physically-based rendering

Postby Thorsten » Sun Sep 24, 2017 5:20 am

The lighting is computed the same in both frameworks, just the amount of information on cloud cover, high atmosphere haze and similar the weather systems forward to the renderer is different. BW doesn't know of high hazes, so it always reports them as zero and never produces any down-scattering. BW also doesn't report mean or local attenuation of the light by cloud cover above.

The interface is all there and completely agnostic to the weather system - if someone decides to extend BW to supply the information the renderer will process it fine.
Thorsten
 
Posts: 10636
Joined: Mon Nov 02, 2009 8:33 am

Re: PBR or Physically-based rendering

Postby Necolatis » Sun Sep 24, 2017 7:29 am

Ok, thanks. I guess I'll just adjust so it looks decent in one of the weather settings, and the people using the other setting will just have settle for less pretty.

It would all just be easier if everybody used same renderer and weather.
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore


Hangar: https://sites.google.com/site/fghangar/
User avatar
Necolatis
 
Posts: 1907
Joined: Mon Oct 29, 2012 12:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2018.3.2
OS: Windows 10

Re: PBR or Physically-based rendering

Postby sidi762 » Sun May 06, 2018 12:46 pm

It's 8 month since last post. Are there any progress were made?
sidi762
 
Posts: 114
Joined: Sat Jun 18, 2016 8:15 am
Callsign: DAG0762
Version: 2017.1.3
OS: MacOS Sierra

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests