 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
>
> Isn't texture part of material though? I always thought writing
> pigment{...} by itself was just a shortcut for
> material{texture{pigment{...}}} (and texture{...} a shortcut for
> material{texture{...}})
My own understanding is that 'material' is just a container, not a functional
'wrapper'--just to encapsulate the more important elements inside, to easily
move then from one place to another. A goofy real-world example would be a
lawyer with his briefcase; it holds all his important legal papers, so he can
take them into court. Other than that, though, the briefcase has no function in
his actual law practice.
Same for POV's 'transform' keyword, I think.
In other words, the material{texture{pigment[...}}} 'hierarchy of importance'
actually stops at texture{...}, conceptually speaking.
Yet I'm rather hoping that my analogy is wrong(!)--so that someone more astute
here cwill correct me, and *I* can get a better understanding of the situation.
;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> 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.
The 'transform' keyword serves the same sole(?) purpose--
#declare my_transform =
transform{
rotate{...}
translate{...}
matrix{...}
--etc. etc.
}
And the docs say that using a transform block like this is more efficient for
POV-Ray than typing all those various individual 'transforms' every time they
are needed, as-is, in a group. Perhaps the same efficiency is produced by a
'material' container.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.01.2013 22:04, schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Good to know!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> 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.
Didn't know that!
> And Scott wrote:
> Good to know!
Yes indeed. Thanks Clipka.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
