Jump to content

  • Log In with Google      Sign In   
  • Create Account


Deferred shading and material properties


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 KaiserJohan   Members   -  Reputation: 1094

Like
0Likes
Like

Posted 23 December 2013 - 05:00 PM

I am using assimp to import 3d models. Assimp defines the following material properties (http://assimp.sourceforge.net/lib_html/materials.html):

  • Diffuse color
  • Ambient color
  • Specular color
  • Emissive color

To use with the typical phong shading alghorithm.

 

I am using a OpenGL 4.3 deferred shading renderer, and I'm wondering how to exactly pass on these proprties between the geometry pass and the shading pass? At the moment I output position, normals and diffuse from geometry pass but those are all used. I've read about somehow packing these values in the alpha component, is that the best approach? Problem is of course i have 4 properties but only 3 alpha components.

 

Any input is much appreciated.

 



Sponsor:

#2 Samith   Members   -  Reputation: 2114

Like
2Likes
Like

Posted 23 December 2013 - 05:43 PM

This is one of the tradeoffs of deferred rendering. In the standard, basic deferred rendering setup all your material properties have to be written to your geometry buffers. Because bandwidth is expensive, this means you need to carefully choose which material properties you need, in order to cut down on the amount of data that needs to be written per pixel in your geometry pass.

 

My guess is that right now you are writing out position in one buffer, normal in another, and diffuse color in a third buffer during your geometry pass. This leaves you with three alpha channels. One common sacrifice is to settle with monochromatic specular color (one channel instead of three). That only leaves ambient and emissive color left. You probably won't lose much visual fidelity if you force ambient color to be the same as the diffuse color, meaning the ambient irradiance is multiplied by the diffuse color and that is the ambient radiance at that pixel.

 

Emissive color doesn't REALLY have to be a material property. Emissive color represents radiance at that texel that is to be added into the scene. Emissive color is almost a light source in itself, and you could actually draw models with emissive color twice: once during the geometry pass, where you write out all the normal material properties (position, normal, diffuse, specular, etc) and then once again during the lighting pass, where you simply add in the emissive color to the final lighting buffer. This has the cost that the model must be drawn twice, but hopefully you don't have TONS of models with emissive color, so it might not be that bad.

 

Also...

 


Problem is of course i have 4 properties but only 3 alpha components.

 

Those four properties are actually twelve properties tongue.png  One property each for the red, green and blue channels of each color.



#3 Hodgman   Moderators   -  Reputation: 28582

Like
1Likes
Like

Posted 23 December 2013 - 06:05 PM

'Ambient color' makes no sense as a material property... What kind of object is green when lit by a cloudy day but red when lit by a white light bulb?
If you're going for realistic lighting, you don't need it.

You also don't have to just use those 4 properties, you can choose your own.
Does assimp really not import other material properties that may exist in the source files?

#4 Chris_F   Members   -  Reputation: 2198

Like
0Likes
Like

Posted 23 December 2013 - 06:15 PM

I wouldn't suggest using assimp in a game. Using it in your own asset tools to convert your meshes into a format that the game engine can easily load into VBOs without conversion or parsing makes a lot more sense. You are free to handle materials any way you like, you don't have to use assimp for that.


Edited by Chris_F, 23 December 2013 - 06:28 PM.


#5 theagentd   Members   -  Reputation: 539

Like
0Likes
Like

Posted 23 December 2013 - 08:15 PM

If you're using OGL3+ you should reconstruct your eye position from depth instead of storing the full eye position. Since you'll also need depth anyway for depth testing, you're basically saving 48 bits of data per pixel by doing that.

 

Normals can be encoded to 2 values: http://aras-p.info/texts/CompactNormalStorage.html

 

 

Example of geometry buffers:

 

Light:
GBuffer0: DiffuseRGB, Glow

GBuffer1: NormalAB, specular intensity, glossiness.

 

Glow is meant to represent the emissive value. It's multiplied by the diffuse color to achieve an emissive effect. If you want an orange emission somewhere, you make the diffuse texture orange there and make your "glow texture" white at the same spot. Although this works reasonably well, it will look a bit washed out as you zoom away from objects since mipmap filtering will start messing with both the diffuse and glow values. To solve that, you can store the emissive values directly in the light accumulation buffer.

 

Heavy:

GBuffer0: DiffuseRGB, specular intensity

GBuffer1: NormalAB, reflectivity, glossiness.

(GBuffer2: MotionVectorXY)

Accumulation buffer: EmissiveRGB

 

In my case I use the last unused value for a reflectivity variable for screen space reflections. I also have motion vectors for motion blur and reprojecting for temporal supersampling, which are stored (if motion blur or temporal SSAA is enabled) in an additional GL_RG16F g-buffer.



#6 AgentC   Members   -  Reputation: 1259

Like
0Likes
Like

Posted 24 December 2013 - 07:15 AM

I would also suggest handling emissive and ambient during the G-buffer pass, by binding the light accumulation rendertarget and rendering to it already during the G-buffer pass. It's slightly more bandwidth, but then you can easily have different per-object ambient light settings and don't have to either use up G-buffer channels for emissive or do a second pass for emissive objects.


Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...

Urho3D (engine)  Hessian (C64 game project)





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS