Deferred lighting and Terrain Splatting
Author
Ok, I have my deferred renderer up and running, but I wonder how I should go about rendering my terrain which uses texture splatting. It's not a simple mesh any more with a Diffuse texture and a Normalmap texture to render attributes to the G-buffer. It has several texture layers and they are blended together in a certain way.
Should I write my "deferred" shader to be able to perform texture splatting ? Literally that would means to copy the contents of the splatting shader into it. What if something else in the future needs to have unique technique. Should my deferred shader be the only shader that knows how to render all the objects in the game using different techniques/code paths ?
Thanks.
Its PERFECTLY fine to render your terrain with different pixel/vertex shader -> is that really such a problem to set one shader for terrain and one for objects? 1 hour of work tops. =) You will need different shaders for animated/not animated and glowing/ not glowing etc objects, its not a problem! Just create common buffer storing/fetching functions and reuse them! Then create different techniques for each object type you want and set that technique before drawing them.
You could look into a Light Pre-Pass renderer instead of normal deferred. I find it allows more flexibility in terms of materials.
What's wrong with having more than one shader?
In my opinion, you shouldn't have a "deferred" shader that does everything, you should have a terrain shader with a deferred code path, a mesh shader with a deferred and forward (for blended object) code path, particles shader in forward only, etc.
As Semei said, just create common fetching functions and reuse them
You can also do something similar to this:
in "DeferredPixelShader.hlsl"
and implement the GetDiffuseColor(), GetNormal() function in the mesh shader
and in the terrain shader:
In my opinion, you shouldn't have a "deferred" shader that does everything, you should have a terrain shader with a deferred code path, a mesh shader with a deferred and forward (for blended object) code path, particles shader in forward only, etc.
As Semei said, just create common fetching functions and reuse them
You can also do something similar to this:
in "DeferredPixelShader.hlsl"
PS_OUTPUT ShadePixel(in VS_INPUT input){ PS_OUTPUT out; out.color0.xyz = GetDiffuseColor(input); out.color1.xyz = GetNormal(input); return out;}and implement the GetDiffuseColor(), GetNormal() function in the mesh shader
float3 GetDiffuseColor(in VS_INPUT input){ return input.vertexColor * tex2d(diffuseTexture, input.uv);}#include "DeferredPixelShader.hlsl"and in the terrain shader:
float3 GetDiffuseColor(in VS_INPUT input){ do texture splatting here ...}#include "DeferredPixelShader.hlsl"
Author
Thanks, I'm new to deferred lighting and I was reading a tutorial, where everything was performed in the deferred shader. Last night i modified the terrain shader to output diffuse as color0, normal as color1 etc.
Everything works great. Sorry about the dump question and the confusion.
Everything works great. Sorry about the dump question and the confusion.
One of the beauties of deferred rendering is the ability to decouple the material shaders from the lighting algorithms.
In my deferred setup, I have one render target for the diffuse color, which would be the end result of say texture lookups, texture splatting, procedural materials, etc.
So for example, in your terrain you could have your texture splatting and write your normal and final color to your GBuffer MRTs. From everything I understand about deferred rendering, your lighting pass should have absolutely nothing to do with the output color of the surface materials. Nothing to do with texture lookups or texture splatting, etc for object surfaces. This opens up a ton of flexibility.
In my deferred setup, I have one render target for the diffuse color, which would be the end result of say texture lookups, texture splatting, procedural materials, etc.
So for example, in your terrain you could have your texture splatting and write your normal and final color to your GBuffer MRTs. From everything I understand about deferred rendering, your lighting pass should have absolutely nothing to do with the output color of the surface materials. Nothing to do with texture lookups or texture splatting, etc for object surfaces. This opens up a ton of flexibility.
Author
Yep, some say, that deferred lighting forces a single lighting model over the entire scene. Here's what I'm thinking. Is it possible for some meshes to render them using their shader with different lighting and output the color for the diffuse RT and mark the normal somehow. Then in the deferred lighting pass, skip and don't light those pixels of that mesh and sample only the diffuse RT(wich contain already lighting and stuff) to output the final color ?
An easy way is to output a "material id" in one of your g-buffer channel.
When you do the lighting pass, you can customize the lighting based on that material id. But you'll most likely have to do dynamic branching in your shader.
But S.T.A.L.K.E.R. for example, used the ID to look into a 3D texture instead. The texture contains some surface properties in order to customize the lighting for each ID.
When you do the lighting pass, you can customize the lighting based on that material id. But you'll most likely have to do dynamic branching in your shader.
But S.T.A.L.K.E.R. for example, used the ID to look into a 3D texture instead. The texture contains some surface properties in order to customize the lighting for each ID.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
