 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The following text is from a thread that stared in the images
group and I felt it would be better disscussed here rather than
there. It contains the original posters text in full along with
my reply to his query.
After going through the text below I would like to hear your
opinion.
Is it A, B, C, or D or ?
A. A Bug
B. A predictable by product of coincident surfaces
C. An unpredictable problem that one could easil expect
under these operating conditions
D. combinations of the previous three options
?.
=================================
Anton Sherwood wrote:
>
> We all know that you shouldn't let the two objects in difference{} have a
> plane in common, because the algorithm can't decide which of the two is "on
> top" as it were.
>
> But what about intersections? Even if the algorithm can't decide between the
> two planes, it ought to find one or the other to be "inside", and respond to
> that one.
>
> intersection {
> cylinder { <-1,-1,0>, <-1,1,0>, 2
> pigment { color Red }
> normal { wrinkles scale 1/16 }
> }
> cylinder { <1,-1,0>, <1,1,0>, 2
> pigment { color Green }
> normal { leopard scale 1/16}
> }
> }
>
> I'd be happy if the top of the object were red, green, yellow, or blotchy of
> both colors. (The first time I spotted this bug, the object had one texture
> all over, anyway.) Instead, the object has no top at all.
>
> Is this bug well known?
I replied with the following comments and wisdom:
It is weird whatever it is and it just keeps getting stranger.
I am sure it has something to do with the intersection testing but
without the aid of a programmers background and a copy of the source
code I can't say specificaly what it may be. The coincident surface
problem has been so well documented I doubt anyone but a 3 month old
newbie has not heard about or experienced it for himself. It's just
that your example takes it to a new extreme.
I'll post this message with your comments intact in the programming
group and see if Ron of someone else can offer any insight into this
oddity.
Try this for even more fun with your strange behavior.
Using the following code rendered each steps in the order I dictate below.
Observe the changes the overlapping pigments go through as each parameter
is modified.
Leave the object statment untouched and change only the lights and
global settings parameters.
========================
/* Render w/light inside the objects - observe overlapping illumination */
light_source { < 0, 0, -3> rgb 1 }
/* Uncomment the global settings and render again. Note how neither of
the two pigments have dominance over the other */
// global_settings { max_intersections 2 }
/* Now try it with this global statement and witness the change */
// global_settings { max_intersections 4 }
/* Now try the previous two again with this lightsource included and
observe the chages in appearence. */
//light_source { < 0, 0,-25> rgb 1 }
/* Also if you reverse the position of the two objects when the
max_intersections setting is above 4 or more the object on the right
always has priority over the object on the left as to which pigment
will be on top of the other. */
camera {location<0,0,-6.5>look_at<0,0,0>}
union {
cylinder { <1,-1,0>, <1,1,0>, 2
pigment { red 1 }
normal {bozo scale 1/16 }// wrinkles scale 1/16 }
}
cylinder { <-1,-1,0>, <-1,1,0>, 2
pigment { color green 1 }
normal { leopard scale 1/16}
}
scale .35 rotate 90*-x translate<0,.25,-3>}
=======================
The obvious fix for this problem is to simply scale one cylinder
slightly longer than the other and it will all go away. It is even
mentioned in the docs that this is an acceptable practice so don't
feel like you are cheating when you are forced to do so. If you are
expecting some other result from your current object placement and
csg type used then you are probably applying it wrong and should be
applying it differently or try using a different csg intersection type.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 May 1999 00:27:15 -0700, Ken wrote:
>Is it A, B, C, or D or ?
>
>A. A Bug
>B. A predictable by product of coincident surfaces
>C. An unpredictable problem that one could easil expect
> under these operating conditions
>D. combinations of the previous three options
I'd call it B, with a smattering of C.
>> We all know that you shouldn't let the two objects in difference{} have a
>> plane in common, because the algorithm can't decide which of the two is "on
>> top" as it were.
>>
>> But what about intersections? Even if the algorithm can't decide between the
>> two planes, it ought to find one or the other to be "inside", and respond to
>> that one.
Why should it? If a point is on the surface of an object, is it inside or
outside? Also, keep in mind that there is no difference between difference
and intersection. The internal implementation of
difference {object {A} object {B}}
is
intersection {object {A} object {B inverse}}
Here's what the CSG-intersection algorithm does: First, it finds all
intersections[1] of your ray with the object in question. Next, it tests
the intersections in the order in which they were encountered, looking for
one that is inside every sub-object in the CSG except the one that was hit.
If this doesn't hold for the first intersection, it goes to the next, and
so on.
So let us look at the case in question. The ray hits both planes at the same
point. The sorting algorithm sorts one intersection in front of the other,
in a predictable but seemingly random way. Note that if cylinder A sorts
ahead of cylinder B this time, they will likely sort the same way every time,
regardless of which direction the ray is coming from. The first intersection
that is found may or may not be "inside" the other plane, due to numerical
inaccuracies. If it is, it is kept. If not, it's thrown away and the other
intersection tested. If the two planes have identical equations, the result
of testing the other intersection will be identical to the first one. So
either the first intersection works, or neither one works. If the first one
works, you get a pixel colored like the first object. If neither works, you
go right through that face as if it didn't exist. The result is a speckly
surface where you expected something else. If you're really lucky, the
numerical inaccuracies may all go in your favor, leaving you with either a
solid surface or a transparent one. If you're extremely lucky, this will be
the result you expected. :)
[1] intersection here does not mean CSG intersection. It means "the place
where a ray hits an object."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
