 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Quick-'n-Dirty Radiosity |
|
 |
ctoan Member since: 9/25/2002 |
|||
 Posted - 5/22/2003 9:49:06 AM |
||||
This is a question directed at Yann-L (or anyone who knows how he did it  ) about his plant screenshot posted a while back. He mentioned that the plant cast shadows on itself using 'Quick-'n-Dirty Radiosity' but the main shadow casting system was turned off. This interested me...I mean, radiosity that's quick, easy, and preferable to typical stencil shadow volumes? Anyway, I'd love it if someone could explain this for the rest of us to use! Chris Pergrossi < ctoan > My Realm |
||||
|
||||
|
VladR Member since: 12/4/2001 From: Slovakia |
|||
|
Posted - 5/23/2003 2:25:05 AM |
||||
quote:Ehm, no. Quality radiosity isn`t quick. You can fake it to be near real-time (for simple scenes) but it definitely isn`t real-time alternative to stencil shadow volumes. Google it or just go here for some basic info on fast radiosity: http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm Basically you divide the model into patches (triangles or quads) and let every model`s patch be a light source radiating light to every other patch in a model. You have to stop the algorithm at some point and it depends on you whether you want to wait long for quality result or faster less-quality one. While I do not know what specific radiosity algorithm does he use (he implemented most of them, AFAIK), I think that he means just radiosity that converges fast and doesn`t need to be precisely calculated on supercomputers (which costs hell of a money). VladR Avenger game |
||||
|
||||
|
Yann L Moderator Member since: 2/6/2002 From: Breizh |
|||
|
Posted - 5/23/2003 9:50:21 AM |
||||
| Well, the word 'quick' is highly relative... I meant quick in terms of fast convergence and low-quality, since I didn't want to wait hours for some test trees. The radiosity I used is a basic progressive refinement system, taking only vertex colour into account. That's usually enough for a tree, considering the high tesselation. I first shot the primary light from a HDRI envmap, but only monochromatic, distributed over the full spectrum (ie. greyscale lighting). I then do a quick PR convergence over the tree mesh, by path tracing only, no hemicubes. Taking into account the leaf texture alpha, of course. This step is multi-spectral, ie. takes into account the full colour spectrum, to allow colour bleeding, although I started with a monochromatic primary light. That's because I wanted the tree-inherent colour bleeding (the green leaves, etc), but no influence from an external spectrum. Not at this point. So I had a tree, with per-vertex radiosity (RGB) that would represent the internal lighting, assuming a monochrome external spectrum. The realtime lighting is done via a combination of a local per-tree incident illumination cubemap (indexed via per-pixel EMBM), combined with the per-vertex radiosity. The illumination map is computed at scene build time, by using the full radiosity solution for the entire 3D world. That way, I can instance a single tree geometry, but still have full local lighting (with soft shadows). And all I have to store per instance, is a small 16*16*6 cubemap. That's not even 5kB per tree or tree group, however complex the reference tree model is. The internal per-vertex tree radiosity solution is the same for all trees. So in short: * internal self shadowing and colour bleeding is done once per tree mesh, through per vertex PR radiosity. * external radiosity and soft shadows are added per-instance, by using an illumination incidence EMBM cubemap. * Sharp shadows and local lights are added by shadowmaps and dot3 lighting, per-instance. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
