[Radiance-general] colorpict modifiers in instances and frozen octrees?

[Lars O. Grobe]

Hi!

Am Mittwoch, 16. Oktober 2002 17:13 schrieben Sie:

> No, and neither are the function files. You need to make sure
> that the paths those are referenced with point to a location
> where they can actually be found, especially after moving the
> octree to a different directory. Note that relative paths (which
> are recommended) are generally resolved relative to the current
> directory of the *process* that creates (oconv) or reads (rpict)
> the octree.

One more question regarding this topic, if I apply a colorpict to an object, 
and use this as instance, will the transformations of the instance be applied 
to the pattern, too? I have a floor build of tiles. A tile here is an 
instance, refering to an octree which is made from a rad-file describing the 
geometry at 0;0;0 with a colorpict modifier (which also defaults to 0;0;0). I 
use these instances with replmarks, so I should get the tiles with their 
pattern transformed to the points defined by the markers? Or will replmarks 
transform only the geometry to the triangle marker's position, not it's 
colorpict modifier?

In fact, I simply wonder why I don't get any patterns if I render my scene 
(and no error messages).

CU, Lars.

Here is my material-definition (as you see, the geometry is from dxf2rad ;-):

void colorpict porphyr_pattern
9 clip clip clip 13_36a_map_porphyr.pic picture.cal pic_u pic_v -s 3
0
1 2

porphyr_pattern plastic porphyr
0
0
5 .11 .11 .08 .05 0

void alias l_floor_green_stripes porphyr