This is something that has been bugging me for a long time, and I've finally
gotten up the nerve to post about it ;-)

It concerns the use of multiple 'bare' pigment statements in an object. Not
something I ever do, simply because it doesn't work. But the documentation at
various places makes it unclear as to why.

For example, this doesn't work:

object{...some object...
 pigment{...}
 pigment{..another pigment with some transparency...}
      }

The 2nd pigment *completely* overrides the first; there's no 'layering.'

Essentially, the problem as I see it has to do with 'default' (implied) texture
wrappers around pigments, vs. explicit (user-added) texture wrappers. The two
cases seem to show different behaviors, and it's not clear why.

Here's the basis for my possible misunderstanding:
In 2.3.4.1 (part of 2.3.4 "Advanced Texture Options") it says: "Pigments can
also be layered one on top of the next so long as the uppermost layers are at
least partially transparent so the ones beneath can show through." Is this meant
to imply that the pigments need no explicit texture wrappers? Seen 'in
isolation', it could be read that way. Yet all the examples there make use of
explicit wrappers--no simple 'naked' pigments. And other parts of the docs (and
examples) generally use explicit textures too.

However, in 3.5.1 "Pigment" is says:
"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...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."

So it's clear that an implicit texture wrapper is added around a bare pigment
statement...one that *should* be equivalent to typing a full  texture{...}.

But here's the basic question: If a bare pigment has a 'default' (implicit)
texture wrapper, then why does using a 2nd bare pigment (also in a 'default'
texture wrapper) completely override it? That doesn't happen when *explicit*
texture wrappers are used. There's no (clear?) distinction made in the docs
between the two situations. *Is* there a clearly-understood difference (one that
needs an explanation in the docs)? Or does this indicate a bug?

Something else I discovered: Using multiple bare pigment statements causes some
really weird behavior in the final result. Example:

box{0, 1 scale <1,1,.0001>
 pigment{bozo scale .2}
 pigment{
  gradient y
  color_map{
   [0 rgb <1,0,0>]
   [1 rgbt 1]
   }
  }
 }

Aside from the 2nd pigment completely replacing the 1st, the SCALE in the 1st
pigment inexplicably affects the 2nd one! This is certainly not right. (Of
course, I'm doing something apparently 'incorrect' here anyway, by applying
multiple naked pigments.)

Post a reply to this message

Am 26.01.2013 22:10, schrieb Kenneth:

> But here's the basic question: If a bare pigment has a 'default' (implicit)
> texture wrapper, then why does using a 2nd bare pigment (also in a 'default'
> texture wrapper) completely override it? That doesn't happen when *explicit*
> texture wrappers are used. There's no (clear?) distinction made in the docs
> between the two situations. *Is* there a clearly-understood difference (one that
> needs an explanation in the docs)? Or does this indicate a bug?

Here's the catch:

- Bare pigment statements are not implicitly wrapped in texture 
/statements/ (which define textures) but in /textures/.

- To define layered textures, you don't specify multiple /textures/ for 
the object, but multiple /consecutive/ texture /statements/. (You can't 
even put a "#declare" in between.)

When this syntax was originally designed, it /should/ have been 
something like:

     texture {
         layered
         texture { ... }
         texture { ... }
         ...
     }

But whoever added this feature to POV-Ray chose to do it differently.


> Something else I discovered: Using multiple bare pigment statements causes some
> really weird behavior in the final result. Example:
>
> box{0, 1 scale <1,1,.0001>
>   pigment{bozo scale .2}
>   pigment{
>    gradient y
>    color_map{
>     [0 rgb <1,0,0>]
>     [1 rgbt 1]
>     }
>    }
>   }
>
> Aside from the 2nd pigment completely replacing the 1st, the SCALE in the 1st
> pigment inexplicably affects the 2nd one! This is certainly not right. (Of
> course, I'm doing something apparently 'incorrect' here anyway, by applying
> multiple naked pigments.)

Sounds weird and unintentional. I'll have a closer look at this. I'll 
also check whether this affects stuff like:

   #declare BOX = box { 0, 1 scale <1,1,.0001>
     pigment { bozo scale .2 }
   }
   object { box
     pigment{
       gradient y
       color_map{
         [0 rgb <1,0,0>]
         [1 rgbt 1]
       }
     }
   }

becase this should effectively be the same as your construct.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Here's the catch:
>
> - Bare pigment statements are not implicitly wrapped in texture
> /statements/ (which define textures) but in /textures/.
>

Hmm, I'm having trouble understanding that. What is meant by a 'texture' without
{..} brackets (if indeed I'm reading this correctly)? That's a new 'construct'
to me, conceptually speaking. Is it some kind of distinction that POV-Ray works
with internally?

Post a reply to this message

Am 27.01.2013 13:53, schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>
>> Here's the catch:
>>
>> - Bare pigment statements are not implicitly wrapped in texture
>> /statements/ (which define textures) but in /textures/.
>>
>
> Hmm, I'm having trouble understanding that. What is meant by a 'texture' without
> {..} brackets (if indeed I'm reading this correctly)? That's a new 'construct'
> to me, conceptually speaking. Is it some kind of distinction that POV-Ray works
> with internally?

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.

Post a reply to this message

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.

Post a reply to this message

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