Kenneth <kdw### [at] earthlinknet> wrote:
> >   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?

  Then what is it that you want? You haven't explained that. You have only
said that the current solution is "wrong", but you haven't explained what
the "right" solution would be. You just want the "right" solution, but you
haven't told us what it is. What is it that you want, exactly?

> Sure, it's a 'clever solution'--but to a problem that shouldn't be there.

  Maybe you wouldn't want the problem to be there, but we just can't get
around the fact that it is: Differently-textured objects can overlap, and
if the overlapping part becomes visible due to CSG, it has to be colored
with *something*. That is the problem, and it's a very real problem.

  So, how would you like for it to be colored?

> (And
> no, I don't have any coding solution to the problem; I'm not a programmer.)

  It's not a question of programming. It's a question of you telling what
color you want there to be in the overlapping part. You haven't told us that.

> Yet
> solutions have been found, AFAIK--otherwise, how do other CGI programs
> accomplish exactly this feature?

  Please explain it to us, so that we can understand.

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

  I don't even understand what that means.

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

  And exactly why would this be the "correct" solution, or the one the user
wants? What if the user wants the overlapping part to be colored using the
texture of the smaller object? What if the overlapping objects are identical?

  And no, "let the user specify which object should be used" is not a working
solution because you then end up having more than one overlapping object with
the keyword in question, and the same problem happens.

  (Sure, in this case an error could be raised, but is that really what you
want? What if you can't affect the existence of the keyword in an object
you are including in your CSG, eg. because it's a declared object?)

> > > 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 don't understand why adding the color of the cutting object to the mix
would make the result any better. It sounds that it would only make it worse.

  And no, it's not possible to color the overlapping part in a variable
manner because it's not possible to calculate the distance from a point
to the surface of an object (not in an accurate and efficient way). That
would be like a proximity pattern, which is a difficult problem.

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

  No, I didn't. But when the developer who came up with the solution presented
it, I thought it was a good idea. It nicely solves the problem of overlapping
objects.

> Don't take it so
> personally. The idea of getting the *actual* colors of cutaway parts is a GOOD
> one, an OBVIOUS one.

  You have still not told us exactly how the overlapping part should be
colored.

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

> Yes, I'm sure.

  I wouldn't be so sure. Your description sounded like you were actually
emulating clipped_by using a transparent cutting object, after which you
started seeing the inside of the objects. Perhaps you got confused because
of your camera angle and lighting, and thought that it looked good? However,
if you are indeed looking at the inner surfaces of the objects through a
cut, it just won't work from all angles and possible lighting.

-- 
                                                          - Warp

Post a reply to this message