Radiosity

[captainrex]

I've been starting to finally animate and stuff, but one thing that stands in my way is lighting effects. I have no clue how to use radiosity. I've tried it and all i get is a bunch of spots all over and have no idea how to get rid of this and get good looking lighting. Anyone know how to work radiosity?

[John Bigboote]

It might be one of those features that is prohibitive to animations because of high render time, only used for stills- but I could be wrong. Have you used the forum's Search feature to find previous discussions on Radiosity?

[captainrex]

yea i've looked. i'm not sure i exactly kno what to look for tho

[robcat2075]

yea i've looked. i'm not sure i exactly kno what to look for tho

 

Start here

 

http://www.hash.com/forums/index.php?showforum=36

 

 

the "Cornell Box" discussion should be your first stop.

 

Radiosity is a very time consuming process suited more for stills than animation.

[detbear]

When you do get going with it(radiosity)....... you may experience some incredibly long render times.

 

Especially when it comes to long animated sequences. The photon computations are heavy on renders. At least this is my experience with radiosity. Hopefully, I just haven't optimized the process and you will not have this problem. There are probably more people here with better techniques to avoid the render hit.

 

If you do run into this, see if you can composite a still render of your backgrounds with the radiosity and then try to match the moving characters by rendering them with other lighting schemes that are not so heavy on the render side.

 

Maybe there's some tricks to help with this that I'm unaware of.

 

Cheers,

 

William

[Elm]

Hi!

 

Is there any way to sort of "bake" the radiosity to a 3D set (for all Non-moving objects, of course)?

 

Thanks in advance for any help!

 

Elm.

[Fuchur]

Hi!

 

Is there any way to sort of "bake" the radiosity to a 3D set (for all Non-moving objects, of course)?

 

Thanks in advance for any help!

 

Elm.

 

You think of lightmaps, right? There has been a lightmap-functionality I stumbled about a few version back, so I never got it to work as I would have expected. Maybe I was just doing something wrong...

Maybe Steffen or Robert can say something about that.

 

See you

*Fuchur*

[robcat2075]

Unless light maps work, (I can't even find them) there is no illumination baking.

 

One way to approximate it would be to apply renders back through the camera onto the geometry, but you will need to do a render from enough angles to cover any sides of an object that will be seen.

 

Illumination baking would be a good feature request, maybe for v18? Write it up and make a case for it.

 

The old radiosity scheme did have a baking feature, perhaps it can be resurrected.

[Elm]

...

Write it up and make a case for it.

...

 

 

Would love to, but I remember trying to request a feature somewhen in the past and wasn't "authorized" for some reason ?!

Could someone point me to the feature request thread please?

 

@robcat:

 

Yeah, mapping the scene from multiple angles would be a solution, but it's quite a hassle, isn't it (the more complex the scene), and I wanted to avoid JUST that ...

[thejobe]

you can get the look of radiosity with a few tricks.

This post here shows a 5 second walk took about 3 hours to render.

i have a few lighting setups in the contributors cue that will give this effect and keep the render times to a reasonable amount.

you can also setup a skylight system to get a radiosity effect.

the fastest render i got with radiosity is about 10 mins for 1 frame at 640x480 res

[Fuchur]

The LightMaps-Export is still there:

1.) Create an object.

2.) Create a chor (with default lightening for instance).

3.) Bring the object to the chor.

4.) Rightclick in the PWS on the chor and choose "Export > LightMaps".

5.) A menu pops open. Choose a path to which it should save something.

6.) If you just hit okay after choosing a path, each object in your chor will get a new folder in that directory and there are many different image-files which were exported.

 

The maps are there, but I am not quite sure what to do next now...

I'd say these are somehow like PatchImages (so each map for each patch), but since they are not applied, I am not sure how to do that.

(the ground-model is usually just one patch and you can easily see how it was intended if you add the map of the ground as a patch-image to your ground-model...)

 

If you choose "polygon" instead of "patchmodel" the log-file next to it will contain some position-informations. (at least I think that is what it is... maybe some kind of UV-data)

 

I think I remember something that this has been implented for Avalanche and a special workflow they used a while back.

It exports maps, but I don't know how they should be used afterwards. This is one of the sleeping beauties in A:M if you ask me... I never tested it with radiosity etc. neighter, but normal light-sources work as they should.

(as far as I can see from the ground-model).

 

See you

*Fuchur*

[Elm]

you can get the look of radiosity with a few tricks.

This post here shows a 5 second walk took about 3 hours to render.

i have a few lighting setups in the contributors cue that will give this effect and keep the render times to a reasonable amount.

you can also setup a skylight system to get a radiosity effect.

the fastest render i got with radiosity is about 10 mins for 1 frame at 640x480 res

 

 

Thanks, but that's not quite what I'm looking for - your example rather has an AO / sky / domelight look, instead of an Indoor look, which I'm after.

 

Greetz,

Elm.

[robcat2075]

...

Write it up and make a case for it.

...

 

 

Would love to, but I remember trying to request a feature somewhen in the past and wasn't "authorized" for some reason ?!

Could someone point me to the feature request thread please?

 

It will NEVER happen if you don't ask. Go to hash.com/reports like you do for bugs but mark the "severity" as "feature".

 

I've asked for a lot of features over the years. Some happen, some don't.

 

Since we already have Surface baking maybe it would be a matter of adding just one more map to the result?

 

@robcat:

 

Yeah, mapping the scene from multiple angles would be a solution, but it's quite a hassle, isn't it (the more complex the scene), and I wanted to avoid JUST that ...

 

It's the only work around I can think of right now. What are you doing that needs radiosity?

[robcat2075]

Thanks, but that's not quite what I'm looking for - your example rather has an AO / sky / domelight look, instead of an Indoor look, which I'm after.

 

Greetz,

Elm.

 

 

If it's the occlusion you're looking for, FakeAO can work real well in indoor settings. And it's fast!

[robcat2075]

Here is one of my old test scenes updated to just use FakeAOGPU for interior AO:

 

 

 

I think that's pretty good for 0.57 seconds!

 

 

For comparison here are the tests from my previous thread of various AO schemes for interior lighting:

 

 

 

The "jitter" version used 256 passes of a traveling light.

[Elm]

Stunning, as always...

 

I'll try that out now.

Just in case I fail, is there a good workflow tutorial, I already did a forum search...

 

THANKS?

 

Cool, but... well...

[ernesttx]

Robcat, if the FakeAOGPU working? I haven't look at it since I thought it was still producing rectangle jaggies/anomalies?

[robcat2075]

Cool, but... well...

 

What's wrong with it?

 

 

 

 

Robcat, if the FakeAOGPU working? I haven't look at it since I thought it was still producing rectangle jaggies/anomalies?

 

In general it works well. I have a few odd circumstances.. Give it a try. Remember, the default settings are just default settings, you can change them.

[Elm]

Well it doesn't seem to work properly with the test scene I set up. All in all it's okay, but it seems to have problems with transparencies for a start...

And - I want to move away (at least a bit) from having loads of passes / compositing work.. I'm after a nice beauty pass for which I'd have some masks to tweak and that'll be all..

that radiosity thing still got me hooked - works well and fast enuogh for scenes without moving elements. Still thinking about how to integrate moving elements... If one could only bake the lighting situation!

[robcat2075]

Well it doesn't seem to work properly with the test scene I set up. All in all it's okay, but it seems to have problems with transparencies for a start...

 

True, FakeAO is a "screenspace" AO solution that uses only the depthmap as a guide. Any transparent mesh appears as an opaque surface in a depth map. It's not real AO it's just something that happens to look very much like it in most circumstances.

 

Depending on what your transparencies are, a work-around might be to do a pass with all the transparent mesh deleted and use the depthmap from that pass with your original render to create the FakeAO result.

 

 

 

 

 

And - I want to move away (at least a bit) from having loads of passes / compositing work.. I'm after a nice beauty pass for which I'd have some masks to tweak and that'll be all..

 

You can also use FakeAO in the final render as a camera post effect, but I've preferred using it in post in a Composite so i can quickly test settings to get the right look without having to re-render.

 

 

If one could only bake the lighting situation!

 

Make that feature suggestion for v18! Yves wrote the radiosity stuff I recall. Maybe he could be hired to add baking.

[Elm]

Yeah, I made a feature request already (hope I did it right ...) on A:M reports

 

I understand the advantages of the fake AO procedure, really quick and all that.. In use, it would definitely be a seperate pass in my compositing workflow, as it would have to get color-tweaked anyway to fit the scene's lighting situation right, so..

 

Okay, radiosity update: I rendered a test sequence with quite good settings ( 1 Mio. photons cast) 1920 x 1080 pixels, moving object inside.. It rendered apxx 4 hours per frame (i rendered on 40 cores), and the flickering was moderate (still a bit). I rerender at the moment with 2 mio photons casted. Let's wait and see...

 

I'll keep you updated with attached rendering comparisons.

 

Greetz,

Elm.

[robcat2075]

Okay, radiosity update: I rendered a test sequence with quite good settings ( 1 Mio. photons cast) 1920 x 1080 pixels, moving object inside.. It rendered apxx 4 hours per frame

 

4 hours for radiosity? Why... when I was a boy we had to wait seven hours just to get

... and we liked it!

 

 

I'll be eager to see what you come up with.

[Elm]

I'll be eager to see what you come up with.

 

 

Ahhh, don't expext a big bang.. Just a little indoor set with a ball slightly moving.. BUT: WITH REFLECTIONS A N D RAYTRACED SHADOWS!!! NOW WHAT ABOUT THAT?!?

 

Talking bout the Amiga days, aren't you?

[Elm]

Hi!

 

Attached the Test Renderings.

 

Notice how small the difference between 1Mio and 2Mio Photons is.. ..and the large gap between just 100.000.

Of course, the compression of the attached .mov does the rest, but there's also still some flickering in the uncompressed 2Mio-HD-Frames (1980+1080).

 

I think it's most clever to render at 1Mio, because 2Mio takes double as long to render (7h+ per frame).

 

Greetz,

Elm.

 

P.S.: Thanks to Xtaz for the radiosity scene this project is based on!

Radiosity_Vergleich_A.mov

[robcat2075]

Is that test scene on a disk or the forum somewhere?

[Elm]

My scene is based on the prj. that is attached to this post.

 

I hope I may make this public here and now, because he sent it via dropbox...

radiosity.zip

[Elm]

Just in case you wonder about why the image looks "painted" here and there - I ran the whole sequence through A:Ms "denoise" post effect to get rid of the final-gathering jitter grain.

[ypoissant]

You should be able to get rid of some flicker by increasing "Sample Area" and "Photon Samples" instead of increasinf "Photons Cast". You will get more diffuse indirect lighting but with a scene composed of mostry diffuse surfaces like this one, this should not be a problem. Increasing "Photons Cast" can significantly increase the render time. But incrasing the area and samples only increases the irradiance precalculation time.

[robcat2075]

HI, Yves, thanks for checking in!

 

While you're here... How crazy is the "baking" idea? I recall the old radiosity scheme was storing the results to a map. Was there a reason that didn't survive into the new radiosity?

 

Also... is it conceivable that GPU computing could speed up radiosity rendering?

[Elm]

You should be able to get rid of some flicker by increasing "Sample Area" and "Photon Samples" instead of increasinf "Photons Cast". You will get more diffuse indirect lighting but with a scene composed of mostry diffuse surfaces like this one, this should not be a problem. Increasing "Photons Cast" can significantly increase the render time. But incrasing the area and samples only increases the irradiance precalculation time.

 

Hi Yves! How cool you're still around!!

 

I'm not really sure (not in the office right now to check, maybe tomorrow..), but I pretty much cranked up every value.. I will post the values I used when I'm back in the office.

And - yeah - what about that baking thing?

 

All the best,

Elm.

 

EDIT:

IIRC, my values are:

 

Photons cast: 1.000.000

Sample Area: 4.000

Photon Samples: 2.000

Intensity: 90% (?)

Max Bounces: 15

Caustics: Off

Final Gathering: On

Samples: 50

Jittering 50 %

Precompute Irradiance: On

[ypoissant]

HI, Yves, thanks for checking in!

 

While you're here... How crazy is the "baking" idea?

I'm not sure how the light baking is done but at least it means that the infrastructure for producing the maps and storing values in them is there.

 

Thinking out loud here: Photon mapping is a screen space algorithm. I mean there is the first pass which is world space but the second pass is the one that computes radiosity on surfaces. And this is screen space, meaning that only the surfaces visible to the camera have their radiosity computed and the computation is done on a per camera pixel way. In other words, the screen pixels gives the structure for computing the radiosity on surfaces. Baking radiosity would mean computing rasiosity on all surfaces, visible or not. Assuming the baking infrastructure is based on the old radiosity baking technique, the calculation of radiosity on surfaces could be driven by the texels on the baked radiosity texture maps.

 

So yes, this should be feasible. The baking of radiosity would probably take quite long though. But then it would be done only once or very few times.

 

I recall the old radiosity scheme was storing the results to a map. Was there a reason that didn't survive into the new radiosity?

Two very different techniques. Although "Photon Map" contains the world "map", this map is actually a hierarchical data structure to store the photons and their position and accelerate their query during rendering. While the old "radiosity" subdivides the patches to store the light interactions between surfaces. In A:M case, this subdivision was done through textures on surfaces. Surfaces that required finer sundivisions had higher resolution textures. Those radiosity texture maps cannot by used for photon maping. And the "Radiosity" technique have been abandoned by every 3D app around because 1) It isn't flexible enough, 2) it cannot render all reflection types (glossy for instance), 3) it cannot produce hard or quasi hard shadows, 4) It is hard to parameterize and get renders that look good, 5) It flickers like mad during animation.

 

Also... is it conceivable that GPU computing could speed up radiosity rendering?

Well, the answer is not simple. In theory, every rendering algorithm can be programmed on a GPU. But the performance is oftentimes disapointing due to the limited computing model of GPUs. A technique like Photon Mapping would probably perform not too well on GPUs and programming it would require a lot of development effort. Some people have done that though. On the other hand, path tracing, a very popular global illumination technique on GPUs is relatively easy to program but gives poor performance (like several hours on a Fermi). To get really good performances on a GPU requires some extraordinary crafting. And so far, whatever rendering technique is developped, a well crafted one on a GPU is usually only a few times faster than a well crafted one on multi-cores CPUs.

 

So my conclusion is that, right now it is conceivable but not worth the effort. Development effort would be better spent utilizing all the resources of multi-core CPUs IMO.

[ypoissant]

You should be able to get rid of some flicker by increasing "Sample Area" and "Photon Samples" instead of increasinf "Photons Cast". You will get more diffuse indirect lighting but with a scene composed of mostry diffuse surfaces like this one, this should not be a problem. Increasing "Photons Cast" can significantly increase the render time. But incrasing the area and samples only increases the irradiance precalculation time.

 

Hi Yves! How cool you're still around!!

 

I'm not really sure (not in the office right now to check, maybe tomorrow..), but I pretty much cranked up every value.. I will post the values I used when I'm back in the office.

And - yeah - what about that baking thing?

 

All the best,

Elm.

 

EDIT:

IIRC, my values are:

 

Photons cast: 1.000.000

Sample Area: 4.000

Photon Samples: 2.000

Intensity: 90% (?)

Max Bounces: 15

Caustics: Off

Final Gathering: On

Samples: 50

Jittering 50 %

Precompute Irradiance: On

 

I see. In that case, try the other way around: reduce the sampling area and photon samples. My hypothesis is that you will then trade low frequency noise for high frequency noise which could be easier to iron out with noise filtering.

 

The problem with all form of global illumination techniques for animation is that all those techniques are stochastic and any object that moves in the scene can give very different results from frame to frame unless very long time is spent to compute a nearly perfect solution per frame. For photon mapping, that means increasing the final gathering samples and the number of photons as you found out.

 

Leave the intensity to 100%

 

Also, gamma correction could attenuate the noise by reducing the contrast gradients in the render.

[robcat2075]

Here's a FakeAO render that approximates the occlusion present in the radiosity render. If one were to brighten the entry area in back it would begin to look much like the radiosity render.

 

[Elm]

@Robcat:

 

Looks good! But you know my point(s)... - Do you have any Idea about faking color bleeding/radiance? Maybe with everything fully reflecting very blurry?

 

 

@Yves:

 

After I checked the cornell box tut on your hp again, I think I really have to set up the scene back from the start. Especially the portion about "visually" controlling the settings (1 pass rendering, etc) as well as taking the Scene's scale into account may improve the rendering a lot.

I'll give it a try, but right now I'm busy on something different <_ src="https://www.hash.com/forums/uploads/emoticons/minecraft_happy.png" alt="^_^"> ...unfortunately..

 

Thanks a lot so far!!!

[robcat2075]

@Robcat:

 

Looks good! But you know my point(s)... - Do you have any Idea about faking color bleeding/radiance?

 

 

 

Color bleeding? You'd have to fake it with carefully placed lights.

 

See this thread

 

the red and blue walls have colored "area" spline lights on them that I animate to brighten as the flying light approaches to simulate colored bounce light.

 

 

Maybe with everything fully reflecting very blurry?

hmmm... maybe... scattered light is rather different from reflected light however. But you might try it.