|
 |
Am 29.01.2013 22:04, schrieb Kenneth:
> "Kenneth" <kdw### [at] gmail com> wrote:
>
>>
>> In other words, the material{texture{pigment[...}}} 'hierarchy of importance'
>> actually stops at texture{...}, conceptually speaking.
>>
>
> To clarify that a bit more: A 'material' container's function (the only one I
> know of) is to encapsulate a texture{...} with an interior{...}--since they are
> both separate code chunks, and there's no other way to #declare them together so
> that the combination can be easily used in multiple places in the scene code.
Absolutely. material is just a way to conveniently "bundle" textures and
interiors into one variable. When it's applied to an object, the
material is "unwrapped" and both texture and interior applied to the
object separately.
> The 'transform' keyword serves the same sole(?) purpose--
>
> #declare my_transform =
> transform{
> rotate{...}
> translate{...}
> matrix{...}
> --etc. etc.
> }
No, actually not. The transform doesn't just bundle the individual
rotations, translations etc., but rather stores a single transformation
matrix (and its inverse) that is equivalent to the combination of
translations, rotations etc. Whether you plug in a combined transform
into an object, or apply the transformations individually to the same
object, may even have an impact on performance. (Spheres for instance
profit from their rotational symmetry when you apply rotations directly,
but IIRC they don't if you apply a rotation via a generic transform.)
A transform is also the only way to store /any/ transformation in a
variable. (You can, of course, store vectors in variables and pass those
to translate or rotate, but then you are storing vectors, not
translations or rotations.)
Post a reply to this message
|
|
