#### Archived

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

# From Classical Radiosity to ...

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

Hello to everyone... Few days ago i finished my first radiosity calculator. I don''t know if my approach is good or how much good it is, but it works for now. In fact, i made it using only the general knowledge a novice, on the subject, programmer can get by reading papers on radiosity. I mean the general idea is that every point in a 3d world is an emitter and a receiver of light!!! That''s my approach. And the implementation is done using raytracing. From every lumel in the world, that has some amount of light to give, shot to every other visible lumel. The amount of light transfered from lumel to lumel is computed using form factors (this is the radiosity part!!!). I know this is not the classical matrix solution radiosity, but this is how i did it. Know, i want to know, if there is any tutorial, or detailed paper on more advanced radiosity techniques, such as hemicubes, or Monte Carlo raytraycing, for speeding up the whole process. And something i read all over the net(!!!). Is real-time radiosity possible????? I saw a course on gameversity (nice name!!!), and some papers on the subject, but no source or implementation on that. So, i must say that i''m a little suspicious on that. I mean, how much real-time, can radiosity calculations be??? Real-time means 30-60 FPS??? And then where someone can put AI, or simple animation, if the most time i spent on lighting calculations??? And in what kind of cpu, can it be real-time??? I mean there is no GPU specific stuff that can help radiosity (i think), so all the work must be done by the cpu!!! Thanks in advance... HellRaiZer

#### Share this post

##### Share on other sites
First: please stop using so much exclamation (!!!) and question (???) marks :D

>I know this is not the classical matrix solution radiosity, but >this is how i did it.

Not many radiosity algorithms try to *directly* solve the matrix (because the memory consumption can be overly large). But the popular "refinement" kind of algorithms solve this matrix equation, although iteratively instead of directly.

>And in what kind of cpu, can it be real-time??? I mean there is >no GPU specific stuff that can help radiosity (i think), so all >the work must be done by the cpu!!!

To be realistic, you can''t do radiosity in real-time on current machines. Simple scenes (cornell box) might be possible but don''t even dream about processor time left for physics or AI.

Search google for "hugo elias radiosity". Hugo Elias''s article explains the hemicube algorithm for computing the form factors. All it requires is basic scanline rasterizer, so you *can* optimize radiosity using GPU. I haven''t tested that method, but it might be the fastest method around.

- Mikko Kauppila

#### Share this post

##### Share on other sites
quote:
Original post by HellRaiZer
Is real-time radiosity possible?????

You can use radiosity to precompute the lighting in the scene. Then use this information (lightmaps, just a texture really) to draw the lighted scene. I think Quake2 lighting was calculated using radiosity.
edit: this only works for static lighting.

[edited by - Koen on June 4, 2003 7:35:00 PM]

#### Share this post

##### Share on other sites
For "realtime global illumination style images", this might help

http://www.research.scea.com/gdc2003/spherical-harmonic-lighting.pdf

Even though they claim realtime performance, I sure would like to see a demo of this algorithm before becomming a beliver.

#### Share this post

##### Share on other sites
Thanks for the link.
I already read it. And despite the fact, that i had no problem with the maths (maybe a little!!!), i didn''t understood the main principles of it. So i can''t use it. And, if i remember right, it can be used for self shadowing only. It doesn''t produce shadows and other stuff. It just lights the model!!!! And if you want a demo, try playing Unreal 2. I nearly sure that it use this technique, for lighting animated models!!!

HellRaiZer

#### Share this post

##### Share on other sites
Ludde,

http://www.donw.co.uk/shl_exe.zip (5MB)
http://www.donw.co.uk/shl_readme.txt

My Ivanic/Ruedenbuerg SH rotation code isn''t working despite it being what I believe to be an exact implementation of their 1996 (plus 1998 corrections) paper.

When that''s fixed, I''ll upload the source.

#### Share this post

##### Share on other sites
Please if you have code, the upload it. I''m very curious to see it. Btw, the demo was impressive. Good job.

HellRaiZer

#### Share this post

##### Share on other sites
Perhaps I should just add one little note: although SH lighting is currently the new hype technique, and often praised as the ultimate solution for lighting, it is in fact far from that. SH lighting research is still at the very beginning, one have to keep that in mind.

Besides it being a very interesting technique, it has a lot of nice advantages, that''s for sure: implicitly encoding light transfer functions of individual lightsources allow (unlike traditional radiosity *) a fully dynamic light environment with all the nice additions we know from global illumination: interreflections, soft shadows, colour bleeding, etc.

But that''s pretty much where the advantages stop. It has many drawbacks: the most obvious being, that it is a static model technique. It is not applicable on dynamic, moving objects. Yes, you can interpolate (and also rotate) the transfer functions, but the visual results of that are generally bad, especially if complex shadows are involved. So, this limits you to static models - just as traditional radiosity. Compared to traditional progressive refinement or Monte Carlo radiosity, spherical harmonics tend to have much worse quality. The transfer functions just can''t capture the details needed to accurately represent hard and complex shadow boundaries.

That said, research on SH lighting is advancing every day, so those limitations might eventually fade away. Especially the dynamic model issue is under heavy investigation. But with the currently available models, you should ask yourself, if an implementation is really worth it - especially if you already have a working traditional HDRI/radiosity solver. Not to say that SH lighting is bad, there are lots of interesting applications for it. But it is not the miracle solution some people think it is.

*) Note: It is also possible to encode per-vertex or even per-pixel incident-direction dependent transfer coefficients using a traditional radiosity approach. This will also allow a dynamic lightscape, similar to SH lighting, although more limited (and at a higher memory cost). But OTOH, the quality will also be much better. You decide.

#### Share this post

##### Share on other sites
Thaks for the demo, very impressive.

One question. Since it only works for static geometry, what about using it to dynamicly light static world geometry?

#### Share this post

##### Share on other sites
Wow, I wasn''t expecting many downloads of that thing. I''ve had to take down the original download since you guys were bleeding my bandwidth dry I''ve re-uploaded a 2MB version of the same name but this time it''s without the file-cached SH co-efficients so you''ll have to sit twiddling your thumbs for 30 minutes when it runs the first time. Sorry about that.

HellRaiZer,

I''ll upload the source code in a couple of days on the main page as I''ve just managed to get the Ivanic SH rotation code working. As ever it was an idiotic bug slapping me in the face, I just need to clean the code up now.

Ludde,

yep - that''s one of the ideas: use SH as your first pass (per-vertex or per-pixel) and then do your local lighting for subsequent passes using the regular lighting methods.

Static geometry really isn''t that much of a problem if you take into consideration games like Jak & Daxter: nearly everything in that game is fixed to the ground or walls and it doesn''t bother the player one bit. Neighbourhood transfer and baking of physically modelled movement are now pretty hot research areas (e.g. imagine being able to bump into a tree and have it react accordingly - http://www-2.cs.cmu.edu/~djames/) so they''ll improve the situation somewhat. Skinned characters however are a big problem - you might be able to rotate the SH co-efficients on a per-vertex basis with your bones but it just doesn''t work for the shadowing and inter-reflectance terms.

It''s still incredibly early to see if SH methods will actually turn out to be the next big lighting model to use, but it''s got a lot of people excited. I''m a bit wary of Epic''s recent announcement that they''re using it in their next technology, seems a bit premature. But I do know other companies who''ve been using this technology for the last year and they seem to be running with it.

In short, SH lighting has lots of problems. But it sure as hell impresses to show "real-time global illumination" with dynamic lighting for a relatively simple method (SH rotation excepted .

btw, if you can''t download or run the EXE, here''s a screenshot: http://www.donw.co.uk/dir.jpg

#### Share this post

##### Share on other sites
Hmm, as a big radiosity fan, I''m not so hot about SH lighting. I can''t really see the advantages over a multi-spectral radiosity approach, with stored transfer coefficients. Apart perhaps the lower memory requirements, but hmm, I don''t know. I think I''ll wait, until some more research has been completed

For an idea, here is a screenshot of a scene using a PR radiosity solution with stored transfer coefficients. All lightsources in that scenes are fully dynamic. Don''t mind the lighting bug on the right, the exposure function had a bug (over-saturation).

#### Share this post

##### Share on other sites
I must admit, this is perfect!!
Yann, can you tell the "statistics" of that screenshot. I mean
1) Number of polygons
2) Number of lights (are those two only?)
3) Is it rendered with multitexturing?
4) Time to render????????????
5) Lightmaps'' dimensions, and number of lightmaps.
6) Kind of lights (point lights (i think it is possible), area lights, or lights in the shape of the object)

The more i see from radiosity, the more i dont want to do anything else. Not even a game. A good radiosity renderer would be fine for this life!!!!

The problem is that i dont have someone to make this kind of models for me, and i can''t test my implementation on a good looking enviroment.

And a question. It''s about number (6) of the above "details". What kind of lights are more suitable for radiosity. I tested my renderer with lights, in the shape of a model. I mean, every model''s polygons that has luminosity greater than 0.0, has initial radiosity to give. I realized that model''s shapes must be of fixed shape. For example a cone light doesn''t produce what it must be. I know, this can be an error of my code, but with ceiling lights everything looks good.
And something i read in many papers. Why point lights are difficult to implement with radiosity??? I think because they dont have a normal attached to them, so you can''t compute an angle with the direction vector (to every lumel). But this can be solved, or at least i think so? Simply, the cos of the angle between point light''s normal and the point-to-lumel direction will be 1.0. I mean, for every light-to-lumel direction, the normal of the light is equal to this direction!!!

Thanks for the attention, and please i want those details!! If possible.

HellRaiZer

#### Share this post

##### Share on other sites
Has anybody every implemented the Elias method in a pixel shader? That would be interesting to see.

#### Share this post

##### Share on other sites
quote:

Hugo Elias''s article explains the hemicube algorithm for computing the form factors. All it requires is basic scanline rasterizer, so you *can* optimize radiosity using GPU.

The method can be implemented on modern GPUs without any software rasterizer. You have to do

1.) Render to float buffer.

2.) Use "counting" pixel shader to downsample this buffer to 1x1 size.

3.) Read this value back and use it as vertex (or lightmap texel) color.

Almost real-time for small (~1K vertices) scenes.

#### Share this post

##### Share on other sites
quote:
Original post by HellRaiZer
Yann, can you tell the "statistics" of that screenshot. I mean
1) Number of polygons
2) Number of lights (are those two only?)
3) Is it rendered with multitexturing?
4) Time to render????????????
5) Lightmaps' dimensions, and number of lightmaps.
6) Kind of lights (point lights (i think it is possible), area lights, or lights in the shape of the object)

1) The bedroom is part of a largeer scene (an entire house), but that room alone is about, hmm, 50k, I believe.
2) 4 lights, but only 3 switched on (the lamp left of the bed is off). I was testing by giving each light a different intensity, that's why it looks a little weird.
3) Yes, of course.
4) 0.009 secs (ie. 110 fps). The time to obtain the radiosity solution was much longer, obviously On the whole scene (the entire house), it took around 48 hours. But the house has several million faces, so that time is pretty normal. That's the drawback of radiosity. The algorithm used was multi-spectral PR with transfer tracking, using an inital HDRI shooting pass for the atmospheric light.
5) Ouch. I'm not sure, the engine doesn't tell, as the lightmaps are already packed into larger textures at this point. The bedroom takes one 1024² texture, but it's not entire used up.
6) For this screenshot, point lights (initial shooting pass distributed the energy of the point lights to the surrounding surfaces, normal PR radiosity takes from there).

Edit: Here is another shot from the same scene, but with only one single light switched on. Note that the lights are dynamic, ie. I can modify their intensity in realtime, without recomputing the radiosity solution.

quote:

The more i see from radiosity, the more i dont want to do anything else. Not even a game. A good radiosity renderer would be fine for this life!!!!

Well, radiosity also has many problems. First and foremost, the very long time required for solving it. And it's a diffuse only technique, although approximations for the specular component exist. The real advantage of radiosity is the extreme realism you get: it's currently pretty much the only way to achieve total photorealism: have a look at this image, for instance (LightScape rendering by Chang Kyung Seok). Isn't it just perfect ?

quote:

And a question. It's about number (6) of the above "details". What kind of lights are more suitable for radiosity.

Definitely area lights. No question about that, they are the most accurate representation of real-life radiation transfer.

quote:

And something i read in many papers. Why point lights are difficult to implement with radiosity??? I think because they dont have a normal attached to them, so you can't compute an angle with the direction vector (to every lumel).

The problem with point lights, is that it's difficult to accurately compute the emitted energy. In real-life, a point light doesn't exist, since it has no surface area. So in a radiosity solution, a point light would have a differential area of zero, with a finite energy emission, which is impossible. But the trick to simply distribute the energy to all surrounding surfaces works pretty well for me. It might not be 100% accurate, but you would be using area lights anyway, if you are interested in uttermost precision.

[edited by - Yann L on June 9, 2003 9:44:21 AM]

#### Share this post

##### Share on other sites
Hello Yann L!

Maybe I''m wrong, but as I see, you can''t rotate your lights around the scene with your radiosity solution. You can change the light parameters (like intensity, color...).
This is the difference between the "dynamic radiosity" & the precomputed radiance transfer.

bye, Fnt

#### Share this post

##### Share on other sites
quote:
Original post by FanThomaS
Maybe I''m wrong, but as I see, you can''t rotate your lights around the scene with your radiosity solution. You can change the light parameters (like intensity, color...).
This is the difference between the "dynamic radiosity" & the precomputed radiance transfer.

Yes, of course, the light position is static. It''s not realtime radiosity, that would be a little bit out of reach of current technology, with scenes of that complexity

#### Share this post

##### Share on other sites
Those are some cool screenshots, Yann. You mention that your lights are dynamic but which parameters are dynamic? Intensity is one, is colour, position and rotation dynamic?

I''d like to address the first issue of spherical harmonics being unable to to represent complex shadow boundaries and lighting. It''s right that SH lighting in its current form can only address low-frequency lighting due to the low orders we use for projection. However, impractical as it is, if you raise SH lighting to around the 32nd order it can address this issue. One big problem with SHs is the effort it wastes in encoding low-frequency lighting with the higher orders. The paper "All-Frequency Shadows Using Non-Linear Wavelet Lighting Approximation" suggests an alternative whose results are much more impressive for shadowing than SHs.

Your implementation of radiosity seems to be able to handle local light sources in a way SH lighting cannot. I don''t believe SH lighting is currently of any indoor use but it''s great for outdoors where you can treat your skydome as a time-varying HDR light source, rotating it and changing it for the time of day and the current weather conditions in real-time. How does the radiosity approach handle this?

I''m beginning to understand why people are getting excited about this though. Everywhere I look I see mention of building specific GPU functionality to handle SH lighting. I wouldn''t be surprised if this is a current research effort going on at the nVidia labs.

Finally, SH lighting can be extended to handle arbitrary BRDFs such as BSSRDFs and tailored glossy surfaces. I know radiosity has its problems with non-diffuse surfaces and that techniques have been developed to overcome this but I don''t believe their realtime counterpart have the same generality as that which SH lighting promises. Or rather, I''ve seen real-time subsurface scattering with SH lighting, but not with "realtime radiosity" techniques

#### Share this post

##### Share on other sites
Doh, static light position, ignore that question

#### Share this post

##### Share on other sites
the power of sh is that the light-direction is variable and realtime changeable. so its definitely great for static objects that are moveable. generally known as rigid bodies. while the world itself can be radiosity-lit, the objects that can bounce around in it cannot. but they can interact with a global world-grid of the light-directions of the radiosity-solution (similar to the light-grid in quake3) to solve realtime an about-radiosity solution for those meshes. say powerups, munition-packets, etc.

and with the neighborhout-transfer (how the FUCK do you write neighbourhoutdfjlsdfljds?!?!), you can softshade perfectly the radiosity-lit world around it as well.

radiosity for the world, where lights don''t move.
sh for the objects, where lights can move around them (or, the objects move around the lights)

while its not perfect (only directional lights actually), it works very well. namely as well as environmentmaps.

a combination is the best.

"take a look around" - limp bizkit
www.google.com

#### Share this post

##### Share on other sites
quote:
Original post by Yann L
Yes, of course, the light position is static. It''s not realtime radiosity, that would be a little bit out of reach of current technology, with scenes of that complexity

Yeah, I know!

#### Share this post

##### Share on other sites
AP: Well, I never said that SH was inherently bad. But in it''s current form, the quality is not what I''d expect from a global illumination solution. Yes, you can raise it up to the 32th or 48th order, or more, but is that still realtime ? Things might change with dedicated SH hardware though, that''s a fact. I fully agree on the wavelet issue though: I personally think that spherical harmonics might not be the best available mathematical model to represent complex lighting. Non-linear wavelets or partial fractal functions, on the other hand, might very well be. Unfortunately, their realtime implementation is much more involved.

quote:

Your implementation of radiosity seems to be able to handle local light sources in a way SH lighting cannot. I don''t believe SH lighting is currently of any indoor use but it''s great for outdoors where you can treat your skydome as a time-varying HDR light source, rotating it and changing it for the time of day and the current weather conditions in real-time. How does the radiosity approach handle this?

Yes, I agree that SH lighting is well suited for outdoor useage. My current radiosity implementation handles that by subdividing the sky into multiple bands (16 currently), tracking the individual light transfer over each band, and encoding compressed directional energy information into each vertex/lightmap texel. At rendertime, those directional coefficients are decompressed, and multiplied with the colour of the individual sky subbands. From the principle, it''s just another method to encode directional incident light, the realtime part is not very different to SH. Expect, that instead of several orders, I need to multiply several energy bands. Not much runtime difference, I guess. I can obviously not continuously rotate my transfer functions, but I can represent high frequency shadows. Hmm, as so often, tradeoffs everywhere...

davepermen:
"a combination is the best."

Yes, I definitely agree with that. I guess I will implement a test SH framework, and try it on my outdoor HDRI solver. Let''s see how it performs, and compares to the radiosity solution. I guess the quality differences outdoors won''t be too visible, since you almost never encounter high-frequency shadows from skylight anyway. The advantage of continously rotating the light distribution on the skydome is admittedly very interesting.

#### Share this post

##### Share on other sites
spherical harmonics are to lighting what environmental maps are to reflections. only useful for "objects".. where you can use a (cubic) envmap to fake reflections in a good way on an object (a mesh), there you can use sh to simulate complex lighting in a good way.

sh are in no way global illumination for me. they are a complete solution for how a mesh does diffuse light (or even with the full matrix for specular light as well), depending on an infinite far away lightsource.

thats all they are. but thats still a lot, and very good.

oh, and radiosity is not at all a very good solution.. there are a lot of details lost in it. as you have to precalc it, you can as well precalc all the other lighting phenomenons as well, and just store per patch an "incomming light envmap/sh". put that realtime into the brdf of the material there and voilà, you have the full lighting solution realtime, with speculars and interreflections and all the crap.

the only problem, most is static then. except the brdf actually (and, with individual "incomming light envmap/sh" per light, dynamic changing of light-values is possible as well, intensity and color, i mean...

"take a look around" - limp bizkit
www.google.com

#### Share this post

##### Share on other sites
quote:
Original post by davepermen
oh, and radiosity is not at all a very good solution.. there are a lot of details lost in it. as you have to precalc it, you can as well precalc all the other lighting phenomenons as well, and just store per patch an "incomming light envmap/sh". put that realtime into the brdf of the material there and voilà, you have the full lighting solution realtime, with speculars and interreflections and all the crap.

Actually, I do not agree with that. Radiosity is a very good approximation for an entirely diffuse light transfer. It loses information, where directional (ie. non-uniform BRDFs) come into play. In reality, almost all materials show some kind of specularity, but you have to take the human brain into account: visual psychology. Radiosity might not be a technically accurate representation of light interaction (only photon-tracing is), but it is a damn good visual representation. Especially, if you add specular effects by other methods over the diffuse solution.

Let''s face it: a good radiosity rendering is indistinguishable from a photograph. We CG professionals might be spoiled, we tend to look at every small detail: are the highlights at the right positions, is the reflection correct, etc. But show that Chang Kyung Seok rendering I linked to earlier, to Jow Average on the street. He will think it''s a photograph. 100% guaranteed. (if it wasn''t for the symmetric plant models )

What do we want more in CG ? View-dependent materials, of course: anisotropic BRDFs, good reflective and refractive behaviour. But SH lighting will not solve that yet. An low order SH approximation is worse than a radiosity approximation, in terms of lost information. The only advantage of current SH technology is the dynamic freedom it gives your lightsources at minimal performance overhead. That''s a great advantage, no question, but you trade off a lot of quality for it. As I said earlier, that might change with faster SH-enabled hardware (higher SH orders), and ongoing research. But currently, it just doesn''t cut it, in terms of quality.

The solution would be a full envmap per patch. That''s unfortunately not practicable on current hardware. SH lighting might approximate that, but it''s a visually poor approximation, compared to a ''perfect'' reference system. Your BRDFs can be as good as you want, if the incoming light is incorrect, you just won''t get the right effect.

#### Share this post

##### Share on other sites
yann, i just don''t know where you actually try to compare radiosity and sh. they have nothing in common. sh are a way to store the influence of incomming light on each surface patch on a mesh. the lighting then is done realtime.

radiosity is a simple precalc method for lightmaps. as you can cummulate lights, and simply scale lights, of course the light-intensity of each light can get dynamically changed. but radiosity is a full precalc method for lighting. nothing is dynamic. and then, i prefer to use something fully solving the problem, because there is no reason to then restrict to simple diffuse interreflections. photon - tracing is then fully solving the problem, so why not choosing it?

sh are an extension to bumpmaps. instead of just storing a normal and using that to simulate lighting on a plane, you store a small very compressed envmap, wich shows in wich directions it can "see the light" (the normal on a normal-map shows the same actually). sh are bether bumpmaps for me. to generate them, you have to use some sort of gi over the mesh. but thats about it.

"take a look around" - limp bizkit
www.google.com

• ### Forum Statistics

• Total Topics
628730
• Total Posts
2984431

• 25
• 11
• 10
• 16
• 14