Hi all.
I am making some test with Ambien Occlusion.
When using the irradiance cache i have we seen that mantra almost hang my computer due to excessive use of memory.
The render without using irradiance caching, so computing all the AO: 20 MB.
The render using irrandiance cache in Read Only mode: 1 GB.
The render using Read Write mode: 1,06 GB.
I think that this change from 20MB to 1GB is not logical when the unique difference is that I am using the irradiance cache.
The cache file have a size of 75MB.
I am using 128 samples, and an error of 0.1 in the cache.
Any othre with similar problems?

Using Houdini 8.0.521, Ubuntu 5.10.

Thanks

That does seem rather strange, especially considering that the file size is only 75 Mb. What is the resolution of your image? Are there a lot of sharp features in the scene that could cause a large number of results to be placed in the irradiance cache? How is the memory use affected by a small increase in the error (eg. to 0.2 or 0.3)?

Andrew

Hi andrewc for your reply.
I have made many render test to show my results.
Hopefully it hepls to drop some light on this.
I have a scene with a robot and a plane.
The plane have a size of 29 in both axis and 4 rows and columns.
The GI only calculates Ambient occlusion, with 128 samples, 0.001 bias and 10 in the maximum intersect distance.
-Rendering only the robot without using irradiance cache:

Render time: 1m47s
Memory: 10.37 MB

-Rendering with the plane:

Render time: 10m39s
Memory: 18.07 MB

Why this difference in render time, when i have added only a simple plane?

Now using the irradiance cache.
I generate a iradiance cache using the scene with the robot and with the plane. Put the irradiance cache in Write Only.
Cache file size: 6.4MB
Cache settings: default error 0.1. Default samples 128. Using Read Only
-Rendering only the robot:
Rendering time: 44s
Memory: 40 MB

-Rendering with the plane:
Rendering time: 1m3s
Memory: 47.1 MB

So some of the problems with the cache seems solved. Maybe i put wome wired value in any parameter, but doing all again seems to work fine.
My problem now are some artifacts when rendering with the cache. These artifacts are more evident in the contact areas between the feets and floor and in sharp edges, compare the image below with the previous ones:

For this last image i have used 256 samples.

Sorry for the large message.
Thanks.

lisux
Why this difference in render time, when i have added only a simple plane?

I suspect the cause for large increase in render time is because the ground plane adds 3 times more geometry coverage to the image, all which have occlusion being run on it.

Wolfwood

lisux
Why this difference in render time, when i have added only a simple plane?

I suspect the cause for large increase in render time is because the ground plane adds 3 times more geometry coverage to the image, all which have occlusion being run on it.

Yes, it should be the reason. I remember RenderMan making great speed ups in Ambient Occlusion with this type of geometry because it can interpolate nearby results when the geometry doen's have many changes in his shape.

More problems I have noticed.
The memory “eating” by the irrandiance cache continues.
At the beggining the renders gous well, but while more frames are rendered the cache grows from 7 MB to 420 after 50 frames rendered, using Read/Write mode obviously, and then Mantra needs to load all the cache and the process memory size is about 1.5 GB, when in the forst renders it only occupies 50 MB.
The second problem is this:

The floor contact shadows is not updated properly, even being updated the cache every frame. And there are artifacts in the foots.
It seems like the cache is not getting valid values.
I have used even an error of 0.01 trying to avoid this artifact, but with no luck.

I think the cache is per frame, so use $F in the filename of the cache maybe? That would explain the bizarre occlusion results too )

Cheers,

Peter B

pbowmar
I think the cache is per frame, so use $F in the filename of the cache maybe? That would explain the bizarre occlusion results too

Cheers,

Peter B

Thanks Peter.
I thought that the Write/Read mode of the cache was intended to do animations, to update the cache frame to frame, calculating the pixels that changes, in basis of the margin error, adding tem to the cache, but reusing the pixels that does't change. So you don't need to use one cache file per frame. I am in a mistake?
I am now making a test render, and this is the evolution of the irradiance cache:

• Frame Size(MB)
  1 5
  5 13
  7 18
  15 39
  17 44
  
  
  The coverage of the image is almost the same, why this great increase between frames?
  Here is the scene that causes these crazy renders:
  
  http://personales.ya.com/lisux/testAO.hip [personales.ya.com]
  Someone can share their experiences/workflow using Ambient occlusion in animation with Mantra?
  Thanks.

Hmm, I believe I don't know what I'm talking about, I will need to let Mark or Andrew comment definitively on this. Sorry, I assumed it was a discreet per-frame cache that would speed up re-rendering of that frame.

Cheers,

Peter B

pbowmar
Hmm, I believe I don't know what I'm talking about, I will need to let Mark or Andrew comment definitively on this. Sorry, I assumed it was a discreet per-frame cache that would speed up re-rendering of that frame.

Cheers,

Peter B

No problem Peter.
But it is so difficult to use Ambient Occlusion with Mantra?
I don't belive that, there must be any way.

Before I say this, let me clarify that I haven't used GI in Mantra, but things are more or less similar between renderers, so…

Irradiance caching doesn't store information about time. So, in a multiframe render, in Read/Write mode to the same map, a point may be occluded in one frame, but in the next it may receive illumination. The point will receive and average correctly the incoming radiance, but during final frame rendering, when the renderer quieries the irradiance map, the point would have store illumination form all the frames in animation - that is why you see “the shadow” of the leg in frame e.g. 100, although the illumination for it is in fact created for frame e.g. 1.

So, solution will be to craete a unique file for every frame and only use a singla map for non-moving objects (in a different pass, of course)

Cheers

edit: additionaly, gi rendering methods such as irradianca caching are view-dependant, so adding something, even a simple plane will add quite a bit of render time for sampling and memory for storing…

Diula is right on the money.

You can use i3dconvert to convert your irradiance cache file into a normal bgeo which you can read with a File SOP. That way you can see where the cache points are.

You'll notice its time/view dependent.

A picture is worth a 1000 posts.

OUt of curiosity, I wonder why the points are clustered so? Is it related to a Jitter setting?

Jason, the clustering is related to some internal (fixed) parameters that control the irradiance extrapolation.

Wolfwood and diula are correct, the irradiance cache files are not intended to propagate data between frames. If you want to cache the data, you'll need to use per-frame files. Note that the irradiance cache does not need a file to operate - if no file is specified, it will do the caching in memory.

Andrew

Well maybe I am trying to do something that is not possible in the Mantra GI implementation.
Some vray users, told me this render uses one cache, the render identifies what pixels have changed and then update this pixels for the next frame and reuse the cache in the pixels that doesn't change.
How it so it I don't know exactly, becaus eto have a safety error margin it needs to sample enough pixels and extrapolate it to identify potential changes, but this is another history …
I understandm and thanks, diula explanations.
Well then I have to make and extra pass for the GI.
For AndrewC, it is possible in Mantra to control the error of the extrapolation?
In RenderMan is possibl eto set it, the render looks where more samples are needed and in the zones qhere not so much caclculus is needed it applyes a more aggressive extrapolation.
Mantra can do this type of extrapolation?
It is possible to control this in Mantra?

Well, here it goes again. I hope I can explain it better than the first time
There are two scenarios that you ned to address:
a) Static geometry and a moving camera (e.g. a street flyover) - mode Read/Write
b) Dynamic geometry (xform or vertex transorms) - camera doesn't matter - mode Write

In case a: You use incremental writing to the Irradiance map. In the first frame, irradiance samples will be created for all the surfaces visible for that frame and stored in the file (or memory). In next frame, as camera moves, new surfaces will become visible. Again, new irradiance sample points will be created (only for the newly visible geometry) and they will be added to the existing irradiance map. So, you are progressively adding more and more samples to the map, as new geometry is revealed for each frame. Since no geometry moves and the indirect diffuse component being irrelevant of viewing direction, this will produce correct illumination efficiently. This is mray's freeze mode, VRay Add Modes, etc…

Disadvantages: Memory consumption: For each frame you omit the computation of the geometry which already has the indirect lighting computed - great, you save time. But for each frame, you put more and more samples in the map, increasing it's size more and more, until it may not fit in memory at all…yet still for a given frame, you may store millions of points, that are not visible in it….

case B: You have animated geometry. e.g. a white room and a red ball bouncing in it. If you try the same cache mode (Read/Write) here with color bleeding, you'll see that the color bleeding from the ball sticks to the walls over time -a nuce effect but obviously incorrect. This due to samples being time ignorant…So the only solution will be to regenerate the cache for every single frame…

Interpolation: The Error value will determine how close the clusters of samples need to be. As in mental ray, mantra uses some internal methods to determine where it needs more samples, based on proximity, normal deviation, etc (as visible in the pics wolfood posted). So tuning here is key, I don't think anyone will give some magic numbers

On a final note: Mantra is definitely not as flexible as mental ray for irradiance caching, but it looks all right…Mayba time for some RFEs:
1. Allow for Multiple Cache Files on separate objects
2. Dynamic offload of data from the map for the render tile, that doesn't need it. e.g. load only as much of the cache as you need, similar to mip-mapping

Cheers

Thanks diula, very instructive.
I think that thiese instructions should be in the docs
And forthe RFEs, I am with you, ehwn the cache file is huge mantra "eats all of your RAM, using a tiled file format, like the RAT, will be very useful.