My strange global illumination solution.

Global illumination is spationaly/directinaly low frequency signal.
Lightmap is sptaionaly high frequency but cannot store high frequency directional data due to memory issue.
Specular IBL is also important part of Global illumination. most game engine uses pre-filtered cubemap for specular GI. This has high frequency directional data, but spatial frequency is very low(1 ~ 300 cubemap in the level in UE4).

So I thought that if specular IBL is low spatial freqency data, what if we use high frequency diffuse GI and forgive high frequency spatial diffuse GI?

Below are result of that thought. There is only 1 probe which can be updated in realtime(no lightmap) and hbao+.


Diffuse indirect lighting might be incorrect spatially. but matches with specular IBL.
and with very low memory(no lightmap) and can be easily interpolated(time of day).

probe can be interpolated using volume texture(3d clipmap in large world), or blended in tiled culling using compute shader. I tried both and chose tiled culling with CS.

Fourier Opacity Map volumetric shadow.

I implemented volumetric shadow of particle system in UE3.
There were several options for this effect. The most feasible 3 were like below.

1. per pixel deep shadow map(need CS, UE3 didnt have CS back then)
2. FOM
3. Simple thickness map

I tried #2 first. the result was quite good with some resource. But finally I chose simple thickness map technique because of the severe ringing effect of some particles with high opacity! ringing effect is seen in spherical harmonics too. because frouier and SH use wave like basis functions.

Today, I found that UE4 is using FOM for volumetric self shadow. and document is warning about ringing effect.

why did they choose FOM? maybe they must have found solution for ringing effect.
I will look into source code later.

Incorrect naming in UE4 skylight source code.

Recently, I am reading UE4 skylight code. and found that they call projected SH coefficients as "IrradianceEnvironmentMap".

Actually, this naming is wrong.
They make this Irradiance SH Function by producting cosine lobe in the end. But until then it is projected "Radiance SH" not "Irradiance SH".

Let's recall basic rendering process using spherical harmonics.

1. Project SH coefficients from radiance cube map.
2. Convert Radiance SH to Irradiance SH by dot product with cosine lobe
(Ravi Ramamoorthi's paper)
3. Evaluate Irradiance env map with normal vector

Let's see two different shader code for SH shading.

Below code is hlsl from MJP in gamedev.net
This is easy to understand.
There is radiance SH, cosine lobe.

static const float Pi = 3.141592654f; static const float CosineA0 = Pi; static const float CosineA1 = (2.0f * Pi) / 3.0f; static const float CosineA2 = Pi * 0.25f; struct SH9 { float c[9]; }; struct SH9Color { float3 c[9]; }; SH9 SHCosineLobe(in float3 dir) { SH9 sh; // Band 0 sh.c[0] = 0.282095f * CosineA0; // Band 1 sh.c[1] = 0.488603f * dir.y * CosineA1; sh.c[2] = 0.488603f * dir.z * CosineA1; sh.c[3] = 0.488603f * dir.x * CosineA1; // Band 2 sh.c[4] = 1.092548f * dir.x * dir.y * CosineA2; sh.c[5] = 1.092548f * dir.y * dir.z * CosineA2; sh.c[6] = 0.315392f * (3.0f * dir.z * dir.z - 1.0f) * CosineA2; sh.c[7] = 1.092548f * dir.x * dir.z * CosineA2; sh.c[8] = 0.546274f * (dir.x * dir.x - dir.y * dir.y) * CosineA2; return sh; } float3 ComputeSHIrradiance(in float3 normal, in SH9Color radiance) { // Compute the cosine lobe in SH, oriented about the normal direction SH9 shCosine = SHCosineLobe(normal); // Compute the SH dot product to get irradiance float3 irradiance = 0.0f; for(uint i = 0; i < 9; ++i) irradiance += radiance.c[i] * shCosine.c[i]; return irradiance; } float3 ComputeSHDiffuse(in float3 normal, in SH9Color radiance, in float3 diffuseAlbedo) { // Diffuse BRDF is albedo / Pi return ComputeSHIrradiance(normal, radiance) * diffuseAlbedo * (1.0f / Pi); }

And below is code from Peter-Pike Sloan
This code seems to be just a sh evaluation code.
The secret is coefficient for cosine lobe is already producted to radiance SH(and it becomes Irradiance finally!)
// constants containing irradiance environmne map float4 cAr; float4 cAg; float4 cAb; float4 cBr; float4 cBg; float4 cBb; float4 cC; float3 ShadeIrad(float4 vNormal) { float3 x1, x2, x3; // Linear + constant polynomial terms x1.r = dot(cAr,vNormal); x1.g = dot(cAg,vNormal); x1.b = dot(cAb,vNormal); // 4 of the quadratic polynomials float4 vB = vNormal.xyzz * vNormal.yzzx; x2.r = dot(cBr,vB); x2.g = dot(cBg,vB); x2.b = dot(cBb,vB); // Final quadratic polynomial float vC = vNormal.x*vNormal.x - vNormal.y*vNormal.y; x3 = cC.rgb * vC; return x1+x2+x3; }

Later code may be a lot faster(because use fewer shader instructions).

UE4 call value after 1 as IrradianceEnvironmentMap(it becomes irradiance in the end, but not at first).

Although final rendering is OK, But Incorrect naming confuse stupid reader like me.

UE4 Rendering thread problem related to Editor

UE4 has multi-thread rendering architecture which is similar to UE3(almost same..).
Game thread datas(PrimitiveComponent..) and Rendering thread datas(SceneProxy..) are main components of it.

Game thread enqueue asynchronous rendering command continously to rendering thread. Applying changed property in game thread to rendering thread is one of them.

Usually there is no bad thing here. Until Editor and UpdateRendertargetCapture are used together.

case :
1. Component property is changed by editor click.(from Window Msg Pump)
2. There is 2dSceneCaptureActor in the scene.
3. GarbageCollection is performed.

problem :
1. some object could be garbage collected.
2. Scene could be rendered before change of property is applied to render thread.
3. Garbaged collected object could be referenced in rendering thread.

I resolved this sitation by FlushRenderingCommand. But still, We could say this is flaw of UE4 multi-threading or update capture architecture.

Improving outline postprocess using stencil operation.

There is excellent tutorial for Outline postprocess.

http://www.tomlooman.com/ue4-outline-post-process/

His technique support pretty outline using custom depth(simliar technique is already being used by editor selected object), and also provide nice multi color feature too.

But what if your game designer want to specify occluders who cause occludee outlined?

Here is my solution.

1. occludee writes team color ID to stencil.
2. occluder increment stencil by 1(to do this, we need to slightly modify custom depth path, PrimitiveComponent has occluder/occludee flag and it is rendered seperately in custom depth path)
3. In PostProcess, only increment stencil pixel is considered as "outlined"

This is very useful when there are too much outline in screen, and we want to use only needed.

Got full time graphics programmer job.

Recently, I came back to game industry. and am now full time graphics programmer.

People might say that why would we need graphics programmer if we use engine like UE4. but even UE4 doesn't have all the features we want. so there are tons of things to be touched by graphics programmer.

Fortunately, UE4 is a lot easier than UE4 to modify or extend.

Here is what I am doing now.

1. understand inside of renderer, and guide artist team to use engine correctly(ex: PBR input)

2. adding missing features(ex : lighting channel in UE3 or Hair rendering and etc..)

3. make tools for faster artistic iteration and faster tweak.

I am thinking if there are more things to be done. and these are very interesing so far.

I will post some tips later.