I built a model of a complicated machine. The machine consists of many
parts with different materials (for example, steel screws, copper electrodes,
ceramic insulators, glass, graphite, silicon, and so on). Thus, the parts in
the model have different textures (or pigments).

I would like to generate a cross-section of the model. Usage of "intersection"
or "difference" with a "plane" does not work well, because the texture of
the cross-section is determined by the "plane".

I thought about preparing a macro like following:

#macro X(OBJ,TEX)
  difference{
    object{OBJ}
    plane{<1,1,1>,0}  // a plane to cut the model, same texture
    texture{TEX}
  }
#end

and substituting all parts in the model with this macro. However, this does
not work because I used many "rotation"s and "translate"s to build the model.
(These "rotation"s and "translate"s are also applied to the "plane" to cut
the model).

How can I achieve my goal without modifying the model as far as possible?

Post a reply to this message

"Tomohiro" <nomail@nomail> wrote in message 
news:web.4a13ff1fd9818dbeab6e42900@news.povray.org...
>I built a model of a complicated machine.
> ...
> I would like to generate a cross-section of the model. Usage of 
> "intersection"
> or "difference" with a "plane" does not work well, because the texture of
> the cross-section is determined by the "plane".
>  ....
> How can I achieve my goal without modifying the model as far as possible?
>

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:

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
}

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.

Regards,
Chris B.

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:

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

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

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. There are probably reasons why POV-Ray can't do it (yet); but that
needs changing! After all, one of POV's BIG strengths is in its texturing
ability.

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

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.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

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

Oops, let me qualify that: The now-visible original colors are those of the
*interiors* of all the objects, not the cutaway 'surfaces' (because those
surfaces are now invisible.) So it's not as simple a situation as I described.
Oh well, I thought I was really onto something there... :-(

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.4a14dde6c981982af50167bc0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>
>> I don't think there's a perfect answer to this. There is a
>> 'cutaway_textures' keyword ...
>> 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.
>
> 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).


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

That does sound like a nice addition.


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

If you cut holes for the parts-within-parts you may be ok, but I vaguely 
recall an earlier discussion on these newsgroups about other problems with 
using cutaway_textures on large composite objects, though I don't remember 
the detail.

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. Then, 
as I build up the scene, for all objects that I add which could potentially 
be cut by the cutter I add a 'difference' operation using whatever texture I 
want for the cut surface. Subsequently you can easily alter the shape and 
position of the cutting object. This is the technique I incorporated into 
the Blockwall macros in the Object Collection for cutting window and door 
holes in the walls of a building. It gives the correct block texture and 
also significantly improves performance over cutting the holes afterwards 
because you end up with lots of small bounding boxes instead of one big one.

Another advantage of this technique is that you can be highly selective 
about the components you choose to cut. For example, you may wish to slice 
through the cylinder block of an engine, leaving the spark plugs and 
drive-chain intact. You can even use multiple cutting objects or independant 
texture definitions, for example coloring the cut surfaces of the engine red 
and the gear-box blue. Of course it's easy to incorporate this technique if 
you're just starting work on a scene, but may not be easy to apply 
retrospectively to an existing model.


Regards,
Chris B.

Post a reply to this message

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