HLMS PBR BRDF

[SolarPortal]

Well, first, we are using our own HLMS for PBR using a metallic workflow and following the traditional shader of doing things world space over view space which gets more accurate results when taking PBR assets from other tools and engines. e.g. substance, 3d coat, etc...

We removed the reflection map and ambient lighting system and generated a so called Skylight which fills this all for us which only provides IBL based ambience, we render a cubemap of the world, mainly skybox/skydome or HDRi images with mip maps and then process this using a GGX NDF importance sampling technique in compute shader per mip map. This is known as the specular reflection texture which is then used in the reflection part of the shader, then we rendered an irradiance texture which is a small 32x32 cubemap with no mips for the diffuse IBL and ran a separate compute shader that computes Diffuse Irradiance for plans of a light probe based system later. However as @dark_sylinc said in another of your topics, using one of the higher mip maps of the prefiltered specular reflection can be used as the diffuse IBL, just don't do the reflection part of the calculation and use the geometry normal, normal texture multiplied by a TBN made up from world space normals, tangents and binormals.

We couldn't rely on the mip maps alone being generated as it did not produce the accurate results needed as seen across other top engines. It also makes the roughness of far superior quality and preserves heat spots from bright lights in the image. It also really makes metal materials pop across the roughness. The specular reflection texture then has an increased blurring the higher the mips go.

Then add the 2 cubemaps to the hlms in a custom manner instead of baking the textures. 1 called reflection and the other as lightprobe.

Thats at least the basics of what we did with ours, but im still working the new shader.. currently adding vertex coloured based wind.

All i can say, is the hlms system is powerful if not confusing at first, but its very adaptable, so if there isnt something you like, get in there and tweak it out

Unfortunately i cannot share my code as its the new rendering for the next version of our engine, but for reference, this is a post of the differences: https://forum.aurasoft-skyline.co.uk/vi ... =32&t=2542

Hope this makes sense, as i have written it quickly.

Edit: the main reason we went ahead on making our own started because it was difficult to get normal maps in ambience that had little specular, which tended to make things overshine or a very bright fresnel with it turned up.

[xrgo]

That´s looking really really good congrats!
Long ago I went on a similar road (viewtopic.php?t=84156), but my main concern at that time was that the default implementation didn't support metallic workflow and I tried to simplify the shaders hopping for better performance (I do VR).
But soon metallic workflow was introduced and many other new features that I really wanted and integrating them back to my shaders was a pita, so I drop that went on the road of using the customization interfaces that the default pbs has (listener, custom_pieces, uservalues, inheriting, etc) and now when a new feature comes I just update ogre and replace all the shader templates with the new ones and all my customization just works and also the new features... I am sorry if I sound like "you've wasted time", its not my intention , just want to tell my experience so people that feel that the default implementation doesn't fit their need don't think that the only way to fix it is to write everything from scratch, the beautiful thing is that once you understand how hlms works you can do a lot of things in many different approaches.
And also wonder why your default looks that way, seems to me that is a gamma problem on the albedo texture more than a shader problem, my customization does very little different from the default one (mostly just extends it) and I think it looks great (thanks dark_sylinc!):

here's a video:


you can also see that I already have wind (vertex coloured based using a 3D noise texture), I can share details if you want

a capture (moved the gun away from shadows):


Cheers! and great work!
viva Ogre!

[SolarPortal]

hey xrgo,

I am sorry if I sound like "you've wasted time", its not my intention , just want to tell my experience so people that feel that the default implementation doesn't fit their need don't think that the only way to fix it is to write everything from scratch,

agreed, customising only certain pieces really is powerful and keeping up to date with the main ogre source base is generally a good idea haha XD, when going 2.2, we could be looking at moving back to the other shader as it has so many cool new features but will be porting the custom PBR shader and skylight to that. Although with our shaders we don't have to tweak any settings and leave it all at 1.0 values when using textures and it matches the other software which is something we desperately need in order to keep things simple for our end users.

Problem is that the more you look into PBR, everyone does it slightly differently which makes it hard to have an industry standard. Moving to worldspace instead of viewspace was the major thing for us as it makes certain effect a bit easier but for instance to use the forward 3d lights, all the light positions need multiplied by the inverse view matrix first. Not to sure why ogre went with view space over world space.

Nice idea with using the noise map instead vertex colours, might have a looky into that..

One of the next things we will also be tackling is tessellation with pn triangles just to get that bit extra quality.

As for the gamma, we were trying to match the textures viewed in render closely to the colour of the texture if set in a standard lighting setting, but then when applying HDRi's, it gives consistent results, very much like yours does, the only part i notice, is that with a bright spot on the environment, there should be a brighter reflection at that part whereas a typical gaussian filter darkens the brighter spots the more it blurs.

When i compared the old roughness to the new diffuse irradiance technique, there was a huge difference in look and quality(old uses mips to get the blur which can be quite noticeable on certain environment maps and materials whereas using the compute shader means we have higher mips with blurs which produce a smoother more accurate result) and of course ambient lighting normals that don't rely on the specular reflection to highlight to normals is a big render improvement. I would say that our shader more closely resembles unreal engine without all the post processing effects lol

But still, very impressive xrgo It's cool to see how the original adopters of the 2.x pipeline has taken things

[SolarPortal]

heres a post to show the normals difference in ambience, please bear in mind the lighting difference because the skyline PBR only works with IBL for ambience.

[xrgo]

it look really really better, I wonder how that wood material would look in my engine, can you share those maps?

Nice idea with using the noise map instead vertex colours, might have a looky into that..

I am using both, the R channel of the vertex color is used for wind weight, black means no influence (trunk, pinned parts of the flag, etc), and white full influence. The noise 3D texture is what gives the wavy effect, and the shader is basically this:

Code: Select all

	@property( use_wind )
		@property( syntax == glsl )
  		worldPos.xyz += ( texture( texPerlinNoise, 0.2*worldPos.xyz + float3(passBuf.windTime) +
													float3(passBuf.globalTime*0.3) ).xyz - 0.5 ) * colour.x * passBuf.windIntensity;
		@else
  		worldPos.xyz += ( texPerlinNoise.SampleLevel( texPerlinNoiseSampler,
													0.2*worldPos.xyz + float3( passBuf.windTime, passBuf.windTime, passBuf.windTime )+
													float3( passBuf.globalTime*0.3, passBuf.globalTime*0.3, passBuf.globalTime*0.3 ), 0 ).xyz -
													float3( 0.5, 0.5, 0.5 ) ) * input.colour.x * passBuf.windIntensity;
		@end
	@end

passBuf.windTime is a global timer that just increases over time

and here's the texture:
https://www.dropbox.com/s/75crodirnat7i ... e.dds?dl=0

[SolarPortal]

Sure, here is the download:
Substance_Glossyish_wood
You need the mesh since it was exported from substance painter which i've included in the package.

Thanks for sharing that too
For ours, we were basing it on what crytek did: https://developer.nvidia.com/gpugems/GP ... _ch16.html and this: https://mtnphil.wordpress.com/2011/10/1 ... egetation/ using vertex colours as weights for movement. Im still working on the wind now, but i have the basis of the code working and seeing promising results.

[SolarPortal]

also thought id post a screenshot from it inside substance, not the same direction or environment, but ours looks very similar with just loading the textures and not tweaking a single value from 1.0 or 0.0 for metallic slider

Clipboard Image.jpg

[xrgo]

indeed looks better with your engine
this is in my engine:

and I noticed that the roughness was too white, in fact one of my customizations for the default pbs is that I found that everything looked too shiny compared to ue4 for example, so I redefine the piece envSpecularRoughness like this (I found that formula somewhere, it supposed to mimic ue4):

Code: Select all

@undefpiece( envSpecularRoughness )
@piece( envSpecularRoughness ) @value(num_probes_mipmaps) + log2(pixelData.roughness) @end

instead of the default:

Code: Select all

@piece( envSpecularRoughness ) pixelData.roughness * 12.0 @end

adjusting the roughness a bit looks like this:


still yours look way better.
A big difference is that I cant load a cubemap by file easily so I just use the default per pixel probes, so the cubemap is a capture of the scene. plus I am doing tonemapping

I would love to make Ogre look closer to ue4, if you can share more details, maybe we can make Ogre look better by default for everyone!

Not to sure why ogre went with view space over world space

because of precision, world space stuff tend to produce artifacts when you go far away from the origin (>10km)

For ours, we were basing it on what crytek did: https://developer.nvidia.com/gpugems/GP ... _ch16.html and this: https://mtnphil.wordpress.com/2011/10/1 ... egetation/ using vertex colours as weights for movement. Im still working on the wind now, but i have the basis of the code working and seeing promising results.

well that's a more advance solution, obviously is going to look better, keep it up!

[SolarPortal]

and I noticed that the roughness was too white, in fact one of my customizations for the default pbs is that I found that everything looked too shiny compared to ue4 for example

This is exactly what set us off too and this mesh and material is what made us start to make the changes. At first i did try the fix you made to the roughness calculation and that seemed to adjust how quickly it started to blur which looked better but still didn't give the look we were after.

We decided to duplicate the PBR and strip implementation down to bearbones removing most of the features and base code leaving only the main stuff The pixel shader was changed the most with a few changes to the vertex shader.

There is a few difference between our codes:
* We output the worldspace normal, tangent, position from the vertex shader.
* The TBN is made from these world space
* We dont have a reflection texture for the material slot, it is sent through seperately as irradiance, specularReflection, specularBRDFLookup.
* Your going to need the eyepos: float3 eyepos = normalize(passBuf.cameraPosWS.xyz - inPs.worldPos); Just giving this as it had me stumped for a few days. You might not need it, in which case no problem

The ambience is where you should work as this is where the problem lies most notably around the fact of no normals if there is no specular IBl part.
I understand the reason for adding a fixed and hemispherical ambience but for PBR they just dont work well enough, as a reflection whether blurred using spherical harmonics or not is what controls the fresnel sheen colours, no bright spots=no sheen Rather than the sheen all around the surface.

I would love to make Ogre look closer to ue4, if you can share more details, maybe we can make Ogre look better by default for everyone!

I would love to give more, but since this is the new render for the next big version of our engine, i cant share too much, but maybes once we have released and completed the work, we could possibly release the PBR changes we use and then they could be made to ogre. Not sure, but ill keep it in the back of my mind.

plus I am doing tonemapping

all shots taken are without any post effects. Tonemapping for us will come after we are finished on the shader to give it that bit more of a pop if needed.

because of precision, world space stuff tend to produce artifacts when you go far away from the origin (>10km)

Even on the standard shader my vertices start to jump a bit at 1000m+, then at 10k they are quite stuttery, Moving the scene origin should help though.

[xrgo]

Thank you! I'll look in to this when I have the time, now that I know that it can be improved I will not sleep fine until its fixed lol
I understand you can't share more, don't worry, thanks for all the info

Even on the standard shader my vertices start to jump a bit at 1000m+

strange I have a scene with a radius of 3500 and I have no problem (haven't really tested more than that), I had zfighting but it was fixed with the reverse-z implementation

Saludos!!

[SolarPortal]

cool, i hope it helps

[dark_sylinc]

Very nice-looking thread!

Improvements are always welcome! Specially if they make us closer to other tools to avoid the heterogeneity; thus a smoother pipeline when importing assets from tool -> engine.

We don't process our cubemaps through GGX NDF because we never had time to delve into it. Contributions are welcome!

following the traditional shader of doing things world space over view space which gets more accurate results when taking PBR assets from other tools and engines. e.g. substance, 3d coat, etc..

With the exception of floating point accuracy, there's no quality difference between doing things in world and view space. In fact view space tends to be more accurate with a few exceptions due to stability when rotating the camera.

But it is very easy to mess up though e.g. if you're looking into another implementation, then it's possible some assumption about the space was overlooked (e.g. view space can assume the camera is at 0 0 0) or some parameter is in the wrong space.

Not to sure why ogre went with view space over world space.

As xrgo explained, it's because of precision, which gets really bad for larger scenes.

In retrospective, it was a bad choice; and we should've gone with world space + relative origins (which I tried to avoid because it has its own set of problems).

It was a bad choice not because of the reasons you're encountering, but because view space is "infectous" (everything needs to be transformed, even parameters that could otherwise be considered static now need to be aware of the camera, even if they only contain direction and no position*) and because it's not the best fit for VR (in VR, you don't have one view space, but rather two)

*With relative origins, position needs to be aware of the relative origin.

[TaaTT4]

We removed the reflection map and ambient lighting system and generated a so called Skylight which fills this all for us which only provides IBL based ambience, we render a cubemap of the world, mainly skybox/skydome or HDRi images with mip maps and then process this using a GGX NDF importance sampling technique in compute shader per mip map. This is known as the specular reflection texture which is then used in the reflection part of the shader...

For what I've understood, this is the real difference (in terms of lighting) between Solar and OGRE implementations of PBR. Solar uses his compute shader to "post-process" the cubemap while OGRE uses it as-is (no matter what if it comes from an external texture or a probe).

... then we rendered an irradiance texture which is a small 32x32 cubemap with no mips for the diffuse IBL and ran a separate compute shader that computes Diffuse Irradiance for plans of a light probe based system later. However as @dark_sylinc said in another of your topics, using one of the higher mip maps of the prefiltered specular reflection can be used as the diffuse IBL, just don't do the reflection part of the calculation and use the geometry normal, normal texture multiplied by a TBN made up from world space normals, tangents and binormals.

This is another difference. Solar follows what Filament does (two different cubemaps, one for diffuse IBL and one for specular IBL) while OGRE uses the cubemap for everything (considering the low-resolution mip as a diffuse IBL).

Solar, could you modify you shader mimic what OGRE does (use the low-resolution mip as a diffuse IBL) and then upload a comparative screenshot? I hope I'm not asking too much, but I'm interested in figure it out what contributes more in the visual improvement you obtained: if the application of GGX NDF over the cubemap or the separate diffuse IBL.

[xrgo]

well this thread took a turn from the original title but its really interesting =)
One thing I noticed is that the specular blob by default is very dim, so I tried fimlament implementation of the BRDF https://google.github.io/filament/Filam ... delsummary
and its looking really nice already, normals pop up very nicely:



compared to the one posted before

and I didn't adjust roughness nor anything else

but this only improves the behaviour with lights, nothing to do with the cubemaps yet, so in shadows it looks exactly as flat as always

this is the adapted shader (you can put it on a custom template and it will redefine the piece)
I hope I ported it well, I hope more people can test it

Code: Select all

@undefpiece( DeclareBRDF )
@piece( DeclareBRDF )

#define PI 3.14159265359

float D_GGX(float NoH, float a) {
    float a2 = a * a;
    float f = (NoH * a2 - NoH) * NoH + 1.0;
    return a2 / (PI * f * f);
}

float3 F_Schlick(float VoH, float3 f0) {
    return f0 + (float3(1.0,1.0,1.0) - f0) * pow(1.0 - VoH, 5.0);
}

float V_SmithGGXCorrelated(float NoV, float NoL, float a) {
    float a2 = a * a;
    float GGXL = NoV * sqrt((-NoL * a2 + NoL) * NoL + a2);
    float GGXV = NoL * sqrt((-NoV * a2 + NoV) * NoV + a2);
    return 0.5 / (GGXV + GGXL);
}

//Default BRDF
INLINE float3 BRDF( float3 lightDir, float3 lightDiffuse, float3 lightSpecular, PixelData pixelData )
{
	    float3 halfWay = normalize( lightDir + pixelData.viewDir );

	    float NoV = abs( dot( pixelData.normal, pixelData.viewDir ) ) + 1e-5;
	    float NoL = saturate( dot( pixelData.normal, lightDir ) );
	    float NoH = saturate( dot( pixelData.normal, halfWay ) );
	    float LoH = saturate( dot( lightDir, halfWay ) );

	    // perceptually linear roughness to roughness (see parameterization)
	    float roughness = pixelData.roughness * pixelData.roughness;

	    float D = D_GGX(NoH, roughness);
	    float3  F = F_Schlick(LoH, pixelData.F0);
	    float V = V_SmithGGXCorrelated(NoV, NoL, roughness);

	    // specular BRDF
	    float3 Fr = (D * V) * F;

	    // diffuse BRDF (already divided by PI)
	    float3 Fd = pixelData.diffuse;

	    // apply lighting...
	    return lightDiffuse * NoL * ( Fd + Fr );
}
@end

[xrgo]

another comparison
just changed the brdf piece


what I need to do now is make a similar scene on ue4 and/or blender eevee to see if this change fit those standards
substance (as I was told) don't have lights so I can't compare with that

[TaaTT4]

another comparison
just changed the brdf piece

In left image you're using OGRE vanilla ("default" BRDF, right?) while in right image you're using the BRDF taken from Filament, correct? Visually speaking, the right image seems more vivid and less flat. From a physics point of view, I don't know if the Filament BRDF can be graft in OGRE without any further changes (in theory yes, but is better to wait the opinion of THE expert ). If so, you could submit a PR and make it choosable as an alternative to default BRDF implementation.

[xrgo]

exactly, left default, right filament
I hope for: that my further investigation (comparison with other engines) visually validates this approach (gonna take some time, maybe others can help), and that Matias wont see anything strange, then make the Ogre's default the one that fits better ue4/eevee so users benefit right out of the box (that I am guessing is the filament one)

[xrgo]

I made a comparison with blender eevee, I tried to mimic camera position and exposure, cubemap was exported from my engine, looks a bit bluish maybe because of the different tonemapper

eevee


filament brdf


ogre default brdf


the specular highlights/blobs looks very very similar eevee/filament, definitely looks flat with ogre's default.
I am going to try unreal next

[al2950]

This is indeed a very interesting thread. I have had similar issues, with getting artist textures to look right in Ogre, but better looking stuff is not a priority for me sadly. Although I love how easy it is to drop in a different BRDF into the HLMS .

[frostbyte2]

doh, i'm just a simple ogre user and i have no clue about brdf's and friends, but i remember i saw some related tweet on https://twitter.com/tuan_kuranes linking to this stuff... http://jcgt.org/published/0008/04/01/
from what i understand they developed some kind of method/software to map/fit between brdf's without access to the actual implementation
just figured it might be helpful somehow with adjusting ogre's results to blender...

[TaaTT4]

Hey @SolarPortal, anything about this?

Solar, could you modify you shader mimic what OGRE does (use the low-resolution mip as a diffuse IBL) and then upload a comparative screenshot? I hope I'm not asking too much, but I'm interested in figure it out what contributes more in the visual improvement you obtained: if the application of GGX NDF over the cubemap or the separate diffuse IBL.

And what about you @xrgo, any news?

I hope for: that my further investigation (comparison with other engines) visually validates this approach (gonna take some time, maybe others can help), and that Matias wont see anything strange, then make the Ogre's default the one that fits better ue4/eevee so users benefit right out of the box (that I am guessing is the filament one)

[xrgo]

I tried that same model in unreal and for some reason looked really glitched so I didn't posted it, then I haven't had more time, I just move to another home so maybe next week. But I can say that I've been using this brdf by default in my apps the last days and I can notice everything looks nicer . I just want to confirm with unreal with another model or fix the exporting so it won't look glitched

[SolarPortal]

Hey, sorry i just haven't had time yet. i'm a 24 hr carer and trying to develop our engine at the same time which we are trying to get the next version ready

[TaaTT4]

I tried that same model in unreal and for some reason looked really glitched so I didn't posted it, then I haven't had more time, I just move to another home so maybe next week. But I can say that I've been using this brdf by default in my apps the last days and I can notice everything looks nicer . I just want to confirm with unreal with another model or fix the exporting so it won't look glitched

Hey, sorry i just haven't had time yet. i'm a 24 hr carer and trying to develop our engine at the same time which we are trying to get the next version ready

Don't worry, just keep me updated
Artists here have seen your screenshots and, since we use Substance too, are a bit over-excited.

[xrgo]

I made a comparison with blender eevee, I tried to mimic camera position and exposure, cubemap was exported from my engine, looks a bit bluish maybe because of the different tonemapper

eevee


filament brdf


ogre default brdf


the specular highlights/blobs looks very very similar eevee/filament, definitely looks flat with ogre's default.
I am going to try unreal next

I kind of make it work in unreal, geometry still broken but at least textures look good



and I don't know how to use it, so it was hard to match everything for a fair comparison, at least I could load the same cubemap and set the light angle, and as you can see the specular highlights are also very bright, so I am now convinced that the default brdf is faulty, I can make a PR to add the option but tbh I would like this to replace the default one (and maybe move the default to a separate option in case someone still needs it), so I am going to wait if dark_sylinc has something to say about it =)

now the next step is to process the cubemaps like SolarPortal did but it seems a bit over my skills