PBR and Graphics Improvements implementation

Everything about development and the OpenMW source code.
User avatar
DestinedToDie
Posts: 1181
Joined: 29 Jun 2015, 09:08

Re: PBR and Graphics Improvements implementation

Post by DestinedToDie »

sjek wrote:as a fan non coder, they aren't yet implemented is osg possibly from perfomance reasons
I remember Scrawl talking about not feeling like implementing shadows a second time. I guess he got burnt out in that area and everyone was fine with setting priority to other features.
User avatar
sjek
Posts: 442
Joined: 22 Nov 2014, 10:51

Re: PBR and Graphics Improvements implementation

Post by sjek »

possibly so
User avatar
Methelina
Posts: 34
Joined: 22 Aug 2016, 09:21
Contact:

Re: PBR and Graphics Improvements implementation

Post by Methelina »

Thx guys for some explanation. We found the issue what was between shadows and us XD And we working on the first shadow-prototype
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: PBR and Graphics Improvements implementation

Post by AnyOldName3 »

Will your shadow implementation be for the legacy rendering system too, or just the fancy PBR one?
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: PBR and Graphics Improvements implementation

Post by psi29a »

AnyOldName3 wrote:Will your shadow implementation be for the legacy rendering system too, or just the fancy PBR one?
Huh? There is only one rendering system. PBR is just shader "magic", the rendering system (OSG) supports this.

Correct me if I'm wrong.
User avatar
Methelina
Posts: 34
Joined: 22 Aug 2016, 09:21
Contact:

Re: PBR and Graphics Improvements implementation

Post by Methelina »

Shadows and PBR are different entities of the engine. PBR is a method to render a mesh surface, Shadows is an entity of the lighting XD
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: PBR and Graphics Improvements implementation

Post by AnyOldName3 »

There's PBR shading (e.g. Cook-Torrance, Oren-Nayar) of PBR materials (e.g. using measured values or a metalness workflow) lit by PBR lighting (e.g. multiple importance sampling of an environment map instead of relying on adding a constant ambient colour and other fancy stuff). If shadows were somehow part of the PBR lighting, then they might not be available when it wasn't used. I wouldn't know if that was the case, as I've only ever written raytracers, so have no idea where shadows come into polygon scan conversion based rendering. :P
User avatar
Methelina
Posts: 34
Joined: 22 Aug 2016, 09:21
Contact:

Re: PBR and Graphics Improvements implementation

Post by Methelina »

If you want to go deep into this stuff in the engine, shadows and pbr stuff are calculating separately

for example my old-old work. A simple example of Disney GGX (Generalized Trowbridge-Reitz) PBR model, AO and shadows just made by their own passes and than applied in calculations

Code: Select all

#define USE_DISNEYS_DIFFUSE 			//to see the difference
#define PI 3.14159265
#define USE_TOKSVIG 				

float hornerD(in float f, in float x) 	//Horner distribution for the Fresnel
{
return 1. + (f - 1.) * exp2((-5.55473 * x - 6.98316) * x);
}

float SpecPowerToRoughness(in float s1) {
        	return sqrt(2.0 / (s1 + 2.0));
   	 }

vec3 shade(in vec3 n, in vec3 v, in vec3 l, in vec3 lcol, in vec3 alb)
{
	//material data (could be passed in)
	const float rough = 0.45;
	const vec3 F0 = vec3(.4);
	const float kr = .4; //diff/spec ratio

    float dotNL = saturate(dot(N,L));
    float dotNV = saturate(dot(N,V));
    float dotNH = saturate(dot(N,H));
    float dotLH = saturate(dot(L,H));

	vec3 col = vec3(0.);
	float ao = 0.0; //Ambient occlusion pass can be made manually, or texture2d or a postFX term in deferred later
	
if ( dotNL  > 0. && dotNV > 0.)
	{
    	float dotVH = saturate(dot(V,H));   	 

 //---------------- Toksvig Factor Applied------------------- No specular aliasing
  	 
    	#ifdef USE_TOKSVIG   	 
   			 float rough = (2.0 / (rough * rough) - 2.0);
   			 float normalMapLen = length(N);
   			 float s = rough;
            	float ft = normalMapLen / mix(s, 1.0, normalMapLen);
            	ft = max(ft, 0.01);
            	rough = SpecPowerToRoughness(ft * s);
  	 
   	 #endif
        	
#ifdef USE_DISNEYS_DIFFUSE
    	float fd90 = 0.5+ 2.*dotVH*dotVH*rough;
    	vec3 dif =  dotNL *alb*hornerD(fd90,  dotNL )*hornerD(fd90, dotNV); //thats the place where the color transforms via roughness and dot-products of surface info 
    	
#else
    	vec3 dif = alb* dotNL ;
    	
#endif
   	 
    	float a = rough*rough;
    	float a2 = a*a;
    	float dn = dotNH*dotNH*(a2 - 1.) + 1.;
    	float D = a2/(PI*dn*dn);
   	 
    	float k = pow( rough*0.5 + 0.5, 2.0 )*0.5;
    	float nvc = max(dotNV,0.);
    	float gv = nvc/(nvc*(1.-k) + k);
    	float gl =  dotNL /( dotNL *(1.-k) + k);
    	float G = gv*gl;

    	vec3 F = F0 + (1. - F0) * exp2((-5.55473 * dotVH - 6.98316) * vh); //Horner term applied to the Fresnel 	 
   	 
  		 vec3 spe = D*F*G/(4.* dotNL *dotNV);
   	 col = mix(spe,dif,kr);
    	
#if 0 //clearcoat method from DPaper, need the double IBL samples
    	n = normalize(n - normalize(pos) * 0.5);    
    	col += vec3(specular(n,l,rd,50.0))*0.2;
    	
#endif
    	col *= shadow; //we apply the shadow here, abstract a little here  :)  Where the shadows calculated somewhere in other place  :) 
    	col *= lcol;
	}
	
else //complete hack
	{
    	col = alb*exp2(rough)*0.02*ao*(.5+ao);
	}
       col += 0.2*alb*ao;
return col; //col;
}


vec3 tone(vec3 color, float gamma) //Reinhard based tone mapping
{
    float white = 2.; 
    float luma = dot(color, vec3(0.2126, 0.7152, 0.0722));
    float toneMappedLuma = luma * (1. + luma / (white*white)) / (1. + luma);
    color *= toneMappedLuma / luma;
    color = pow(color, vec3(1. / gamma));
    return color;
}

col = tone(col,0.9)*1.4;
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: PBR and Graphics Improvements implementation

Post by psi29a »

Awesome, yeah... I think it is the terminology and how I was thinking about things that got me confused.

Apparently OpenMW uses OSG to render things, but OpenMW has a "lighting.glsl" which is being used to handle how the scene looks which is as Methelina says:
no its a lighting part of engine that renders a specular of the scene
from normals, view vector, light-pass
As for 'shadows":
no shadows are separated system
shadows are generated as projection for light sources and in openMW no code about shadows.
it has on the sources of OSG, but OSG used for OpenMW have no shadows code too
So there we go...
User avatar
Methelina
Posts: 34
Joined: 22 Aug 2016, 09:21
Contact:

Re: PBR and Graphics Improvements implementation

Post by Methelina »

The next step is:
addin shadows node to the OSG build and adding connector in the openMW, when will be some results i will show it here XD
Post Reply