HLMS PBR BRDF

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

HLMS PBR BRDF

Post by SolarPortal » Mon Dec 02, 2019 9:13 pm

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.
1 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Tue Dec 03, 2019 3:36 am

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 :D , 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):
Image

Cheers! and great work!
viva Ogre!
1 x

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Tue Dec 03, 2019 12:54 pm

hey xrgo,
I am sorry if I sound like "you've wasted time", its not my intention :D , 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 :P

But still, very impressive xrgo :) It's cool to see how the original adopters of the 2.x pipeline has taken things :)
0 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Tue Dec 03, 2019 1:24 pm

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.
Attachments
Skyline_Ogre_Difference.jpg
0 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Tue Dec 03, 2019 4:15 pm

it look really really better, I wonder how that wood material would look in my engine, can you share those maps?
SolarPortal wrote:
Tue Dec 03, 2019 12:54 pm
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
0 x

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Tue Dec 03, 2019 6:41 pm

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.
0 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Tue Dec 03, 2019 8:50 pm

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 :P
Clipboard Image.jpg
0 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Tue Dec 03, 2019 8:55 pm

indeed looks better with your engine
this is in my engine:
Image
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:
Image

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 :P

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!
SolarPortal wrote:
Tue Dec 03, 2019 12:54 pm
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)
SolarPortal wrote:
Tue Dec 03, 2019 6:41 pm
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!
0 x

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Tue Dec 03, 2019 9:49 pm

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 :P

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 :P
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.
:D
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.
1 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Tue Dec 03, 2019 11:40 pm

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 :D
SolarPortal wrote:
Tue Dec 03, 2019 9:49 pm
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!!
0 x

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 141
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 8
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by SolarPortal » Wed Dec 04, 2019 12:21 am

cool, i hope it helps 8)
0 x
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4147
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 268
Contact:

Re: Compute Shaders and cubemaps [SOLVED]

Post by dark_sylinc » Wed Dec 04, 2019 4:59 am

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.
0 x

User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 181
Joined: Wed Apr 23, 2014 3:49 pm
x 20

Re: Compute Shaders and cubemaps [SOLVED]

Post by TaaTT4 » Wed Dec 04, 2019 11:04 am

SolarPortal wrote:
Mon Dec 02, 2019 9:13 pm
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).
SolarPortal wrote:
Mon Dec 02, 2019 9:13 pm
... 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.
0 x
Senior game programmer at Vae Victis
Working on Racecraft

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Wed Dec 04, 2019 4:15 pm

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:

Image

compared to the one posted before
xrgo wrote:
Tue Dec 03, 2019 8:55 pm
Image
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
1 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Wed Dec 04, 2019 4:44 pm

another comparison
just changed the brdf piece
Image

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
1 x

User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 181
Joined: Wed Apr 23, 2014 3:49 pm
x 20

Re: Compute Shaders and cubemaps [SOLVED]

Post by TaaTT4 » Wed Dec 04, 2019 5:14 pm

xrgo wrote:
Wed Dec 04, 2019 4:44 pm
another comparison
just changed the brdf piece
Image
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 :D). If so, you could submit a PR and make it choosable as an alternative to default BRDF implementation.
0 x
Senior game programmer at Vae Victis
Working on Racecraft

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Wed Dec 04, 2019 5:27 pm

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)
2 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1075
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 92

Re: Compute Shaders and cubemaps [SOLVED]

Post by xrgo » Wed Dec 04, 2019 7:38 pm

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
Image

filament brdf
Image

ogre default brdf
Image

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

al2950
OGRE Expert User
OGRE Expert User
Posts: 1212
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 80

Re: Compute Shaders and cubemaps [SOLVED]

Post by al2950 » Thu Dec 05, 2019 11:49 am

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 :D.
0 x

frostbyte2
Gnoblar
Posts: 8
Joined: Mon Jun 03, 2019 2:45 pm
x 8

Re: HLMS PBR BRDF

Post by frostbyte2 » Thu Dec 05, 2019 5:27 pm

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...
0 x

Post Reply