So, I was wondering if it were possible to define a pattern that depends on if
the surface of one object is coincident with another.

object A, Object B, and an overlapping surface.

I was thinking about it initially from the perspective of ease-of-use in
highlighting imperfections in CSG / math,

pigment {overlap {_textureA, _textureB, _textureOverlap}}

but then it occurred to me that if this were possible, then

pigment {overlap {_textureA, _textureB, _textureB}}

would take care of a lot of coincident surface problems.



Just brainstorming and wondered if this might spark some ideas.

Post a reply to this message

in news:web.5c85aaecd4241a93765e06870@news.povray.org Bald Eagle wrote:

 
> Just brainstorming and wondered if this might spark some ideas.

Use the trace function in a pigment and multiply the colour by the 
distance result of trace,

ingo

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:

> Use the trace function in a pigment and multiply the colour by the
> distance result of trace,

That would give a distance based color for either of the objects.

I could probably multiply the normal vector results by each other and use a
select() function to work something out, but I think CSG'ing everything into
difference B from A
difference A from B
and intersect A and B
would be far simpler (in SDL)

Perhaps there's a way using a union / merge and the object pattern.

Post a reply to this message

Le 19-03-10 à 20:25, Bald Eagle a écrit :
> So, I was wondering if it were possible to define a pattern that depends on if
> the surface of one object is coincident with another.
> 
> object A, Object B, and an overlapping surface.
> 
> I was thinking about it initially from the perspective of ease-of-use in
> highlighting imperfections in CSG / math,
> 
> pigment {overlap {_textureA, _textureB, _textureOverlap}}
> 
> but then it occurred to me that if this were possible, then
> 
> pigment {overlap {_textureA, _textureB, _textureB}}
> 
> would take care of a lot of coincident surface problems.
> 
> 
> 
> Just brainstorming and wondered if this might spark some ideas.
> 
> 

The main problem with coincident surfaces is that you can't reliably 
tell if two surfaces are coincident or not while rendering. On one test, 
the surface of object A seems to be in front of the surface of object B, 
then, on the next test, it seems to be behind.

The only cases when it don't cause problem is if all surfaces are opaque 
and share the same texture.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> Le 19-03-10 à 20:25, Bald Eagle a écrit :
> > So, I was wondering if it were possible to define a pattern that depends on if
> > the surface of one object is coincident with another.
> >
> > object A, Object B, and an overlapping surface.
> >
> > I was thinking about it initially from the perspective of ease-of-use in
> > highlighting imperfections in CSG / math,
> >
> > pigment {overlap {_textureA, _textureB, _textureOverlap}}
> >
> > but then it occurred to me that if this were possible, then
> >
> > pigment {overlap {_textureA, _textureB, _textureB}}
> >
> > would take care of a lot of coincident surface problems.
> >
> >
> >
> > Just brainstorming and wondered if this might spark some ideas.
> >
> >
>
> The main problem with coincident surfaces is that you can't reliably
> tell if two surfaces are coincident or not while rendering. On one test,
> the surface of object A seems to be in front of the surface of object B,
> then, on the next test, it seems to be behind.
>
> The only cases when it don't cause problem is if all surfaces are opaque
> and share the same texture.

Well, yes.
But the problem is that POV-Ray is trying to numerically compare the distance of
two surfaces from the camera, and it doesn't know which surface is _supposed to_
be in front.

My thought was that if you could specify that - yes, ObjectB is definitely the
one that's definitely in front,
by using
texture {pigment {overlap {_textureA, _textureB, _textureB}}}
Then the iffy-z-fighting speckled or other weird result would be overridden by
making that portion of the occluded object automatically the same texture.

I think that trying to implement it in SDL might give rise to people doing
experiments that may lead to some interesting findings - usually by unexpected
results or mistaken understanding or other anomalies   ;)

It's also just an interesting thing to do because it forces you to try to get
your head into how POV-Ray processes the ray-object intersection tests.
Especially when using transmit and/or filter.

It just popped into my head before I even made it out of bed, so I thought I'd
just bring it up.

I'll probably wind up breaking POV-Ray again.  :D

Post a reply to this message

Le 19-03-11 à 19:43, Bald Eagle a écrit :
> Alain <kua### [at] videotronca> wrote:
>> Le 19-03-10 à 20:25, Bald Eagle a écrit :
>>> So, I was wondering if it were possible to define a pattern that depends on if
>>> the surface of one object is coincident with another.
>>>
>>> object A, Object B, and an overlapping surface.
>>>
>>> I was thinking about it initially from the perspective of ease-of-use in
>>> highlighting imperfections in CSG / math,
>>>
>>> pigment {overlap {_textureA, _textureB, _textureOverlap}}
>>>
>>> but then it occurred to me that if this were possible, then
>>>
>>> pigment {overlap {_textureA, _textureB, _textureB}}
>>>
>>> would take care of a lot of coincident surface problems.
>>>
>>>
>>>
>>> Just brainstorming and wondered if this might spark some ideas.
>>>
>>>
>>
>> The main problem with coincident surfaces is that you can't reliably
>> tell if two surfaces are coincident or not while rendering. On one test,
>> the surface of object A seems to be in front of the surface of object B,
>> then, on the next test, it seems to be behind.
>>
>> The only cases when it don't cause problem is if all surfaces are opaque
>> and share the same texture.
> 
> Well, yes.
> But the problem is that POV-Ray is trying to numerically compare the distance of
> two surfaces from the camera, and it doesn't know which surface is _supposed to_
> be in front.
> 
> My thought was that if you could specify that - yes, ObjectB is definitely the
> one that's definitely in front,
> by using
> texture {pigment {overlap {_textureA, _textureB, _textureB}}}
> Then the iffy-z-fighting speckled or other weird result would be overridden by
> making that portion of the occluded object automatically the same texture.
> 
> I think that trying to implement it in SDL might give rise to people doing
> experiments that may lead to some interesting findings - usually by unexpected
> results or mistaken understanding or other anomalies   ;)
> 
> It's also just an interesting thing to do because it forces you to try to get
> your head into how POV-Ray processes the ray-object intersection tests.
> Especially when using transmit and/or filter.
> 
> It just popped into my head before I even made it out of bed, so I thought I'd
> just bring it up.
> 
> I'll probably wind up breaking POV-Ray again.  :D
> 
> 
> 

In that case, having an object attribute specifying that there are 
expected coincident surfaces could be the way to go.

union{.... have_coincident on}
union{.... coincident on}

I think that making it an object feature rather than a texture feature 
may be better.

Post a reply to this message

Le 11/03/2019 à 01:25, Bald Eagle a écrit :
> So, I was wondering if it were possible to define a pattern that depends on if
> the surface of one object is coincident with another.
> 
> object A, Object B, and an overlapping surface.
> 
> I was thinking about it initially from the perspective of ease-of-use in
> highlighting imperfections in CSG / math,
> 
> pigment {overlap {_textureA, _textureB, _textureOverlap}}
> 
> but then it occurred to me that if this were possible, then
> 
> pigment {overlap {_textureA, _textureB, _textureB}}
> 
> would take care of a lot of coincident surface problems.
> 
> 
> 
> Just brainstorming and wondered if this might spark some ideas.
> 
> 

what would be the difference with the object pattern applied with B, on A ?

object{ A texture{ pigment{ object { B PigmentOut PigmentIn } } }

or/and vice versa.

Unless you want something like:

union{
object {A}
object {B}
texture { pigment { overlap { A B PigmentA PigmentB PigmentAB } } }
}

from coding point of view, the intersection would refer one of the
object, and the point would need to be tested against the other for
insideness to choose which alternative to take (A or AB when A is hit, B
or AB when B is hit)

Can it be extended to more than two objects ?

Can the syntax be different and easier ?

would a proximity-like pattern be more precise ? (similar to object
pattern, but with a tolerance radius to detect the other shape)
(beware, proximity costs a hell to compute, even if this version could
short-cut as soon as a point is found inside the shape)

Normal texture on one shape, overlap texture on the other shape but
referencing the first shape.

Post a reply to this message

Am 11.03.2019 um 01:25 schrieb Bald Eagle:
> So, I was wondering if it were possible to define a pattern that depends on if
> the surface of one object is coincident with another.
> 
> object A, Object B, and an overlapping surface.
> 
> I was thinking about it initially from the perspective of ease-of-use in
> highlighting imperfections in CSG / math,

This is certainly an intriguing idea; but at a closer look it suffers 
from a big fallacy:

Coincident surface problems do /not/ arise from surfaces being 
coincident /per se/.

The true root cause of coincident surface problems is that two 
independent tests may disagree whether two surfaces are coincident or not.

By introducing a coincidence-sensitive pattern, you'd only add yet 
another test to the mix; and while it could certainly be used to solve 
some of the issues, it would inevitably open up other cases where it 
would break down itself.

Post a reply to this message

Am 12.03.2019 um 00:43 schrieb Bald Eagle:

> But the problem is that POV-Ray is trying to numerically compare the distance of
> two surfaces from the camera, and it doesn't know which surface is _supposed to_
> be in front.

Nah, that's just the easiest category of coincident surface problems. 
Sometimes one surface will win, sometimes the other, and you'll probably 
get a speckled surface. With high enough anti-aliasing settings, you may 
even get a neat averaged colour.

That's boring. The real coincident surface problems only start after that.

Because then POV-Ray has to shoot secondary rays (for shadow tests, or 
reflections and/or refractions depending on material), and decide 
whether or not to consider that other surface for this purpose: Is it 
/genuinely/ coincident or just extremely close?

That's where the true can of worms is opened.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Because then POV-Ray has to shoot secondary rays (for shadow tests, or
> reflections and/or refractions depending on material), and decide
> whether or not to consider that other surface for this purpose: Is it
> /genuinely/ coincident or just extremely close?
>
> That's where the true can of worms is opened.

Well, yes, I didn't think that there wouldn't be a string of complications in
the ideal implementation - but a simple "if a ray from the camera intersects
only one object then assign the designated material, if it intersects both
objects, then assign the designated third material (which may be the same as
either of the previous)" would at least be useful for highlighting some overlaps
in CSG, and could give rise to some hard-to-envision effects that might make a
useful artistic tool.

And I suppose that part of the implementation could be an option Epsilon value
to override the usual 1E-06 distance...

Like I said, it was just something that popped into the noggin before I even
really woke up.

Post a reply to this message