Wasn't it Kenneth who wrote:
>"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:
>
>[snip]
>
>> If you render this in 3.6 you'll notice that it works, but of course it
>> can't know which of the two colors to use for the overlapping part, so it
>> seems to average the two colors. Whether this is of any help to you will
>> depend on which version of POV-Ray you're on and upon the specifics of your
>> CSG operations. If you've been diligent enough to avoid overlapping parts of
>> different colors then you may be ok.
>>
>
>I wasn't aware of this limitation until now.  Bummer. Just running a
>simple test of randomly-placed (though overlapping) cubes, all with
>different colors, it does indeed show some kind of 'averaging' of the
>many pigments on the cut-away surfaces.

To avoid the texture averaging, you'd need to design your object so that
all the objects with different textures are cut away separately.

So instead of writing

camera {location  <0, 1,-3> look_at <0,0,0>}
light_source {< 70, 200, -80> color rgb 0.8}
difference {
 union {
   sphere {0,1 pigment {rgb <2,0,0>}}
   box {-0.9,0.9 pigment {rgb <0,0,2>}}
 }
 plane {z,0}
 cutaway_textures
}

You'd write it like this:

camera {location  <0, 1,-3> look_at <0,0,0>}
light_source {< 70, 200, -80> color rgb 0.8}

union {
  difference{
    sphere {0,1 pigment {rgb <2,0,0>}}
    plane {z,0} cutaway_textures
  }
  difference {
    box {-0.9,0.9 pigment {rgb <0,0,2>}}
    plane {z,0} cutaway_textures
  }
}

In this test scene I didn't get coincident surface problems, but I guess
that they might arise, so you might need to change the position of the
plane slightly for each cut. Changing the position of the plane also
gives you control over which of the textures is used for the overlapping
parts.

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:

camera {location  <0, 1,-3> look_at <0,0,0>}
light_source {< 70, 200, -80> color rgb 0.8}

#declare CutAway = true;

#macro Object(ZIndex, A)
  #if (CutAway)
    difference {
      object {A}
      plane{z,ZIndex * -0.000001} cutaway_textures
    }
  #else
    object {A}
  #end
#end

union {
  Object(0, sphere {0,1 pigment {rgb <2,0,0>}})
  Object(1, box {-0.9,0.9 pigment {rgb <0,0,2>}})
}

Changing the "#declare CutAway" switches between the normal view and the
cutaway view. I've used "ZIndex*-0.000001" so that you can use nice
positive integers in the Object() calls instead of negative millionths.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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

"Chris B" <nom### [at] nomailcom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message

> > Thinking about it logically, all the colors *should*
> > be the originals, not averaged ones;
>
> I would argue that the original colors *are* shown, except where two objects
> occupy the same physical space, which is something that doesn't typically
> occur in RL solids. So I guess POV-Ray is forced to do something a bit
> 'unrealistic' to represent an unrealistic RL condition.  If you add a real
> spark plug into a cylinder block you'd normally have to cut a hole in the
> cylinder block first, unless your tool of choice is a sledgehammer (a most
> versatile tool).

Ah yes, that bit of logic escaped me while thinking about this. :-(  You're
absolutely right, a 'simple' cutaway after-the-fact isn't a real-world
situation.
>

>
> One approach I've found successful is to adopt a cookie_cutter type of
> concept, where I define a cutting object at the top of the scene file...

A very interesting idea, one I wouldn't have thought of. I'll have to try that.

In thinking further about the 'averaged' cutaway pigments (as happens now), I
do see the difficulty that POV has in determining *which* surface to choose the
color from, when multiple nested objects are cut across. It seems to me that a
way around this limitation would be: whatever individual object 'volume' the
camera ray hits at the cutaway surface, that's the color that should be
returned. The color of the 'innermost' of any nested objects there, if that
makes any sense. (And I may not be thinking *this* idea through to its logical
core.) But apparently, POV's ray-tracing process currently doesn't work on
'mathematically-created' objects this way (like a box or cylinder, etc.) I.e.,
there's no real internal 'structure' to such objects that a ray can look at at
a particular point in space. That's my simplistic way of thinking about it,
anyway! Yet, a ray *must* be seeing that point in space, in order to do simple
CSG differencing, for example.  So I'm baffled about the cause (or reasoning
behind) the 'averaged' pigments.

KW

Post a reply to this message

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

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.4a1503ebc981982af50167bc0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>> If you add a real
>> spark plug into a cylinder block you'd normally have to cut a hole in the
>> cylinder block first.
>
> It seems to me that a
> way around this limitation would be: whatever individual object 'volume' 
> the
> camera ray hits at the cutaway surface, that's the color that should be
> returned. The color of the 'innermost' of any nested objects there, if 
> that
> makes any sense. (And I may not be thinking *this* idea through to its 
> logical
> core.)

In my example I showed the union of a cube and sphere. The middle of that is 

stick out at different places (they take it in turns to be the outermost 
object), so you could say that the ray really hits both object 'volumes' at 
once.  There are parallels in the real world, particularly with liquids, or 
solids that have solidified from overlapping liquids at which point you get 
a sort of average of the two colors. So a tub of striped ice cream where 
part of the junction between two colors has melted and refrozen gives you 



> But apparently, POV's ray-tracing process currently doesn't work on
> 'mathematically-created' objects this way (like a box or cylinder, etc.) 
> I.e.,
> there's no real internal 'structure' to such objects that a ray can look 
> at at
> a particular point in space.

Some of the POV-Ray media functions can provide certain forms of internal 
'structure' with the consequent processing overhead. The less processor 
intensive options mostly handle the surfaces of the objects.

Regards,
Chris B.

Post a reply to this message

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