OK, I've been fiddling with this as related to ambient occlusion(not doing full irradiance). I'm using an HDR map for the environment in a gi_light - all is working quite nicely. Where the confusion is coming in for me is the cache. I'm trying to figure out a pipeline that would try to streamline the render times and also allow rendering in layers to work properly. If I specify to write to a cache - exactly what gets written out seems to be related to the size of the RGB image being rendered. I'm all for accepting that, however if I render a “test” image at 1x1 pixels just to generate the cache(it ends up being quite small), then I would expect that if I Read the cache for a test render, I would have some seriously grotty occlusion. In fact, it seems to render quite nicely. Is there something being checked at render time and if the resolution of the cache doesn't match the image being rendered it's ignored and the render doesn't use cache? I'm just trying to figure out the process here - it doesn't seem to be documented if this is true…

Cheers,

J.C.

Do you notice a speed difference with and without an irradiance caching? I thought ambient occlusion doesn't use the irradiance cache at all? When a ray shoots out into empy space, it simply samples the HDR map as its light source no?

I didn't notice a savings, so what you're saying is consistent with my results. That's what's been baffling me and I wasn't sure what was going on. However, I would point out that the html tutorial that ships with Houdini (Environmental Illumination) is pretty clear that it's *supposed* to contain occlusion data, so it should be changed. Essentially it starts the tutorial with Occulsion only being used, runs you through a quick test, then it tells you to turn on caching and look at the time savings. Perhaps this was done back when the cache was going to include occlusion info?

Btw, it *would* be nice if this could be cached…

Cheers,

J.C.

Hey John,

I get the feeling that you can't do anything creative with the cache as it is now. You cannot “grow” cache or improve the cache quality once it has been generated. (Believe me, I've tried) All you can do is replicate your previous renders; at the same resolution and sampling. Nothing changes regardless of any new settings. This is definately an area which can be made more accessible to us in the future.

I've wanted to do similar things where I wanted to generated a big fast cache for an etire complex city scene where I wanted to fly the camera about the place, generate a multitde of smaller caches and then concatenate them into single large cache. This large cache should now be pretty detailed allow me to gerenerate some lovely fast images. Sounds good and easy….

BUT! It doesn't work. I think something is slightly broken (slighly broken/very broken, its all the same when it doesn't work), but it will not merge my caches. I am i3dconverting them to point clouds, merging, saving out BGEO's and then i3dconverting back to an icf (irradiance cache file), but no dice; I get a million errors- and besides, even if they DID merge, I've had little luck with improvement in quality of images read from low-rez caches.

I think I'm going to abandon my efforts of using caches creatively right now, possibly until Mantra gets these working a little better. However, using them in their most conservative form works fine.

Tell me if you have any good experiences, I'm very curious.

Take care,
J

Hold on a sec. I take what I wrote in my last post all back. The cache does indeed make a difference. In following the user guide content, I went from 120 sec down to 15 sec in the second render. (I can visualize Mark yelling at me right now for being an idiot. )

The user guide lesson specifically states:
“Only the v_gilight's Global tint and the object shaders' colors can be changed when using the cache file. This limits its usage but can be very effective when making little tweaks during the test rendering stage.”

This means that resolution changes won't work as you suspected in your original post.

K , thanks guys. As you've found, Jason, I'm not having a lot of success finding a practical use for the way caching works at the moment. Ed - I'll admit I've had trouble getting the cache to make a difference outside of the tutorial. Should I have the gall to change something outside of those very limited tweakables, does mantra somehow “know” this and immediately discard the cache? I'm suspecting I'm missing something in my testing that causes this, because I keep having slow renders.

As far as my testing has gone, I was trying to “bust up” the speed of mantra in doing occlusion with an HDR map. I was actually having quite a bit of success and was surprised at how fast things were(relatively speaking, of course - I mean we *are* talking occlusion here ) as I kept adding things each night. My goal was to try to keep the samples “good enough” for video playback in an all-CG scene. Added some serious worley noise patterns to surface colours, then bumps, ray traced reflections… It was actually not too bad - about 1 1/2 hours per vid res frame. Then I added moblur - which based on previous mantra experience always busted the timing. I was surprised - it went up only to around 2 hours(although of course that will vary depending on degree of motion). That wouldn't be *so* bad if you punched those out to dual racksavers per frame. Last night - I managed to break the bank, however. It was data - once I added 260K polys to one of the objects - everything went to hell. Last I checked, it was around 9 hours a frame. All those rays digging through that data was a killer.

I'm sure there's better times out there for this sort of technology, but I think that intelligent cache management would help a lot. There's also a clever hack Mario's going to look into for ambient occlusion specifically which simply makes the time problem go away…(irradiance would be something else). I'm going to wait until he has enough spare sleep to look into that…

Cheers,

J.C.