Over in the Carrara forum at DAZ an incredible tip was mentioned about how to literally cut render times in half (I've tried it multiple times and it actually really does work; I have no idea why).

So you've set up your scene, using full global illumination or skylight or whatever, it's complex and filled with detail and set to render at a large size and you know it's going to take some time.

The trick is before you render the scene at full size you first render it at an incredibly tiny size (shrink it down to a 2pixel/2pixel size, for example) and it will take only a minute or two to perform calculations and render (the pic will just be a tiny dot).  The important thing is that you check the option to 'save irradiance map' before rendering (you will also have to click on the ellipses below that section and name the map that you are saving as well as designate a location where you are saving it; additionally I think it is best to select 'calculate one map for all frames').

After the tiny render is done and the irradiance map has been saved, now uncheck the 'save irradiance map' and select the 'use irradiance map' and click on the ellipses in that section to select the irradiance map you just saved.

Now render at full size, and watch how much more quickly it will render the full size complex scene.

Renders that take me 4 hours to render normally will take about 2 hours and a few extra minutes to render using this method.  It's crazy, but it works and I can't believe how exciting and useful this little tip has been for me.  :)   I used to never use full GI but now with this little trick full GI is something I can use all the time, even with really complex scenes.

I've tested this on several complex scenes and I'm getting render times nearly cut in half every single time.  Does anyone have any idea why this is working?

I'll have to try that trick for my current project.

I think it affects the tmp and compo files in Daz tmp folder; actually I never delete those files and so you should do. carrara does it when needed. however many times this trick doesn't work fine and may cause artifacts on images at high resolutions

 The irradiance map stores calculations regarding light and bounces that can be reused. It sounds like it is independent of size of the render right now, but I think it can be stretched quite a bit. If you look closely some artifacts might be visible on close inspection, if the difference of original render size and full size is too big. But it surely is a good way to reuse calculations. 

I'm not seeing any artifacts, but the again I rarely render anything larger than 1000 pixels per side, so that may be why.  So for me this is a great little trick, but for others who make larger renders this may not be something to use.  Still, it's kind of amazing that this works.

if it shrinks a sky image to 16X16 px, then it might just look like it was lit by a blue or white IBL.
there wouldn't be occlusion artifacts, just complete loss of lighting detail.

Well I can't sit out of this thread anymore.

I have one big issue with render times and that's using raytraced depth of field.  Now if you combine ray traced depth of field with a hard hitting GI AND you have transparency objects in the scene (say like a glass marble or a clear plastic writing pen and why would I mention that?), the render times go baliistic (like days dudes and dudettes).

I will try this in combo with an image that has a big transparent object and ray traced DOF to see if it works.

What I really don't get here is why in the heck does it really matter?  When you render, all that stuff gets crunched at the beginning.  I always assumed that it didn't fuss with it anymore after that but apparently I was wrong.

And while I'm in rant mode,

When network rendering and GI came out (I can't remember what version), I did an article in Renderosity magazine to review the new version (this version of C had literally only been out about 24 hours).  I had TERRIBLE problems with network rendering using GI.  In fact, it was a problem that persisted and I haven't checked it for a while, it was such a big problem that I've actually given up network rendering.  I almost exclusively render using GI and if network rendering can't support GI, then you don't use it (right?).

The problem was that different machines computed slightly different irradiance maps induced by numerics in the compiled code.  The supposed story was that C generated different results on different machines due to roundoff issues (or some such).  So each machine that contributed a little block to the final image had a different overall hue and the result looked like you had overlaid some weird checkerboard on the final image (much badness).

When I pursued this with Eovia, they told me it was this numerics problem.  Well my gut has alwyas wondered why not follow these steps.

All networked machines compute the irradiance map.
When one of them gets done first (the speediest), it tells all the others to stop and then copies that map to all other machines to use.
Then render.

I would think this process would then eliminate numeric issues because all of the rendering nodes would be referencing the same numerical result.

In the end, I have no idea of how C really works and that idea may just be stupid because C just doesn't work that way or something.  Maybe the maps are too big?  I have no idea.

It just seemed like it was a problem that could have been managed.

Well, maybe this didn't belong in this thread but it's an irradience topic so I mentioned it.  It sort of combs my hair backwards because this trick of halving rendering times shouldn't make a difference.

It's very cool that such a trick can be done but sad that C isn't setup to do it the cool way in the first place.

Later,

Thanks for relating the tip jonstark! I really should put together a full tip list and post it here since there are so many - and some very unique to specific image/animation needs or pipelines.

Just to put a point on the pencil...

Irradiance cacheing is primarily used for camera animations through a light and object static scenes. Moving objects or light sources will void the accuracy of the cache. However, in some animation instances, the degradation isn't noticeable -  long camera shots for example. 

CG is slowly making its way to the masses and Carrara, Poser, Vue, Blender et al are poised to capitalize on that. Carrara is not swimming upstream into Hollywood. Given the fact that Carrara is probably given away more than it's purchased, it's astonishing to consider how much it does so well. DAZ is a Content company first, and a Software company second. I think I've detected some of the afore mentioned companies adopting the same strategy too.  ;-)

Carrara has it's annoyances but it's nothing like my favorite software to both equally loathe and love: Vue. :-D  

In fact, I just finished a series on Vue xStream. During the section on animation, the silly program crashed 3 times; one time forcing a complete scene rebuild. Carrara doesn't do that. 

Mark

So would this trick work on animations? Even though my animations are not super complicated, I just dont have the cpu power to churn them out fast enough.

So would rendering a single frame of the animation do the same trick?

 Yes but...

It's typically only appropriate for animations where the camera is moving and nothing else. While it's not the same thing, you can kind of think of it as illumination baking  - where the shadows and light areas are no longer independently generated from a light but behave as if they are merged to the object textures themselves. 

I have version 7 Basic and can't find a feature to save irradiance maps. Is it Pro version only?

 Hi steerpike,

Yes, it is a pro feature only.

Mark

I agree with the Vue love-hate thing.  I suffer from it, too.  When Vue works the way it should, its results are amazing.

Quote -  Hi steerpike,

Yes, it is a pro feature only.

Mark

That's fine, as v7 Pro arrived yesterday at my door bundled with 3D World magazine. Looking forward to trying the rendering technique.

Excellent tutorial in this issue, by the way, Mark.

Hey Mark,

If you post  a tip list, post it as a tutorial.  Then it's easy to find and I think you can edit it and keep adding to it.

 Good idea Kix. We'll do.