Romanticism in science

Now the cube depth map has been generated, we can use this texture as shadow depth map.

To calculate pixel depth in deferred shader, the longest axis of pixel to light position is used as linear depth. But cubemap depth is logarithmic, and we need both to be the same format for comparison. In my shader, I converted depth from cubemap to linear one.

Now, apply this depth comparison to attenuation and everything’s done.

Comparing to render to texture 2d, creating a cubemap as render target is similar with minor difference.

A texture 2d desc will be used for texture creation. When creating a cubemap, ArraySize must be 6 and MiscFlags should be D3D11_RESOURCE_MISC_TEXTURECUBE.

D3D11_TEXTURE2D_DESC cubeTexDesc; cubeTexDesc.Width = 256; cubeTexDesc.Height = 256; cubeTexDesc.MipLevels = 1; cubeTexDesc.ArraySize = 6; cubeTexDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; cubeTexDesc.SampleDesc.Count = 1; cubeTexDesc.SampleDesc.Quality = 0; cubeTexDesc.Usage = D3D11_USAGE_DEFAULT; cubeTexDesc.BindFlags = D3D11_BIND_RENDER_TARGET | D3D11_BIND_SHADER_RESOURCE; cubeTexDesc.CPUAccessFlags = 0; cubeTexDesc.MiscFlags = D3D11_RESOURCE_MISC_TEXTURECUBE;

RRenderer.D3DDevice()->CreateTexture2D(&cubeTexDesc, 0, &cdb.Buffer);

We need six render target views, each of them need a D3D11_RTV_DIMENSION_TEXTURE2DARRAY as ViewDimension. To create render target view for each side, Texture2DArray.FirstArraySlice should be set to the face id.

D3D11_RENDER_TARGET_VIEW_DESC cubeRTVDesc; cubeRTVDesc.Format = cubeTexDesc.Format; cubeRTVDesc.ViewDimension = D3D11_RTV_DIMENSION_TEXTURE2DARRAY; cubeRTVDesc.Texture2DArray.ArraySize = 1; cubeRTVDesc.Texture2DArray.MipSlice = 0; for (int i = 0; i < 6; i++) {     cubeRTVDesc.Texture2DArray.FirstArraySlice = i;     RRenderer.D3DDevice()->CreateRenderTargetView(cdb.Buffer, &cubeRTVDesc, &cdb.View[i]); }

Then we create a shader resource view with ViewDimention set to D3D11_SRV_DIMENSION_TEXTURECUBE

D3D11_SHADER_RESOURCE_VIEW_DESC cubeSRVDesc; cubeSRVDesc.Format = cubeRTVDesc.Format; cubeSRVDesc.ViewDimension = D3D11_SRV_DIMENSION_TEXTURECUBE; cubeSRVDesc.TextureCube.MipLevels = 1; cubeSRVDesc.TextureCube.MostDetailedMip = 0; RRenderer.D3DDevice()->CreateShaderResourceView(cdb.Buffer, &cubeSRVDesc, &cdb.SRV);

Similarly, create texture2d, 6 render target views and shader resource view for depth buffer with D3D11_BIND_DEPTH_STENCIL in BindFlags and format as a depth buffer compatible format.

To render to cubemap, set up six cameras at a view point with 90 degree FOV and each camera looks at one axis direction.

I found a useful lua wrapper class for exporting C++ class to lua. Developed by Alexander Ames, here is the link to LuaWrapper:

https://bitbucket.org/alexames/luawrapper/

LuaWrapper provided an easy interface to extend Lua with class and member function supporting. To register a class with LuaWrapper, a table for static functions, a table for member functions and a wrapper new function for the class are required.

CActor* Actor_new(lua_State* L) {     return new CActor(); }

int Actor_GetName(lua_State* L) {     CActor* actor = luaW_check<CActor>(L, 1);     lua_pushstring(L, actor->GetName());     return 1; }

static luaL_Reg Actor_Table[] = {     { nullptr, nullptr } };

static luaL_Reg Actor_Matatable[] = {     { "GetName", Actor_GetName },     { nullptr, nullptr } };

And register class:

void CActor::RegisterLuaBinding(lua_State* L) {     luaW_register<CActor>(L, "Actor", Actor_Table, Actor_Matatable, Actor_new); }

Then in lua script, class actor can be used like:

Here is the image of controlling objects within Lua script.

Some performance-critical functions are better called from C/C++ side. They can be declared in source code and registered to lua.

The way Lua getting parameters from and sending return values back to script is through stack. A simple function to expose to Lua looks like this:

static int average(lua_State *L) {     /* get number of arguments */     int n = lua_gettop(L);     double sum = 0;     int i;

    /* loop through each argument */     for (i = 1; i <= n; i++)     {         /* total the arguments */         sum += lua_tonumber(L, i);     }

    /* push the average */     lua_pushnumber(L, sum / n);

    /* push the sum */     lua_pushnumber(L, sum);

    /* return the number of results */     return 2; }

Before function can be called in Lua, it needs to be register to lua_State.

lua_register(state, "average", average);

Note: registration happens after loading the script, before executing it.

Now we can call this function from Lua like:

i = average(5, 10, 20)

print(i)

and it gives the result:

Lua is a light weighted scripting language which has been widely used in game development. In my project, I use Lua to move objects in my game. By exposing C/C++ function to Lua, complex behaviors can be implemented without having performance issue while being flexible.

To initialize Lua in the project, we create a lua_State and load script from file:

lua_State *state = luaL_newstate();

// Make standard libraries available in the Lua object luaL_openlibs(state);

int result;

// Load the program; this supports both source code and bytecode files. result = luaL_loadfile(state, "myscript.lua”);

if (result != LUA_OK) {     print_error(state);     return; }

// Finally, execute the program by calling into it. // Change the arguments if you're not running vanilla Lua code.

result = lua_pcall(state, 0, LUA_MULTRET, 0);

if (result != LUA_OK) {     print_error(state);     return; }

Those lines of code will load a script from “myscript.lua” and execute function calls in it.

myscript.lua:

print("Hello world") i = 5 + 5 print("5 + 5 =", i)

Outputs will be:

Hello world 5 + 5 = 10

After using the script, we’ll close lua_State to release the memory.

Besides basic types, PropertyGrid also has a good support with collection classes. In my editor, I created a wrapper class with CLI/C++ to expose C++ material as C# property. A collection of wrapper materials can be accessed in PropertyGrid.

property List<ManagedMaterial^>^ Materials

{     List<ManagedMaterial^>^ get(); }

Within the collection, each element’s properties are shown on the right. As long as the accessors and mutators are properly set, this field should come up automatically.

SeBesides my own engine, I have developed an editor with C# and CLI/C++. PropertyGrid is a good control to set and retrieve object properties.

(Editor with PropertyGrid panel on the right)

To bind an object to PropertyGrid, just set SelectedObject on PropertyGrid to your object:

propertyGrid1.SelectedObject = myGameObject;

To have properties shown up on the grid, object class must have accessor for the property. A mutator is optional when property is read-only to user.

PropertyGrid is very flexible with basic data types and string. For a structural data such as vector3, a good idea is to convert data to string for display/modification, and store to vector3 from string value. Let’s take property position as an example:

property String^ Position {     String^ get()     {         return Vec3ToString(m_SceneObject->GetPosition());     }

    void set(String^ value)     {         m_SceneObject->SetPosition(StringToVec3(value));     } };

Both accessor and mutator are used to make change to the property in PropertyGrid.

Here are the convertor functions between Vector3 and String:

String^ ManagedSceneObject::Vec3ToString(const RVec3& vec) {     return String::Format(L"{0}, {1}, {2}", vec.x, vec.y, vec.z); }

RVec3 ManagedSceneObject::StringToVec3(String^ str) {     String^ delimStr = ",";     array<Char>^ delimiter = delimStr->ToCharArray();     array<String^>^ words = str->Split(delimiter);

    RVec3 vec;     vec.x = (float)Convert::ToDouble(words[0]);     vec.y = (float)Convert::ToDouble(words[1]);     vec.z = (float)Convert::ToDouble(words[2]);

    return vec; }

When using Graphic Analyser to debug DirectX 11 program, some objects are displayed as obj:#. There is a simple way to add name to the objects.

When creating a buffer, shader, render state or any other resources with d3d device, call function SetPrivateData on the object to specify a name that will be shown up in Grahpic Analyser.

ID3D11DeviceChild::SetPrivateData

example:

char debugResName[] = “Backbuffer Texture”;

texture->SetPrivateData(WKPDID_D3DDebugObjectName, strlen( debugResName), debugResName);

The purpose to design a serializer class is to ensure data can be saved to and read from binary files in the exact same way.

With fstream, a file can be opened in either read mode or write mode. Once the file is opened, all operations will depend on the mode user chose.

The first function is to ensure file header. The function will write a given header string into file, or read header from file and check if it matches the one provided by user.

bool EnsureHeader(const char* header, UINT size) {     if (m_Mode == SM_Write)     {         m_FileStream.write(header, size);     }     else     {         assert(!m_FileStream.eof());         char* pBuf = new char[size];         m_FileStream.read(pBuf, size);

        for (UINT i = 0; i < size; i++)         {             if (pBuf[i] != header[i])             {                 delete[] pBuf;                 return false;             }         }

        delete[] pBuf;     }

    return true; }

Then, I made a template function to write to and read from file.

template<typename T> void SerializeData(T& data) {     if (m_Mode == SM_Write)     {         m_FileStream.write((char*)&data, sizeof(T));     }     else     {         assert(!m_FileStream.eof());         m_FileStream.read((char*)&data, sizeof(T));     } }

The template function can take a simple type of data as parameter and save to or read from a binary file. However, it’s not good enough for container classes such as std::string. So I have a specialization template function with std::string.

template<> void SerializeData<string>(string& str) {     if (m_Mode == SM_Write)     {         UINT size = (UINT)str.size();         m_FileStream.write((char*)&size, sizeof(size));         if (size)             m_FileStream.write((char*)str.data(), size);     }     else     {         assert(!m_FileStream.eof());         UINT size;         m_FileStream.read((char*)&size, sizeof(size));         str.resize(size);         if (size)             m_FileStream.read((char*)str.data(), size);     } }

With the same idea, I added vector and array serialization. Just to make sure read and write behave in the same way.

Here is a sample of how to use my serializer:

void RMesh::Serialize(RSerializer& serializer) {     if (!serializer.EnsureHeader("RMSH", 4))         return;

    serializer.SerializeVector(m_MeshElements, &RSerializer::SerializeObject);     serializer.SerializeVector(m_Materials, &RSerializer::SerializeObject);     serializer.SerializeObjectPtr(&m_Animation);     serializer.SerializeVector(m_BoneInitInvMatrices);     serializer.SerializeVector(m_BoneIdToName, &RSerializer::SerializeData);

}

And finally to call serialize on mesh class.

RSerializer serializer;

serializer.Open(”mesh.data”, SM_Write);

mesh.Serialize(serializer);

There is a big change when screen space ray tracing can’t hit any visible pixel on the screen buffer (especially when you look straight at the reflective surface). In my shader, no pixel will be sampled at this point. A better way is to sample from a cubemap as a ‘fallback’ reflection.

(Screen space reflection without fallback cubemap)

(Screen space reflection with fallback cubemap)

One cool thing with deferred shading, is that G-Buffers can be used for implementing many screen space post processing effects. Screen space reflection is one of those effects which has been applied in AAA games for last couple years. The idea is to do a ray tracing in screen space on each pixels to simulate real-time reflections.

(Screen space reflection as post-processing effect)

References: 

Shimmering effect in shadow mapping is the ‘shaking edges’ of the shadows with the movement of camera.

(Shimmering effect is obvious when rendering shadow map with bilinear filter)

This artifact is caused by the arbitrary movement of light view casting discrete shadow depth information on shadow maps. To fix this issue, an offset will be applied on light view, making it aligned to the shadow map pixels:

RVec3 viewForward = (shadowTarget - shadowEyePos).GetNormalizedVec3(); RVec3 viewRight = (RVec3(0, 1, 0).Cross(viewForward)).GetNormalizedVec3(); RVec3 viewUp = (viewForward.Cross(viewRight)).GetNormalizedVec3();

// Calculate texel offset in world space

float shadowMapSize = 1024.0f;

float texel_unit = s0.radius * 2.0f / shadowMapSize;

float dx = shadowEyePos.Dot(viewRight); float dy = shadowEyePos.Dot(viewUp); float offset_x = dx - floorf(dx / texel_unit) * texel_unit; float offset_y = dy - floorf(dy / texel_unit) * texel_unit;

shadowTarget -= viewRight * offset_x + viewUp * offset_y;

shadowEyePos -= viewRight * offset_x + viewUp * offset_y;

Comparing to light view frustum based splitting, A better way to split cascaded shadow levels is to split base on distance to camera. With this approach, the splitting planes are more nature to the users.

(Cascaded levels splitting by view distance)

With some psudo code, the idea behind splitting can be explain as:

if (PixelDepth < Level_0_Distance)

    Apply Shadow 0

else if (PixelDepth < Level_1_Distance)

    Apply Shadow 1

else if (PixelDepth < Level_2_Distance)

    Apply Shadow 2

else

    No Shadow

On issue with my project is that I have frustum split in world space and I only have pixel depth in projection space. The pixel depth cannot be used for the comparison directly since depth buffer stores exponent depth values. This can be solved by multiplying splitting point positions with projection matrix in cpu and pass them to shaders.

Here is an image of final rendering result:

Cascaded shadow map technique is the idea that rendering objects with different quality of shadow based on their distance to camera. The closer and object is to camera, the higher detailed shadow is used.

A common way to split shadow map into different detailed ones is based on distance from camera point. In my case, I’m dividing the camera’s frustum into three levels.

(Visualize frustum dividing)

Then, a bounding sphere will be calculated for each sub-frustum, marking shadow area for each level.

(Large spheres represent render area in different levels)

The sphere represents the smallest volume needed to be rendered to receive shadow in this shadow level. The light orthogonal projection will be set up encapsulating the sphere. Anything lying outside the projection volume can be ignored since they won’t be seen casing shadow in this level. A frustum culling can be done at this step to increase program performance.

For the final rendering, I find the smallest shadow frustum that a pixel is completely inside during pixel shading and sample shadow from corresponding shadow depth map. This gives me a similar result as the Cascaded Shadow Maps sample in DirectX SDK.

(Colors represent different level of cascaded shadow map)

(Cascaded shadow maps, notice the split line of two levels in the upper middle of image)

Comparing to my previous simple shadow map, a cascaded shadow map can provide me with great shadow details at close distance without sacrificing a large render area.

References:

I have implemented a basic shadow mapping in my project for a while. Since I picked up a fixed position for the light view, the light volume covers the entire scene and render everything onto a 1024x1024 depth buffer.

(Scene with shadow map)

(Light view depth buffer)

As you can see the shadow has a low resolution and it’s moved away for its casting object. I started fixing this issue by applying a slope offset.

A slope offset is an offset based on surface normal direction and light direction. The less angle between two directions, the less offset will be applied.

(Shadow depth with/without slope offset)

Slope offset can be calculated as:

SlopeOffset = SlopeOffsetFactor * saturate(1 - dot(N, L))

With a slope offset, constant offset can be reduced so shadow map is closer to the object without causing artifacts.

Still, that is not an acceptable to fix the ‘detaching shadow’ issue. Realized that this may not be fixed with a simple change to offset, I decided my next step would be implementing cascaded shadow map.

Reference: