"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

clipka <nomail@nomail> wrote:
> So why ask, and not just simply make that point.

  Because he is insising that the problem must be fixed. I'm asking how it
should be fixed.

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:

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

I couldn't have stated the situation better myself. ;-)

The spirit of my earlier statements/questions/replies was honestly one of,"Hey,
let's put our heads together and see if we might be able to solve this!"
Nothing more was intended. But the general idea became, "Solve what?? What
problem??" Argumentation ensued. Reminds me of the story of the 'Emperor with
no clothes'--the Emperor stands there naked, thinking that he's fully clothed,
while others look and scratch their heads, wondering why he doesn't realize
that there might be a...problem. I'm sure he argued the point...

Can the current cutaway_textures 'situation' be 're-worked'?  (Notice the
less-inflammatory language.) Beats me!! Doesn't sound like it can; and I
understand why. Well, I *mostly* understand, anyway...

KW

Post a reply to this message

"clipka" <nomail@nomail> wrote:

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

Yeah, I guess that's what I meant by my (vaguely-stated) idea concerning the
'innermost' object.
>
> 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...

Yes yes; and I will be gentle.  ;-)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Can the current cutaway_textures 'situation' be 're-worked'?  (Notice the
> less-inflammatory language.) Beats me!! Doesn't sound like it can; and I
> understand why. Well, I *mostly* understand, anyway...

As I explained earlier, from all I can imagine there's nothing that can be done
about it.

Not unless we're providing the user with a way to add some hints about which of
the intersecting objects should "win" over the other.

It might be worth putting that on the to-do list, but I don't expect to see it
anytime soon.

Post a reply to this message

Kenneth nous illumina en ce 2009-05-21 17:56 -->
> "clipka" <nomail@nomail> wrote:
>> Warp <war### [at] tagpovrayorg> wrote:
> 
>>>   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.
>>
> 
> I couldn't have stated the situation better myself. ;-)
> 
> The spirit of my earlier statements/questions/replies was honestly one of,"Hey,
> let's put our heads together and see if we might be able to solve this!"
> Nothing more was intended. But the general idea became, "Solve what?? What
> problem??" Argumentation ensued. Reminds me of the story of the 'Emperor with
> no clothes'--the Emperor stands there naked, thinking that he's fully clothed,
> while others look and scratch their heads, wondering why he doesn't realize
> that there might be a...problem. I'm sure he argued the point...
> 
> Can the current cutaway_textures 'situation' be 're-worked'?  (Notice the
> less-inflammatory language.) Beats me!! Doesn't sound like it can; and I
> understand why. Well, I *mostly* understand, anyway...
> 
> KW
> 
> 
> 
"re-worked"? How?

Whenever 2 or more objects with different texture are overlaping, you need to 
decide what texture to show.
There are NO way that you can predict what texture to use if you are to only 
show one. In two almost identical cases, you may want one texture or the other 
to show. Or, the algorythm used may show one texture, then the other after a 
slight rotation or translation of the whole object. Sometimes, a slight change 
in the composition of the object, like moving or rotating a component, will 
cause a switch of the texture used. Add a third object, and the situation will 
get even more complex.

You suggested to take "the innermost", but that innermost may not be obvious. It 
can only be "obvious", and even then, not always, if, and ONLY if, it's the 
texture of an object that is totaly enclosed into another one.

If you don't want the textures to be averaged, you can always cut a hole into 
one object to make room for the other.
You do that by deffining one of the objects beforehand, then use a difference to 
remove it before you use the union to add it. This will create a perfectly 
shaped hole, and there will be no overlaping.

Alain

Post a reply to this message