Can someone just help me understand the philosophy of how unions are
textured?

I had code like this

#declare FINGER=
    union{
        cylinder{bar1, foo1, blah  }
        cylinder{bar2, foo2, blah  }
        cylinder{bar3, foo3, blah   pigment {White}}
    }

union{
    object{FINGER}
    object{other_untextured_object#1}
    object{other_untextured_object#2}
    texture{T_Brass_1E}
    }

What happened was that the whole thing looks like brass except for the
one segment I painted white.  The question is why didn't the texture
statement at the end there override the pigment statement above?   I'm
trying to understand the rationale so I can do things more intuitively
in the future....

Post a reply to this message

"Greg M. Johnson" wrote:

[Snip code]

> 
> What happened was that the whole thing looks like brass except for the
> one segment I painted white.  The question is why didn't the texture
> statement at the end there override the pigment statement above?   I'm
> trying to understand the rationale so I can do things more intuitively
> in the future....

I think the rationale is that union{} allows you to group objects to be
able to interact with them as if they were one object, without having to
go through the trouble of applying transformations to every single one
of them, rather than creating a single object out of many constituents. 
Think of it as a "group" rather than the strictly mathematical "union".

It can be a b*tch sometimes (as with the texturing of my tank turrets in
the previous IRTC round) but it is better this way in most cases.

Think about it for a second, if it behaved the way you thought it did,
how would you be able to change the color of the skin of your person
without changing the color of his/her eyes, hair and fingernails?

-- 
Francois Labreque | The surest sign of the existence of extra-
    flabreque     | terrestrial intelligence is that they never
        @         | bothered to come down here and visit us!
  videotron.ca                                  - Calvin

Post a reply to this message

Answer is shorter than your message subject line :-)  Hierarchy.

Well, okay, that's not a real answer.
Any texture (pigment, finish, normal, etc.) placed into an object statement (or
primitive, etc.) gets applied and remains from then on when used in CSG.
Unless--- and this is a big unless--- the same texture keywords are used after
the first inside the *same* object; not counting whole 'texture' statements
because of layering.
Hope that made sense.

Bob H.

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:3A800076.6EB9CAB2@my-dejanews.com...
> Can someone just help me understand the philosophy of how unions are
> textured?

Basically, you can set a default texture for the whole union that will be
applied to any parts of the union that are not individually textured
elsewhere. So, if the bulk of your union is white, but one object within it
is black, then you only need two texture statements - a black one for the
black object and a white one for the whole union. If the behaviour was
different - for example, if the union texture over-wrote the object texture,
then you would have to apply individual textures to every object in the
union, even though only one of them required a different texture to the
rest.

Where (to me) things get more confusing is the following code:

union{
  sphere{0, 1 pigment{White}}
  sphere{0, 1 translate x*2 normal{bozo 10}}
  sphere{0, 1 translate x*-2}
  pigment{Red}
  normal{granite}

}

Here, the sphere with the bozo normal applied generates a warning ("no
pigment"). Also, the white sphere will have no normal. I understand what is
happening, I just don't find it very useful or intuitive.

IMHO it would be better if the red pigment was applied to anything without a
pigment statement, and the granite normal to anything without a normal
statement.

Post a reply to this message

Tom Melly wrote:

> IMHO it would be better if the red pigment was applied to anything without a
> pigment statement, and the granite normal to anything without a normal
> statement.

Is this a flaw in design (not really a bug)?

Post a reply to this message

"Greg M. Johnson" wrote:
> Tom Melly wrote:
>
> > IMHO it would be better if the red pigment was applied to
> > anything without a pigment statement, and the granite normal
> > to anything without a normal statement.
>
> Is this a flaw in design (not really a bug)?

Neither, really. It is caused by the fact that specifying a pigment, normal
or finish without the texture {} brackets around is only a shorthand. A
whole texture is always generated, where default pigment, normal and finish
are used when none are specified.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Rune" <run### [at] inamecom> wrote in message
news:3a8081e5@news.povray.org...
> "Greg M. Johnson" wrote:
> > Tom Melly wrote:
> >
> > > IMHO it would be better if the red pigment was applied to
> > > anything without a pigment statement, and the granite normal
> > > to anything without a normal statement.
> >
> > Is this a flaw in design (not really a bug)?
>
> Neither, really. It is caused by the fact that specifying a pigment,
normal
> or finish without the texture {} brackets around is only a shorthand. A
> whole texture is always generated, where default pigment, normal and
finish
> are used when none are specified.
>

Then I would argue that this is indeed a flaw in the design (if you think
the syntax would be more useful if it worked as I suggested).

It only takes a few mistakes to realise what's going on (pigment =
texture{pigment} etc.) - the point is that additional coding is required to
work with this system.

Post a reply to this message