"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Yes, maybe if you reread that, you'll see where you don't understand their
> > point.
>
> I did. All the way through. Ugh. (Embarrassing, ha.) But in the 'present age', I
> now fully understand their point and where I was wrong. My basic assumption back
> then was...naive and rather uninformed :-\

I feel the same way when I read my posts going back to 2013.  <oof>
> Luckily, the UN-textured
> slicing object does not impose its own color on those surfaces...but will if
> given a 'specified' texture of its own.
>
> (I find it interesting-- and useful!-- that the un-textured object behaves this
> way, even though it does have a default texture applied 'behind-the-scenes'. Why
> it does not impose that on the cut surfaces is a mystery to me. But it's a happy
> circumstance!)

Well, if I had to speculate, it would be that there is a difference between a
primitive and an object.  We can define things as primitives, but the default
texture may not actually get assigned to them until we invoke them as visible
objects to be rendered in a scene, perhaps using object {}.

And honestly, I'd call the fact that a textured object can't be used as the
"cutter" without imparting its assigned texture to the intersection surface,
even when cutaway_textures is invoked, either a bug, or at least unexpected or
undesired behaviour.
So if I want to model a complex CSG object that I want to see in the scene, but
also use as a differencing cutter, I have to model it TWICE?
I would think that cutaway_textures should simply ignore all of the assigned
texturing of the cutter, since that's its conceptual function - to use the
textures of the cut object for the remaining surface, not those of the cutter.

> > One way to address the color selection would be to allow the optional
> > inclusion of a hierarchical index in the cutaway_textures call.   No index
> > averages the colors as is currently the default behaviour.  Supplying an
> > index allows the user to choose some texture in whatever texture
> > hierarchy that POV-Ray constructs, up to the max. So, if there are only 2,
> > and you supply 20, then it's texture #2.
>
> Ah yes-- and that would have been the solution to my old argument too!
> Well-explained, laddie.
>
> > I do very much like your suggestion of the partial contribution of the cutting
object's texture to the surface.  ..
. That would be useful indeed.
>
> That can be done even now. :-) It's part of my code test.

I copied and rendered the code, since The Naughty Walker didn't attach the scene
as a .pov file.  :P

> > And truly, I think it would be as simple as adding the cutting object's
> > texture into the averaged result.
>
> Exactly.

Wait, wha...?   We agree?
To quote Phil Collins, "There must be some misunderstanding...."  ;)

- BW

Post a reply to this message