Jump to content
  • Advertisement
Sign in to follow this  
ArKano22

Disk-Based Global Illumination

This topic is 3158 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

There was a paper i read some time ago which proposed to reduce meshes to a disk-based representation and then calculate per-vertex GI (color bleeding + occlusion) on the gpu, using that representation. It claimed to achieve this with nlogn complexity. I wonder if anyone has ever implemented this besides Fantasy Labs, whose engine never was released (if i´m correct). I´m curious about running a demo of it or something to check the performance.

Share this post


Link to post
Share on other sites
Advertisement
No, the paper i´m talking about is this:

http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter14.html

The results seem to be the holy grail of GI, but i´m afraid it has a major drawback somewhere since it is not a popular technique today. That´s why i´m searching for oppinions.

EDIT: and this is the Fantasy Labs implementation:
http://www.fantasylab.com/newPages/rtgi.html
However no one ever heard of them again, to my knowledge.

Share this post


Link to post
Share on other sites
Well, its a fairly costly technique. You have to generate this index map for all vertices in the scene, then traverse it in a shader doing that disc-to-disc transfer operation for each step. You'll notice the fantasy labs demo is just one mesh standing on a plane. Furthermore, with that demo, they then do subdivision surfaces to make the model look more complex, since it was probably pretty low-poly to begin with (so that the technique would be fast enough).

Plus, ambient occlusion seems to be best for outdoor lighting, with distant light sources. Nonetheless, i've tried twice to implement the paper and failed miserably at it. I can't figure out how to generate the index map, even after looking over their code.

Share this post


Link to post
Share on other sites
I have done something similar before "I think", though mine was more spherical based (though havent read any papers etc)
For an index I used x,y,z positions of the data, i.e. I will write into the texture data base on the x,y,z positions to cut down the texture lookups in the shader

Share this post


Link to post
Share on other sites
Quote:
Original post by zedz
I have done something similar before "I think", though mine was more spherical based (though havent read any papers etc)
For an index I used x,y,z positions of the data, i.e. I will write into the texture data base on the x,y,z positions to cut down the texture lookups in the shader


So you stored x,y,z positions of vertexes in a texture and treated them as spheres to calculate occlusion? Its the same as the paper but w/ spheres instead of discs.

So you have any demo available, or at least a screenshot? Was it fast to compute?

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!