[Radiance-general] rvu: too many modifiers in ambient list

[Greg Ward]

Hi Lars,

That explains the problem.  Because each new inclusion of a material  
gets a new id, and this id needs to go into the ambient include/ 
exclude list for that modifier name, you will quickly overflow your  
ambient exclude set if you incorporate a copy of your materials for  
every object.

This is bad practice in general because it means that most of your  
memory is occupied with redundant material definitions rather than  
geometry.  A better approach is to include any materials that need to  
undergo transformations as part of the geometric object file.  If you  
just have a map you wish to apply, possibly substituting the  
underlying material, you can use an alias appropriately, e.g.:

# The map for this material:

void colorpict thisMap
7 ...
0
0

# origMat is the name of a predefined material in my main library,  
included once

thisMap alias thisMat origMat

thisMat {geometry ...}

-----
This allows you to include the main material definitions only once,  
and control them in a central library.  You can even control the  
maps, because they are named by the colorpict rather than defined  
directly in your geometry files.

Hope this helps.
-Greg

> From: Lars O. Grobe <grobe at gmx.net>
> Date: July 11, 2005 2:50:16 AM PDT
>
> Hi Greg!
>
> I guess the problem arises somewhere else. I get this problem even  
> with only on -ae modifier now. I think the problem is that I simply  
> have too many materials defined. The check in ambient.c is done if  
> I use the -ae switch, but I don't think it is the number of -ae  
> modifiers.
>
> The background is that I do something stupid at the first look: I  
> include my global material library with every object of my scene,  
> than assemble the scene with replmarks. The reason for that  
> (including into each object instead using the library at the final  
> oconv run) is that my materials have to undergo all the  
> transformations I apply to the objects (because I use image maps  
> massively). Before, I had precompiled all these objects and used  
> them as instances, so there was no need in having the material  
> definitions in all objects, but this gave a bad overhead (the point  
> is that a rotated instances still has its mapping, but a rotated  
> rad-scene has wrong mappings, cause the mapping is rotated only if  
> the material definition is IN the scene).
>
> So I guess I will have to find a way to filter the materials better  
> (so that only the materials actually used are included into an  
> object file) or live with the instance overhead.
>
> Thanks, CU Lars.