View Full Version : distributed calculation of a radiosity

07-16-2007, 11:43 AM
I just rendered an image. The Radiosity solution took 12 hours. Rendering itself took 1.5 hours. I work in high res for print.

This is a feature request: I need to be able to distributed calculation of a radiosity solution over a rendering farm.

How urgent is it to you? Anybody has a solution for this while Newtek is figuring this one out?

Just for fun I attach the rendering.

07-16-2007, 12:18 PM
Agreed, up-to-date distributed rendering and a total rewrite of LWSN is on top on the list here too.
In the meantime i'd suggest Fprime, with BNR it can easily split your pic in slices automatically and distribute them on your farm, then it collect them and makes an unique pic. It does all alone, you simply have to tell it how many slices do you want.


07-16-2007, 02:00 PM
Thanks Pavlov.
What is BNR?

07-16-2007, 02:06 PM
Butterfly Net Render, I believe.


07-16-2007, 04:20 PM

07-16-2007, 05:38 PM
BNR is awesome, also 12 hours seems a bit odd with the new radiosity options. You could also try SG_ambocc with the color (color bleeding) option.

07-16-2007, 06:26 PM
Well, don't forget, I rendered at 2600 x 2600 pixels. And there is a lot of glass and metal.

I fiddled quite some time with the new options. I ended up with interpolated montecarlo. Actually the ground still showed small blotches. So that I had to retouch the ground a lot.

What we really need are two features: Being able to save the radiosity solution as a file and being able to calculate the solution over a network.

07-16-2007, 06:33 PM
Anybody knows of somebody who has a render farm which has BNR which I could hire? I think cost would not be a big issue.

07-17-2007, 02:04 PM
12 hours is a bit weird for this still
how much ray recursion limit?

07-18-2007, 10:46 AM
I made some test renders to show the settings and what I was after.

A good contact shadow was most important to me. The "Lightwave Montecarlo Not Interpolated" test I stopped. It would be finished in my next life. So yes, FPrime is a way to go although also that took quite some time. In FPrime the whole image took 10 hours for 1300 by 1300 pixels until the noise was smooth enough. The best interpolated setting was also pretty good though still splotchy but as mentioned previously, Radiosity calculation took 10 hours.

This light bulb has very demanding materials.

07-18-2007, 11:24 AM
hey, i noticed you have always tolerance at 1.
I seem to remember it was deactivated with FG, otherwise it has a big influence over result. Try to lower it to near-zero values, just to see what it happens.


07-18-2007, 11:26 AM
BNR is very good, there is also this too:

VirtualRender Bucket Renderer for LW (not tried it though)

07-18-2007, 11:28 AM
I ended up with interpolated montecarlo. Actually the ground still showed small blotches. So that I had to retouch the ground a lot.

Interpolated Final Gather is MUCH faster than Interpolated Monte Carlo in my experience, and the results are almost identical.

07-18-2007, 11:39 AM
.../....The "Lightwave Montecarlo Not Interpolated" test I stopped. It would be finished in my next life.../...


07-18-2007, 11:44 AM
Yes, I have noticed the weakness of contact shadow with FG interpollated. It is almost impossible to have good contact shadow with any interpollated mode...

Mr Maze
07-18-2007, 11:50 AM
Doesn't the 1000 rays per evaluation make the render time that high? Would it not be better to do more indirect bounces (to remove splotches), but with less rays?

07-18-2007, 04:26 PM
Can we see the setup of your glass materials? It might be that you have reflective air polys\air material in your glass. This increases both your FPrime and LWrederer render times by a great amount...

07-18-2007, 04:32 PM
Simpfendoerfer, once again: What is the setting for Ray Recursion Limit?

07-19-2007, 04:54 PM
You can download the file at http://www.simpfendoerfer.com/HalogenLight.zip

The ray recursion limit was 12. I guess I could try to cut it down.

The glass material is dielectric. Internal dielectric bounces are limited to 1.

07-19-2007, 04:56 PM

This is the reason of the LOONNG rendering time, imho...

07-19-2007, 06:22 PM
Maybe set ray recursion to 5, and MES at 100um... that's a small unit. Not sure what the world scale is but perhaps that value could be higher since you really have a sufficient number of rays. I think that you could cut your render time down to minutes instead of hours that way.

07-19-2007, 06:47 PM
Did a little test with your scene that you provided, settings that I used are in the image here. 48313 This render took minutes using the native renderer. I know I used interpolated, but I kept the ray count, lowered the recursion limit, and upped the indirect bounces. All other settings stayed as you had set them save one I think (you'll find it in the image). I hope this helps a little. Oh yeah changed the MES to 20mm also. Of course this was not the whole image but rather the region that you had selected for render I believe.

07-19-2007, 06:53 PM
Why don't you use the GI caching???

07-19-2007, 09:03 PM
Did 2 more tests, but this time of the entire scene as it was set up. I turned the lights off and let radiosity do the work with the same settings I used above and the image rendered in 24m 48s. This one I left the lights active 48315 and still didn't take hours (just above 1 in fact) in LW's native renderer, and I haven't updated to the current version of 9.2 that is supposed to handle radiosity much better. I'm still before PR1.

07-19-2007, 09:10 PM
Pixym- caching for print isn't needed. Caching is best used for animation, and more or less limited to fly-bys or turntable-like animations so that subsequent frames render faster (by not needing the radiosity solution calculated each time). Doesn't work too well if something in the environment would change the effect of the radiosity (such as lighting or another object) or if the object itself is moving changing the amount or values of the radiosity calculated.

It's a static scene though and caching would be of no benefit.

07-19-2007, 09:13 PM
I will check it out...

07-19-2007, 09:17 PM
One last thing I must point out.... I just dropped the scene in and hit render after making the changes to radiosity, so there was no shadow and no other tweaking done to the bulb to make it look like your render. I also don't have F-prime (ducks to avoid embarrassment) so those setttings didn't work for me of course....anyway....yeah.

07-19-2007, 10:06 PM
Amurelli where is the ground, the contact shadow, why is the bulb black?

07-19-2007, 10:20 PM
Pixym, thank you for pointing out ray recursion. In this instance I forgot all about it.

I did several tests and came to the conclusion the I can live with 8 recurring rays. which will bring us down to 12min 54sec from 15min21sec. I gained 16%. It reduces the rendering time for the entire image to about 10 hours from 12 at this resolution.

Usually I have to provide renderings at 9 times the size in square pixels. :(

Brings back the original question of how to putt it in a rendering farm. Most of the rendering time is taken by calculating the radiosity solution which can not be distributed.

07-20-2007, 08:18 AM
hey, i noticed you have always tolerance at 1.
I seem to remember it was deactivated with FG, otherwise it has a big influence over result. Try to lower it to near-zero values, just to see what it happens.


Pavlov, A different toleranze setting has no influence. It must be diabled. I posted a test with the second batch of images.

07-20-2007, 10:21 AM
it's disabled in FG mode. Maybe try with Montecarlo - see Amurrel's test with settings. MC is slower itself, but probably you can use much lower settings here sicne the difference between MC and FG is just something in ray's directionality. In MC mode interpolated, Tolerance works. Try very low values (near zero) and use cheaper settings in other parameters, probably you'll get contact shadows and good GI in less time.


07-20-2007, 10:34 AM
My test were all done in Montecarlo Interpolated. There was no difference between tolerance 0.1 or 1

07-20-2007, 11:06 AM
Dense Contact shadows with interpollated modes is almost impossible...
I have noticed that surface color blend too much with the contact shadow... in my archiviz scenes.

07-20-2007, 01:30 PM
Have you seen this (http://www.lightwiki.com/How_the_new_radiosity_works_in_LightWave_3D_9.2) already?

I assume so, but just in case ..


07-22-2007, 10:48 PM
Sorry it took me a while to get back to you. I just loaded your model and then rendered it right away with a few render tweaks. I did notice the lack of ground and the black buld and I'm not sure if it is a problem with the version of 9.2 I'm using or I have to in vestigate further. I'll play with it tomorrow and get a better idea of what's going on here.

07-23-2007, 07:18 AM
Worked on the render time issue for quite a while and lost a bit of sleep over it, but that's ok. These are the things that contribute to it as I have found...

After simplifying the materials, and getting the bulb to be transparent and getting a contact shadow I was looking at really long render times as you were. Here are my views and take them for what they are worth, since I'm sure there are a lot of gurus out there that can shoot holes in this, and that would be great...really.

1. The image is high resolution 2560 x 2560 and I noticed the multiplier said 400%

2. Most of the object is dielectric material, meaning there is a whole lot of transparancy going on there and a lot of bouncing of light, refraction and so on.

3. Ray recursion was set to 12, but I found that if it was set lower than 10, I would lose some of the color you were wanting to get since the light didn't bounce enough in all of that dielectric glory.

4. At that resolution radiosity either stright or interpolated is going to take a while. Interpolated is much faster however, doesn't seem so when dealing with that much resolution even with a greater MES.

5. There are three lights in the scene and a luminous poly (I replaced with an area light just for fun). The lights were for specular only and the other object for diffuse I'm assuming, plus the image world which was used for everything. These taken into account plus the bouncing of light with the needed high recursion limit and all of that dielectric material makes render time shoot way up.

6. Adaptive sampling has a lot of pixels to evaluate, but the end result is spectacular so...

I'm sure you already know all of this, but I thought that I would add it for the people who don't or who might be learning something. Heck, you're probably further along in finding the solution than I am.

With all of this taken into account I was looking at a 12hr render time as well +/- 2hrs respectively after set up (I only have dual core). The only way I was able to speed up render times while banging my head against the wall, was to reduce resolution, cut down the recursion limit at the expense of image quality (meaning losing some of the lights in the reflection) and drop the AS, all things that you didn't want.

Like I said, these are just my observations and I'm sure there is some guru out there that can do better. Maybe faking radiosity would do better, I don't know. And since I've been working for two weeks straight and this is my first day off, I'm going back to bed. Good luck! I wish I could've been more help

07-23-2007, 09:35 PM
Amurrell, thank you for your effort. Yes ray recursion at 8 was acceptable. It cut off 20%.

Yes I could try to make a picture with area light and no radiosity like in the past. I try to concur the new territory with my experiment. And I try to figure out with which odds I am dealing if I want to sell such realism at a res of 8000 by 8000.

Right now it means FPrime and render farm which I don't have yet. I also was not able to find one on the net because none of the ones I found ran LW9.2 and FPrime.