Radiosity rant (3D Fluff)

[Wokka]

Hi, just searching for comments on render times.

I recently purchased the 3D Fluff training DVD 'radiosity interiors' and found it very helpfull and interesting. The one issue (as most people seem to have) is the render time required for good radiosity solutions. My main reason for purchasing the DVD was my concern over the time my images were taking,(12-14hours) so I was a bit surprised to find that even the best in the business still have large rendering times.

The videos final render took 'only' 4 hours which is OK for architectural work but it was at a resolution of only 800x600.(480000 pixels)

I don't know about other people, but many of my clients want A3 printouts at 300dpi. (I know we can get away with 150 dpi usually) By my calculations (approx.) that is 4900x3500 (17150000 pixels) 36 times the 800x600.

I normally judge a render to be too slow if it takes more than 12 hours overnight and I can usually achieve this. If however I want to increase my quality and render at the quality 3D Fluff recommend, does that mean waiting 144 hours? (36x4hours) Even at 150m dpi that is way too long.

I understand that radiosity takes time, but having seen images from other programs, rendered at significantly shorter times, I worry about the usability of the C4D radiosity render engine. Maxon are always selling C4D as a great architectural renderer and I have had great results (with or without radiosity) but surely this rendering time issue should be investigated and solved?

Sorry for the rant, I'd just like to know other peoples opinions on this topic.

[Ernest Burden III]

In the tutorial were they 'saving the solution'? That method is how Lightscape renders a 4K line image in 10 minutes. Processing the lighting may take all night, but once done you render, render, render. Cinema has an option to save a rad. solution, and shadow maps, in v9. I haven't tested it yet, but am hopeful that it will help those rendertimes.

[STRAT]

saving the solution in c4d is a MASSIVE time saver and works nicely, as long as you dont change the scene much inbetween renders.

 

i personally find saving a gi solution more a nubes method of doing things. you should really be rendering with a fresh solution for every render you do, as inevetably your model will be tweeked differently from the last test render you did. but thats just my opinion.

The only time i save a solution is during animation rendering. never for stills.

 

full radiosity and gi isn't a fast process on whatever 3d app you choose.

 

There's a massive difference in render times between internal and external renderings.

A typical external render i do, say at 2000x1500 pixels (which btw is the largest res i generally go up to, ideal for printing up to A3, even bigger in some cases) will generally take me no longer than 1-2 hours. and thats with gi accuracy set to 100% !!!

(remember, the higher the accuracy, and i mean generally 95%+, the lower the samples you can get away with).

 

a render can be more accurate and FASTER using extremely high accuracy and lower seampless, compaired to what most peeps do, which is a medium accuracy (say 50-70%) and ultra high samples.

 

internals are a different matter, basically because everything on the screen renders and the space is all enclosed meaning every surface picks up bounced light.

A typical internal render for me at 2000 pixels can easily take up to 4+ hours, and thats with an accuracy generally set around the 95%+ mark (i hardly use 100% for internals because of the time taken to render).

 

but of course there are numerous speed saving tips that MASSIVELY determin render times, both internal and external.

 

* render/composite tags - use these wherever possible to block/accept gi from certain objects in the scene that wont be enhanced by gi.

for example - uncheck the SEEN BY GI box for an object. now that object will still recieve gi/radiosity, but wont give it out.

 

* material's illumination menu - here you can control the strength of gi that particular material generates and recieves. working in conjunction with the object tag's seen by gi box can greatly speed things up.

Also in this option is the SATURATION spinner. this is a great 'fake' radiosity tool - GI and radiosity are 2 completely different things, although usually go hand in hand in a render solution. (i wont go into the differences here). but upping the saturation level of a material gives the impression the radiosity of the material (not the gi) is being increased.

 

* Glass - generally, make sure no glass objects in the scene recieve or general gi. no need. glass is invisible.

 

* Reflections - refs make a huge difference in render times in C4D. Most 3d apps render reflections at great speeds, but C4D doesn't. and this part of the render engine needs a serious look at by maxon sooner or later.

Dont use reflections for the sake of it. and if you do make sure you antialias them individually from the main scene as it will make a difference.

If you need blurry reflections, try to avoid the blur option. there are effective fakeing methods for this.

 

* IBL and skydome GI - the more 'real' gi casting objects in the scene the longer the render times and the more samples you'll need. Try to use low light/shadow emmiting in-fill omnis in the scene to aid in the gi solution. GI generated by lights is a heck of a lot faster in rendering than GI generated by objects. And can be equally, if not more realistic. As i say, the more gi generated by lights, the less samples you'll need, hence faster rendering.

 

* Diffuse Depth - imo, the BIGGEST source of render speeds for your c4d rendering. most peeps use 2, 3, 4 or above. I always use 1. even in the darkest internals. the difference in render times between a DD of even 1 and a DD of 2 is huge. Again, clever use of infil lights can compensate for the lack of bounces.

An experienced user can use a DD of 1 whilst using infill lights to render a scene as realistically as using a DD of 3 and no infil lights, but render 10 times faster.

 

* AntiAliasing - C4D has extensive AA control. make use of it. slightly lowering the AA from it's standard can greatly reduce render times, whilst not being noticable in the final render. best to play with them and experiment.

 

 

There are obviously a shed load of other speed saving tips, but these are some important ones that spring to mind at this moment. Alot of these tips work better for the more experienced user, but again, it's all a case of experimenting and trying things out.

 

the render times i stated are on my daul 2.8 xeons. so if you can get a fast multi proc pc all the better. c4d looooves daul proc HT pc's.

[Wokka]

Thanks for your comments!

Strat, I certainly agree with you regarding rendering techniques and image size. Generally my images are 2500 x 1500 for my A3's and certainly produce acceptable results for most clients. Unfortunatley I'm being asked to 'garantee' 300dpi solutions for printing outside of my control, thus pushing up the number of pixels.

All of your timesaving tips are great and I generally follow your rules (you must get sick of repeating the . The reason I bought the DVD was I thought there'd be some simple one off solution that I'd been missing but it seems I'm getting the most out of C4D already though the DVD had some great (though moinor) improvement ideas.

I suppose I get annoyed with all the work required to either get a reasonable solution or tweaking lighting systems to appear correct. My 2.8 is Hyperthraeded but no Xeon .

Saving the solution is good for that final tweaking but I spend most of my time setting up the scene, adjusting object, lights etc. If a wall colour is changed from brilliant white to deep green, would the same solution work? I'll have to experiment with that. Also I believe the shadow solution is only for soft shadows and I tend to use a mixture and C4D seems to need to rerender the shadows if I adjust the hard shadow light source?

 

I really feel this is an issue Maxon haven't touched much since R7 and certainly makes me look at the possibility of third party renderes.

 

Thanks for your comments.

[STRAT]

If a wall colour is changed from brilliant white to deep green, would the same solution work?

 

absolutely it will, thats exactly what the cached solution is ideal for.

 

what it's not ideal for is tweeking the lighting, or tweeking the gi settings, or tweeking the camera view etc all between test renders.

[wda]

Strat,

 

Does caching the solution basiclly just "trace" the bounces or store illumination ie intensity and color info in C4D?

 

WDA

[STRAT]

Strat,

 

Does caching the solution basiclly just "trace" the bounces or store illumination ie intensity and color info in C4D?

 

WDA

 

couldn't tell you that. i dont know the actual technical ins and outs of it

 

i think it's more a gi cach rather than a radiosity cach, because as i say, changing colours of objects doesnt effect the solution, where as changing light set up does.

 

hence only gi is effected and not radi.

[Ernest Burden III]

I guess it would be nice to test. Maybe with a really simple model, like the Cornell Box. Maybe I'll get to that soon, since I have to know how cache works in practice.

[wda]

Ernest beat you to it,

 

I'd say under standard radiosity, cached solution- the effects of materials and related color bleed (GI) are stored

 

WDA

[Ernest Burden III]

Yeah, that's obvious in your test. That's too bad, in Lightscape the bounced light changes color without re-doing the light calcs.

 

However, the more important issue is speed. If you are animating, and will not be changing the lighting, a cached solution could be a real time saver. Even if you have moving objects like cars you could exclude them from radiosity (should anyway). That would bring the results more in line with what I am used to with LS.

 

Thanks!

[wda]

No problems......

 

You can temper the full red saturation test with Strat's observations. If you are dealing with real world material saturation & lighting levels the color bleed is usually not incredibly substantial and how often will you go from one primary or secondary color to another, mid to end of a project. Caching and making fine adjustments works to speed things up, just don't forget about it being cached and render out the final- .

 

WDA

[Ernest Burden III]

For a test of cached solution I rendered a simple model with a spot and rad. at 100%, not necessarily peak settings, but no matter.

 

Original render took 10:13 (minutes) at 800 x 600

re-render took 5:19

slightly changed viewpoint about 6 mins, very different viewpoint about 5 mins.

 

All it seems to do is skip the prepass, then proceed. Still, a great saving

[STRAT]

well, i appologise for the comments i made regarding colour changing. shows how much i rely on a cached solution for stills. i've always found, particulaly in large complicated scenes, the best solution is always a fresh solution.