rpict, rtrace start up time and number of sources

Hi Lars,

Do you have any redirecting surfaces (mirror or prism materials) in your scene? This could be the expense of precalculating the direct reflections. In this case, setting -dr 0 will eliminate the problem, but at the expense of reflected sources. The alternate is to reduce the setting of -dp, though reducing it to 0 will make the overall calculation take considerably longer.

If you don't have any mirrors or prisms in your scene, then the most likely culprit is the source obstruction routine. Since there are no options controlling this calculation, the only option is to recompile the rendering tools setting -DSHADCACHE=0 in your rmake script. Again, the overall calculation might end up taking longer, but you will avoid the start-up time.

If your scene is not changing from one rendering to the next, I recommend using either the -P or -PP option, which will avoid all start-up costs from one rendering to the next, regardless of the above settings.

Does this help?
-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: April 16, 2008 11:20:35 AM PDT

I have the impression, while actual rendering time is not increasing to much with increasing light source counts (should be about linear in most scenes?), the start-up time of processes is increasing dramatically. What is responsible for that interesting behaviour? In a scene with some thousand sources, it takes three hours until rpict writes the first pixels (same is true for rtrace) - than it is going on fine. Is there anything I could do to speed up this phase of the rendering?

CU Lars.

Hi Lars,

If you are using ranimate, you should be avoiding startup costs already as it typically employs the rpict -S option to read views from the standard input unless the ANIMATE variable is specified. So, you should only have to wait on the first frame. Is this what is happening?

-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: April 16, 2008 2:04:51 PM PDT

Hi Greg,

thank you for that whole bunch of information! :wink: I have no redirecting surfaces, but I use (mk)illums to bundle groups of light sources for the indirect calculation. I do not know if this causes additional start-up processing.

The idea to deactivate the obstruction cache is quite promising for my case. I have one illuminated room, so all those light sources are not hidden by surfaces any way. That means that all that caching is for nothing and just wastes the start-up time in this special scenario.

I will try this as soon as the next image is done (I guess tomorrow) and report any success.

The idea to use -P is a good one - but I wonder how to do this when using ranimate to control the rendering. Maybe you remember, I am that crazy guy using ranimate to render stills - which is nice cause I can use it to continue after broken processes, distribute processes both on smp and on clusters, and all that... :wink: I will have a look at the ranimate documentation once again.

CU and thanks, Lars.

Hi Lars,

Looking at this problem some more, I tried my own scene with 1800 sources, and the start-up time with the default compile option for SHADCACHE (20) took about 11 seconds additional time to get going on a 1.5 GHz G4 processor (i.e., not that swift by today's standards). If your start-up time is three hours, I would have to have close to 2 million sources to get into that kind of range, unless your scene is somehow strangely different. Is there anything else special about it?

-Greg

My 1800 sources are in a large scene -- the octree is a few hundred megs, I think.

-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: April 17, 2008 1:32:29 PM PDT

If you don't have any mirrors or prisms in your scene, then the most likely culprit is the source obstruction routine. Since there are no options controlling this calculation, the only option is to recompile the rendering tools setting -DSHADCACHE=0 in your rmake script. Again, the overall calculation might end up taking longer, but you will avoid the start-up time.

This reduced the start-up time from several hours to 15 seconds... still I have not seen the results of the rendering :wink:

Did you check what happens if you have your 1800 sources in a large scene?

CU Lars.

Hi Lars,

I also have quite a few instances in my scene, so I don't think that's it. I don't know why meshes would be any different, unless loading all the meshes and colorpicts takes a long time by itself. I'm not sure what you mean when you say the light sources are grouped into spheres. Do you have many light sources per each of your 1850 illum's? If so, these should be defined with a glow material with a restricted radius. Otherwise, there is no point to using mkillum. Can you send me the description of one of your light sources in a separate e-mail (off-list)?

-Greg

···

From: "Lars O. Grobe" <[email protected]>
Date: April 17, 2008 2:52:31 PM PDT

My 1800 sources are in a large scene -- the octree is a few hundred megs, I think.

OK, that is strange. I try to list the more or less special characteristics.

- use of instances
- use of mesh primitives
- colorpict mappings
- lots of lights (about 1850)
- light sources are grouped into spheres, that are processed by mkillum. the illum alt material is an invisible trans type

The rpict process takes about 510MB, already being optimized for memory using instances as mentioned.

Should I get some debugging tools installed to check which functions use up all the time at the beginning of occluder-cached renderings?

CU Lars.