> union{
>         #declare toothblob=blob{threshold 0.7 cylinder{0,y,1,1 pigment{rgb
> 1}} }
>
>         object{toothblob translate <0,1,0> }
>         object{toothblob translate <0,2,0> }
>         object{toothblob translate <0,3,0> }
>         object{toothblob translate <0,4,0> }
>
>  // pigment{rgbft 1}   //but this line uncommented out fixes it??
> }



Hmm. I wouldn't be surprised if it went away after you changed the toothblob
definition to

#declare toothblob=blob{threshold 0.7 cylinder{0,y,1,1} pigment{rgb 1}}

So that the *blob* has a pigment, rather than just one of its components.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

In article <3e1e41b1$1@news.povray.org>,
 "Greg M. Johnson" <gregj:-)56590@ao:-)l.com> wrote:

> I found some code which gives an annoying (and false) warning about lack of
> pigment.  It happened when I was unioning a whole bunch of blobs together.

The problem is here:

#declare toothblob=blob{threshold 0.7 cylinder{0,y,1,1 pigment{rgb 1}} }

The blob itself doesn't have any texture, the POV code that checks for a 
texture doesn't know about the component textures. Meshes probably have 
the same problem. A dummy texture is the only method I know of to get 
rid of the warning, it could be in the blob instead of the union.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3e1e4452$1@news.povray.org>,
 "Sir Charles W. Shults III" <aic### [at] cflrrcom> wrote:

>     This is because you have specified the pigment for only the first blob- 
> look at your parentheses.  The following four blobs do not have a 
> pigment specified for them.  When you uncomment that last pigment 
> statement, it is applied to the entire union.

Wrong. The first blob is a declaration, the other objects are copies of 
it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> The blob itself doesn't have any texture, the POV code that checks for a 
> texture doesn't know about the component textures.

  Which IMHO is a bug which should be fixed.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3e1ed91a@news.povray.org...
>
>   Which IMHO is a bug which should be fixed.
>

As a general comment on this, IMHO texture-handling for all CSG-like operations
could do with more flexability. IIRC there's not much chance of this being
'fixed' until 4.00

For example:

union{
    object{foo texture{pigment{rgb 1}}}
    object{bar texture{pigment{rgb 0.5} normal{granite}}}
    object{foobar texture{normal{granite}}}
    texture{pigment{rgb 0.25} normal{bozo}}
}

It would be nice foo used the normal{bozo}, bar used nothing, and foobar used
the pigment{rgb 0.25}

Post a reply to this message

Tom Melly wrote:
> For example:
> 
> union{
>     object{foo texture{pigment{rgb 1}}}
>     object{bar texture{pigment{rgb 0.5} normal{granite}}}
>     object{foobar texture{normal{granite}}}
>     texture{pigment{rgb 0.25} normal{bozo}}
> }
> 
> It would be nice foo used the normal{bozo}, bar used nothing, and foobar used
> the pigment{rgb 0.25}

That doesn't make any sense.  If I have a CSG such that

Union[textureA]
   Sub-objectA[textureB]
   Sub-objectB[textureC]
   Sub-objectC[no texture]

Then it would make sense to have sub-objects A and B use the textures
that are specifically assigned to them, but C use texture A because
that's what's given for the overall CSG...you would have it ignore a
texture specifically assigned to a sub-object.

-- 
--Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote in message
news:3e1ee9d7@news.povray.org...
>
> That doesn't make any sense.  If I have a CSG such that
>
> Union[textureA]
>    Sub-objectA[textureB]
>    Sub-objectB[textureC]
>    Sub-objectC[no texture]
>
> Then it would make sense to have sub-objects A and B use the textures
> that are specifically assigned to them, but C use texture A because
> that's what's given for the overall CSG...you would have it ignore a
> texture specifically assigned to a sub-object.

No - where a texture component is specified I would have it used. What *I* would
like is unspecified components (e.g. the normal, pigment, or finish) of
sub-objects to inherit that component from the default texture of the union.

It still potentially creates a problem, but not, I think, the problem you raise.

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> No - where a texture component is specified I would have it used. What *I* would
> like is unspecified components (e.g. the normal, pigment, or finish) of
> sub-objects to inherit that component from the default texture of the union.

  This should not happen implicitly.
  A subobject can perfectly have no normal specification (you don't want
any normal modifications for it) and you want it to stay that way in the
CSG as well, even though the overall texture for the CSG could have a
normal specification.
  If anything, this functionality should be behind a keyword or something.

  Perhaps something like:

union
{ object { whatever pigment { rgb 1 } normal { to_be_specified_later } }
  object { ... }
  ...
  normal { bumps 1 } // this applies to the first object
}

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3e1eee8e@news.povray.org...

>   This should not happen implicitly.
>   A subobject can perfectly have no normal specification (you don't want
> any normal modifications for it) and you want it to stay that way in the
> CSG as well, even though the overall texture for the CSG could have a
> normal specification.

This indeed was the problem I forsee with my proposal - IMHO though, it is more
common to want to apply a default texture than the reverse (well, if the word
'default' means anything;).

Perhaps an empty block when you don't want the default?

e.g.

texture{normal{}} // will receive default pigment and finish if specified, but
not normal


>   If anything, this functionality should be behind a keyword or something.

<snip>

Yeh, but by the time you've added a keyword, you've lost the (shorter) coding
advantage....

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3e1e4acd@news.povray.org...
> Hmm. I wouldn't be surprised if it went away after you changed the
toothblob
> definition to
>
> #declare toothblob=blob{threshold 0.7 cylinder{0,y,1,1} pigment{rgb 1}}
>
> So that the *blob* has a pigment, rather than just one of its components.
>


Cool.  I had a scene file with a whole page of warnings, which was getting
annoying.

Post a reply to this message