Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > The docs do clearly explain this--but that explanation seems to me to be rather
> > ad hoc, describing a situation that may not have been what the code creator
> > originally had in mind.
>
>   I don't really understand what you are talking about.

Oh, come on.

> The averaging is
> exactly what the implementor wanted, because it was discussed in length
> before the feature was implemented.
>
>   Being able to cut parts of a CSG while retaining the original colors was
> a wanted feature for a long time. The real problem was precisely what should
> be done with overlapping parts: Choosing one of the objects for the coloring
> of the overlapping part and discarding the others would just be wrong. How
> exactly and *why* would POV-Ray choose a certain object and discard the
> others? Averaging all the colors is a clever solution: All the overlapping
> objects contribute to the shared part.

Sorry, but that just makes no sense to me. Why would we want AVERAGED colors?
Sure, it's a 'clever solution'--but to a problem that shouldn't be there. (And
no, I don't have any coding solution to the problem; I'm not a programmer.) Yet
solutions have been found, AFAIK--otherwise, how do other CGI programs
accomplish exactly this feature?
>
>   It's not like the averaging would have been an unintended, surprising
> consequence. That's programmatically absurd.

Really? With all the current problems of 'intentionally-coded' transparency, for
example?
>

>   And exactly which one of the overlapping objects should be chosen as the
> color contributor for the overlapping area?

I *think* I gave a good (though perhaps naive) solution to that--using the
'volume' of the innermost nested object to choose the color from. Yet, again I
have to say that I'm not a programmer, so I don't even know if that's possible.
(Don't fault me for not being the Stephen Hawking of computational science, I
just *use* POV-Ray.)
>

>
> > I can think of another nice addition: As-is, the 'cutting' object can't
> > have a texture (otherwise it fully shows up on all the cutaway surfaces.)
> > Instead, it
> > would be nice to have a method of variably 'blending' the cutting object's
> > pigment with all of the other objects' pigments. An example would be the
> > cutting object having a color of rgb 1, then blending that with all the
> > different objects' colors to get pastel shades on the cutaway surfaces.
>
>   I'm not exactly sure how that's different from the averaging solution.

Well, the averaging of colors as-is seems to be a combination of the objects
that are nested. My idea would impose the CUTTING object's pigment on them all
(in a variable way.)
>
> > I was hoping--at some point--to start working on a 'cutaway' automobile
> > engine in POV-Ray. LOTS of parts-within-parts.  But the current
> > cutaway_texture limitation is a big one.
>
>   What limitation? I really can't understand what you are talking about.

OK, I'll try again: The colors of all the parts would (currently) be averaged
colors, not the 'actual' colors of the parts. The whole point of the argument.

>   It's not a limitation: It's a *solution* to a problem. And a good one
> at that. Can you provide a better solution?

Geez, I'm beginning to think that YOU came up with the current cutaway_textures
idea, and that I'm infringing on your personal domain. Don't take it so
personally. The idea of getting the *actual* colors of cutaway parts is a GOOD
one, an OBVIOUS one. Should we all just sit back and accept that the present
'solution' is all we can get?


>   Are you sure you are not confusing cutaway_textures with clipped_by?

Yes, I'm sure.

Ken W.

Post a reply to this message