Advertisement Jump to content
Sign in to follow this  
KaiserJohan

OpenGL Deferred shading and material properties

This topic is 1851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites
'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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!