Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

MicroPsycho

The hemicube rendering [Radiosity]

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

hi, I have read hugo elias'' article, http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm and I was woundering how do I sum up all light that a patch can see, because the way I understand the article is: that I should render the scene from the point of view of a patch with a pbuffer to create the hemicube, but if I use a pbuffer the data would in a texture, which I can''t loop through and sum up. have I misunderstanded something? I think so, but how do I render the hemicube, and sum up loop? thanks, MicroPsycho

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Well, you can render to texture, lock it, read, etc... but its slow...
Nevertheless, it''s now possible to do a very fast implementation w/ pixel shader (soon realtime for simple radiosity ?)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You should first take a look at this project :
http://www.cs.ucf.edu/graphics/GI-Sumant.html
it includes vertex shader/pixel shader txt files...

The way I though to do it :
The problem is there isnt (or I didnt find) how to keep a value you can increment and get back at the end of the render (that would be the same as locking, so it seems kinda impossible).
So, the way I would do it is doing texture shader that reduce texture size (by doing an average value, u can go each step by a factor of 4 I think, by example 256x256 -> 64x64 -> 16x16 -> 4x4 -> 1x1)
Then, when u got the 1x1 texture (of course try to put 1x1 texture on a bigger one with u,v coords, would prevent massive texture change between each polygon rendered), just render the scene with each quad textured with its associed 1x1 texture (do not forget to disable bilinear filtering).

I haven''t tested speed of this approach (only did a shader few weeks ago that divide texture size to check if this method would work) , but it would probably be very fast, at least hundreds time faster than locking/reading, which implies sync between your prog & rendering pipeline...

Let me know if it works really and if anybody got a better approach, plz let me know, I have to say this one is a bit ugly hehe

xen

Share this post


Link to post
Share on other sites
9 times out of 10 you won''t have as much light going upwards as downwards, thusly you could half the top reslution and send that to the bottom.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!