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. 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.

  It's not like the averaging would have been an unintended, surprising
consequence. That's programmatically absurd. It had to be specifically
programmed to do that.

> (Thinking about it logically, all the colors *should*
> be the originals, not averaged ones; that would be a *true* implementation of
> 'cutaway_textures.')

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

> I think this issue needs to be addressed in a future version of POV-Ray. As-is,
> the cutaway_textures algorithm makes it rather impossible to create
> accurately-colored cutaway objects--a problem which doesn't exist in many other
> CGI programs.

  You will have to first explain the exact algorithm by which one of the
overlapping objects is chosen over the others, and the reasoning for the
choice.

  For example, if you have a red sphere and a green sphere of the same size
in a union, and they partially overlap, and then you cut this union so that
the overlapping area becomes visible, what should be color of this area?
Red or green? Why? Why would one choice be more correct than the other?
What if the user wanted the other choice? Or what if he really wants the
overlapping area to be averaged?

> There are probably reasons why POV-Ray can't do it (yet); but that
> needs changing!

  And how, exactly?

> 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.

> 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.

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

> Something interesting: I just did a further test, with the cutting object having
> a transparent pigment--rgbt <1,1,1,1>--and the result is that you can see into
> each cutaway object.  Nice and weird. But the *really* interesting thing is
> that the many objects' colors are NOT averaged now, but are the originals!
> Which leads me to believe that the current 'averaging' of colors may simply be
> a fixable bug of some kind.

  Are you sure you are not confusing cutaway_textures with clipped_by?

-- 
                                                          - Warp

Post a reply to this message