On 01/28/2013 12:19 AM, Kenneth wrote:
> It might be prudent to add a few words, a caveat of some kind, to the docs
> somewhere in 3.5.1 "Pigment", about this. To help new users, or at least steer
> them clear from the path I went down, re: wondering why multi bare pigments
> don't work 'as might be expected' based on what it says there. ;-) I imagine
> that most newbies would look there first, to find out about pigments in general.
>
> I wouldn't know what to suggest (as I'm still not sure I understand the
> situation myself.) Perhaps something simple, like, "When layering multiple
> pigments, they must first be wrapped in explicit individual texture{...}
> statements." IMO, that would probably take care of the whole conundrum, from the
> user's standpoint.
>
>
Before bothering to amend that section ... wondering if anyone else 
thinks it's a worthy addition?

Post a reply to this message

> Before bothering to amend that section ... wondering if anyone else
> thinks it's a worthy addition?

   I can see the logic behind this confusion... it isn't gratuitous at
all, so I think it may be worth to add a note about it.

   On http://wiki.povray.org/content/Reference:Pigment I will add a
little sentence on the last paragraph:

--
A pigment statement is part of a texture specification. However it can
be tedious to use a texture statement just to add a color to an object.
Therefore you may attach a pigment directly to an object without
explicitly specifying that it as part of a texture. For example instead
of this:

object { My_Object texture {pigment { color Red } } }

you may shorten it to:

object { My_Object pigment {color Red } }

Doing so creates an entire texture structure with default normal and
finish statements just as if you had explicitly typed the full texture
{...} around it. Note that you still need an explicit texture statement
if you want to layer pigments.
--

   ...or something like that.

--
Jaime

Post a reply to this message

On 01/28/2013 10:51 AM, Jaime Vives Piqueres wrote:

>> Before bothering to amend that section ... wondering if anyone else
>> thinks it's a worthy addition?
>
>    I can see the logic behind this confusion... it isn't gratuitous at
> all, so I think it may be worth to add a note about it.

Good enough for me ... there's a standout "Note" where you suggested. I 
guess I just wondered because I always use texture { ... } unless 
testing. Lately I use material { ... } as it makes it easier if later 
decide to make glass ... or use subsurface.

Post a reply to this message

James Holsenback <nom### [at] nonecom> wrote:

> >
> Before bothering to amend that section ... wondering if anyone else
> thinks it's a worthy addition?

Yeah, I was wondering about that myself. For the longest time, I hesitated about
posting this topic--I thought I might be the *only* person out here who saw any
possible confusion about this, or had any questions about it. Maybe I still am!
;-)

Post a reply to this message

> What I mean is that the language construct:
>
>      object {
>          pigment { ... }
>          ...
>      }
>
> is NOT internally expanded to
>
>      object {
>          texture { pigment { ... } }
>          ...
>      }
>
> and then further processed. Rather, the two statements just happen to
> generate the same internal data.

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{...}})

Post a reply to this message

scott <sco### [at] scottcom> 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