Hi!
I use a makefile to create a lot of frozen octrees using colorpict modifiers
(via aliases). These octrees are than used as instances to build a part of a
building, which is than transformed into a frozen octree. So I want to get
frozen octrees for all major parts of my scene which should be useable on
their own, without dependencies on other files.
My makefile than runs rpict on the octree, and I get a nice image.... but I
don't see any image mappings.... I also don't get any error or warnings (I
was used to get "image xxx uses yyy kB" when I used image map patterns so
far).
Are the image maps included in a frozen octree? Do I need any special switch
in rpict to make colorpicts visible (I use just vp vd at the moment)? Is
there anything special when using alias-modifiers in instances (i get my
geometry from dxf2rad, so for each object, I define a file object.mat which
contains just the aliases refering to material definitions in a global file
project.mat).
Thank You, CU, Lars.
Lars O. Grobe wrote:
Are the image maps included in a frozen octree?
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.
Do I need any special switch
in rpict to make colorpicts visible (I use just vp vd at the moment)?
Is there anything special when using alias-modifiers in instances?
No and no.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi!
So it is better to avoid any "cd"-command in Makefile, and specify all paths
relative to the Makefile's directory? Even in the material file (which is not
in the same dir as the Makefile)?
So far I have been thinking that the path is relative to the file where it
appears, but in fact, relative to the process' starting dir makes much more
sense.
Thank you, CU, Lars.
Hi!
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
···
Am Mittwoch, 16. Oktober 2002 17:13 schrieben Sie:
Lars O. Grobe wrote:
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'd certainly hope so! (though I'm too lazy to test reight now)
Greg?
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?
As a principle, replmarks will transform everything. After all, It
just generates the appropriate xform commands or instance primitives
in the output.
Did you verify that a single tile shows the pattern when viewed
eg. with objview? Just to eliminate simple mistakes like mapping
to the wrong side of it etc...
As another remark: For very simple objects like this, instances
create more overhead than they are worth. Consider using the -x
argument with the scene file instead of -i with the octree.
Oh, and I hope you're not using the -m parameter to replmarks...
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Lars O. Grobe wrote:
I use a makefile to create a lot of frozen octrees using colorpict modifiers
(via aliases). These octrees are than used as instances to build a part of a
building, which is than transformed into a frozen octree. So I want to get
frozen octrees for all major parts of my scene which should be useable on
their own, without dependencies on other files.
My makefile than runs rpict on the octree, and I get a nice image.... but I
don't see any image mappings.... I also don't get any error or warnings (I
was used to get "image xxx uses yyy kB" when I used image map patterns so
far).
Are the image maps included in a frozen octree? Do I need any special switch
in rpict to make colorpicts visible (I use just vp vd at the moment)? Is
there anything special when using alias-modifiers in instances (i get my
geometry from dxf2rad, so for each object, I define a file object.mat which
contains just the aliases refering to material definitions in a global file
project.mat).
Thank You, CU, Lars.
In general, it is a good idea to make the picture references local when you create your model (or in a local subdirectory), then move/copy the pictures/subdirectories along with the frozen octree to a library location for convenient access. As long as this library location is included in your RAYPATH environment variable, Radiance will be able to find both the frozen octree and any pictures it refers to in that directory.
This same trick works for scene files -- you can refer to oft-used scene descriptions that exist in your private (or public) library directory, and these scene descriptions can include any geometry they need in their local directory or subdirectories via !xform commands they contain. This was accomplished by a change that came out with 3.0, where xform searches directories in the RAYPATH variable rather than simply looking in the process' local directory. It's actually a huge advantage to the way it used to work, but you have to be aware of it!
-Greg
If you only want to shuffle the tiles in the x-y-plane, try instead of
"pic_u pic_v" "tile_u tile_v"; this will repeat the image and you won't
see the difference (if your tiles are all of the same size, of course).
I played around with picture.cal recently (after the colored window
thread) but found no time to prepare a html documentation.
Thomas
···
On Thu, Oct 17, 2002 at 04:08:59PM +0200, Lars O. Grobe wrote:
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
--
Thomas Bleicher
[email protected]
...................................................................
Hast Du sonst noch was zu erz�hlen oder benutzt Du Windows?
-- Martin Neitzel
Hi!
I rewrote my Makefile, so I store all geometry in dxf, pic in tif (that's
what the rest of the team gives me), and make than converts everything into a
work directory. Here I use oconv and co, and in the makefile, I set the
RAYPATH=$RAYPATH:./ . That works fine in general, but if I use material
aliases, the pictures are not mapped. That's quite funny... I always used a
mapping-file containing only aliases to the material definitons which I hold
in a seperate file, as dxf2rad uses layer names to set modifiers, and I was
able to simply correct the mapping without interfering with the rest of the
scene if one object changed. Are there any special issues concerning
colorpict and aliases???
So, with
oconv material.mat mapping.mat object.rad sky.rad > object.oct
I have no visible mappings, with
oconv material.mat object.rad sky.rad > object.oct
everything is fine.....if I set the modifiers in the object.rad file itself.
Thank you, CU, Lars.
Lars O. Grobe wrote:
Hi!
I rewrote my Makefile, so I store all geometry in dxf, pic in tif (that's
what the rest of the team gives me), and make than converts everything into a
work directory. Here I use oconv and co, and in the makefile, I set the
RAYPATH=$RAYPATH:./ . That works fine in general, but if I use material
aliases, the pictures are not mapped.
You do realize that you need to specify the modifier *for the alias*
instead of for the aliased material?
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Hi !
You do realize that you need to specify the modifier *for the alias*
instead of for the aliased material?
Stupid me..... no, I really didn't know THAT.... is this documented? I was
always defining the material including the colorpict modifier and "mapped"
this material to the modifier that dxf2rad used in the geometry. Now i
changed this - and that's it....
THANK YOU for this hint, I'd never found this....
CU Lars.
Lars O. Grobe wrote:
Hi !
> You do realize that you need to specify the modifier *for the alias*
> instead of for the aliased material?
Stupid me..... no, I really didn't know THAT.... is this documented?
There's a hint in the description of the material types, saying
that aliases are "useful when the same material is used with a
different modifier".
So you never wondered how Rayfront manages its complete flexibility
in composing modifier trees? That wouldn't be possible without
reassigning modifiers through aliases. Not that you really need
to know that when using Rayfront, as it happens transparently in
the background and all you see is that it works... 
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
