POV-Ray : Newsgroups : povray.general : Just musing about a pattern function... Server Time: 22 Jul 2019 22:21:57 GMT
 Just musing about a pattern function... (Message 1 to 10 of 11)
 From: Bald Eagle Subject: Just musing about a pattern function... Date: 11 Mar 2019 00:30:01 Message:
```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.
```
 From: ingo Subject: Re: Just musing about a pattern function... Date: 11 Mar 2019 06:40:21 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
```
 From: Bald Eagle Subject: Re: Just musing about a pattern function... Date: 11 Mar 2019 23:00:00 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.
```
 From: Alain Subject: Re: Just musing about a pattern function... Date: 11 Mar 2019 23:07:37 Message: <5c86ea39\$1@news.povray.org>
```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.
```
 From: Bald Eagle Subject: Re: Just musing about a pattern function... Date: 11 Mar 2019 23:45:01 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
```
 From: Alain Subject: Re: Just musing about a pattern function... Date: 12 Mar 2019 14:43:31 Message: <5c87c593\$1@news.povray.org>
```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.
```
 From: Le Forgeron Subject: Re: Just musing about a pattern function... Date: 12 Mar 2019 18:16:01 Message: <5c87f761\$1@news.povray.org>
```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.
```
 From: clipka Subject: Re: Just musing about a pattern function... Date: 21 Mar 2019 18:23:55 Message: <5c93d6bb\$1@news.povray.org>
```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.
```
 From: clipka Subject: Re: Just musing about a pattern function... Date: 21 Mar 2019 18:36:11 Message: <5c93d99b\$1@news.povray.org>
```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.
```
 From: Bald Eagle Subject: Re: Just musing about a pattern function... Date: 22 Mar 2019 00:50:00 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.
```