Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 4 of 4

Thread: Most efficient way to store "material" properties geometry pass, to the light pass.

  1. #1
    Junior Member Newbie
    Join Date
    Feb 2013
    Location
    Norway
    Posts
    17

    Most efficient way to store "material" properties geometry pass, to the light pass.

    This question is regarding deferred shading

    I was looking for an alternative way (if any) of storing material properties (i.e specularity level, material type etc) from geometry pass to the light pass.

    So far I store the kind of material (diffuse map, diffuse map with normal map etc) in the 4th component of the diffuse color, and it works great. But there are cases where I have to store properties per material (geometry Fragment glsl) that needs to interact with the light pass.

    I Could add another texture to the g-buffer that simply stored properties, and that will work, but I have some concerns of added overhead, so i was looking for alternatives

    Any advice?

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    There is usually a trade off of GPU processing verses the number of g-buffers. The easiest is to just add another g-buffer but you can pack multiple pieces on information in a single float field by using something like x + y * 100 + z * 1000 and then decompose at the other end. You can avoid float rounding problems by using an integer and using intBitsToFloat/floatBitsToInt.

  3. #3
    Junior Member Newbie
    Join Date
    Feb 2013
    Location
    Norway
    Posts
    17
    Alright, thanks for the reply. I expected this was the only way to determine the property of a particular fragment in the light pass. I added another texture to be stored on the g-buffer, performance loss was minimal. (0.1 - 0.3 %)

    Your point on using integers is a good idea, till now I used var > value due to rounding problems as you said.

    Fredrick

  4. #4
    Junior Member Newbie
    Join Date
    Nov 2013
    Posts
    7
    I would not mind so much about performance in the beginning of the deferred shading and throw in as much g-buffers as you need. When your material-system is finished then you can try to pack and reduce the channels you need e.g. could you calculate some of the properties later in the shading-stage (bitangent out of normal and tangent). GPU Gems 2 has a chapter about deferred shading in STALKER (although most probably not anymore up-to-date) where it shows a short comparison of storage options.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •