Warp <war### [at] tagpovrayorg> wrote:


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

I do see the logical conundrum in this example. Taken on it's face, it would
seem to be an insurmountable one--possibly even getting to the 'core' of
logical computation and thought. What could possibly be a 'solution' (or more
likely, a workaround/kludge) to such a situation? It would seem to me that the
best minds in computer-graphics science *must* have given this a great deal of
thought by now (if not an answer.) Yet, it also seems to me that some kind of
practical solution could be arrived at--in POV-Ray--by taking a 'logical
short-cut.'  For example, similar (but only in general concept) to the way POV
handles interior_texture in a semi-transparent object: If you give the object
interior_texture{pigment{rgbt 1}}, the 'back-face' disappears, IIRC. Yet if you
rotate the object around, that invisible back face 'changes its position', to
always be in line with the camera. This strikes me as an acceptable workaround
to another possible problem with logic, although that's just a guess.

The general idea being that a 'non-logical' workwaround might be found in some
way, perhaps not ideal but acceptable. And yes, following my own reasoning I
can agree that the CURRENT 'solution' to the cutaway_textures problem is a
similarly acceptable one.  For now. ;-)

KW

Post a reply to this message

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

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:

> > 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...
>
>   So, how would you like for it to be colored?
>
> ..It's a question of you telling what
> color you want there to be in the overlapping part. You haven't told us that.
>
Hmm, seems that we're communicating from different universes, in different
languages. Methinks that you should re-read this entire post; my requests are
plain to see (if possibly unattainable.) I sense that you're trying to present
some kind of obtuse 'logical' argument in response to those--based (so it
seems) on the single idea of 'What color *should* appear at a surface when
there's no logical answer?' rather than any practical solution or argument to a
practical question. So be it. (I *do* understand the logical problem of which
color POV-Ray should choose at a surface; however, you seem to have latched
onto that as your one-and-only argument to pursue here, sidestepping just about
everything else that I've tried to ask or explain. That's rather...odd, IMO.) I
have no answer to your argument; debating deep questions of logic I will leave
to others.

KW

Post a reply to this message

Mike Williams <nos### [at] econymdemoncouk> wrote:

> To avoid the texture averaging, you'd need to design your object so that
> all the objects with different textures are cut away separately.
[snip]
>
> That removes the convenience of being able to create the whole engine
> and then add the cut away effect afterwards. You can get some of the
> convenience back by creating a macro to control the cut, like this...

Both ideas are very clever and useful; thanks, Mike! My cutaway car engine may
not be so far off in the future after all!

KW

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:

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

Sorry, I may not have explained that well: This feature would be used in
conjunction with the 'new' or improved cutaway_textures idea, the
'non-averaged-colors' one. The cutaway_textures method we have now wouldn't
really benefit from it (in the same way), as you point out.

KW

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> I don't think there's a perfect answer to this. There is a
> 'cutaway_textures' keyword that works with 'difference' and 'intersection'
> CSG operations, but it's a long way from perfect and seems to be broken in
> the 3.7 Beta 32. On the other hand it does work largely as documented on
> POV-Ray 3.6, so it may help. Here's a very trivial test scene:

Thank you very much, it worked well for me.

Post a reply to this message

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

Well, in a sense, it *is* the 'actual' color of *all* the parts, isn't it?

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

The problem with this strikingly obvious idea is that it ignores one strikingly
non-obvious problem:

Which one would be *the* part to take the color from?


"The innermost", you might say.

Now, if you have a solid motor block with spark plugs (forced in with a sledge
hammer, to save the work of drilling holes :P), partially sticking out of the
solid metal block both into the combustion chamber (you drilled a hole for
*that*, didn't you? :D) and outside (to fit the wires to)...

.... which hint do you have for POV-Ray that the spark plugs are meant to take
precedence over the motor block??

Even in the best of all worlds, POV-Ray could only see two objects partially
overlapping. It could judge from the relative size of the objects, or the order
in which the objects were created, but that's all. It does not have any
*reliable* way of finding out which object *you* intended to be the "inserted"
one.


With some partial code redesign, it might be possible to pick the texture of the
object that would have been the last one encountered along the ray if it wasn't
partially cut away. However, you'd be in for some surprise: The cut surface of
the spark plug would be textured *partly* as you'd expect, but *partly* like
the motor block! The wrongly-colored areas would be those which in an "uncut"
shot would show the spark plugs sticking out of the motor block.

I'm perfectly sure this is *not* exactly what you want.

Averaging all objects' texture may not be what you'd expect, but it has the
advantage of at least giving *some* consistent texturing, and not being
influenced by the actual shape of parts you can't even see because they're cut
away.


Professional CAD software avoids the whole issue by not allowing you to insert
those spark plugs with the sledge hammer in the first place, but be a good boy
and drill holes into the motor block first: No overlapping objects here, so no
problem to choose the proper texture.

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Hmm, seems that we're communicating from different universes, in different
> languages. Methinks that you should re-read this entire post; my requests are
> plain to see (if possibly unattainable.) I sense that you're trying to present
> some kind of obtuse 'logical' argument in response to those--based (so it
> seems) on the single idea of 'What color *should* appear at a surface when
> there's no logical answer?' rather than any practical solution or argument to a
> practical question. So be it. (I *do* understand the logical problem of which
> color POV-Ray should choose at a surface; however, you seem to have latched
> onto that as your one-and-only argument to pursue here, sidestepping just about
> everything else that I've tried to ask or explain. That's rather...odd, IMO.) I
> have no answer to your argument; debating deep questions of logic I will leave
> to others.

  You seem to think for some reason that I'm arguing just for the sake of
argument. That's not the case.

  I'm directly asking you: In the case of overlapping objects, which color
should be shown in the overlapping part?

  You have *not* answered this question in any way. The only thing you have
said is that showing the average of the objects is "wrong" and that this
"problem" should be fixed, without specifying exactly how it should be
fixed.

  Why is it so difficult to give a simple and straightforward answer to
a simple and straightforward question?

-- 
                                                          - Warp

Post a reply to this message

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

> Sorry, I may not have explained that well: This feature would be used in
> conjunction with the 'new' or improved cutaway_textures idea, the
> 'non-averaged-colors' one. The cutaway_textures method we have now wouldn't
> really benefit from it (in the same way), as you point out.

  "This feature"? What feature? You haven't explained anything concrete.
I can't understand what is it that you want.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   You seem to think for some reason that I'm arguing just for the sake of
> argument. That's not the case.
>
>   I'm directly asking you: In the case of overlapping objects, which color
> should be shown in the overlapping part?

Well, why are you asking anyway?

It's a rhethorical question from all I see, as there is no sensible answer to it
(aside from the current averaging approach), which seems to be the point you're
trying to make.

So why ask, and not just simply make that point.

(Some ancient greek philosopher or another kept pissing off people with that
nagging-question style of discussion so much that their fellow citizens
ultimately made them drink poison to have them STFU :P)

Post a reply to this message