 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay -- we agree. It depends how one defines "bug".
But I agree POV code is not incorrect.
Dan
> :> No, it's not a bug.
> : No. It is a bug.
> No, it isn't a bug.
> It's a computer limitation, not a bug.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> Okay -- we agree. It depends how one defines "bug".
> But I agree POV code is not incorrect.
>
> Dan
>
> > :> No, it's not a bug.
> > : No. It is a bug.
> > No, it isn't a bug.
> > It's a computer limitation, not a bug.
>
> --
> http://www.flash.net/~djconnel/
Reminds me of a Monty Python skit --
Yes it is !
No it isn,t !
Yeeess it is !!
Isn't !
Is too ! ....
Now for my 2 cents worth.
We all agree it is a nuisance. And my understanding of the
ambiguity is that it occurs at a level where the decimal
places are out somewhere around 5, 6, or more places.
Fine ! Why not put a trap directive in the program
(for csg only of course) that automatically re-scales the
object so this doesn't occur.
I know some of you math geek's are squirming in your
chairs right now but the facts are you can model a molecule
in hundreds of pov units. It's all a matter of perspective.
So the program sees a situation where the csg operation
is going to have perfectly aligned surfaces. Bing ! it quite
at random laps one surface over the other say by 0.0001.
This would be enough to rid the coincident surface from
the scene and calculating whose surface, is whose, is no longer
a problem.
If there is some one out there complains that they actually
use a scaling of .0001 or less in his/her scenes then I think
they need to get a life. The human eye cannot resolve these kinds
of distances anyway and the camera would have to be almost
touching the object to see the difference anyway.
I dare to challenge your sensibilities.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Reminds me of a Monty Python skit --
> Yes it is !
> No it isn,t !
> Yeeess it is !!
> Isn't !
> Is too ! ....
>
> We all agree it is a nuisance. And my understanding of the
> ambiguity is that it occurs at a level where the decimal
> places are out somewhere around 5, 6, or more places.
> Fine ! Why not put a trap directive in the program
> (for csg only of course) that automatically re-scales the
> object so this doesn't occur.
Well, I think it logical to assume that if you have a large block of
wood (A), and cut out a smaller block of it (B), that the interior of
what remains of A would not suddenly go poof, and leave you with the
skin of A only. At least, I've never seen this happen to a wood carver.
:)
You mathematically endowed people say it's a limitation of the algebra
being using. Ok. I'll take your word for it. If so, it's not a "bug"
anymore than division by 0 is. But div by 0 can be trapped and special
cased so....
Anyway, I'm going to irritate someone working on povray if I keep
talking so I'm dropping out of this conversation. ;->
> If there is some one out there complains that they actually
> use a scaling of .0001 or less in his/her scenes then I think
> they need to get a life. The human eye cannot resolve these kinds
> of distances anyway and the camera would have to be almost
> touching the object to see the difference anyway.
Well, it does seem to break up the texture I was using noticiably when
I'm nearby. But.... that may just be a special case.
>
> I dare to challenge your sensibilities.
>
> Ken
--
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usit net (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.fourthfoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html
You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)
"The comedy is over" -i pagliacci
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 04 Oct 1998 11:34:04 -0700, Ken <tyl### [at] pacbellnet> wrote:
> So the program sees a situation where the csg operation
>is going to have perfectly aligned surfaces. Bing ! it quite
>at random laps one surface over the other say by 0.0001.
So sometimes it gets it right, and sometimes it gets it wrong. How is
this better than the current situation? It can't decide which is on
top at random, or half the time it'll end up leaving a 'skin' anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote:
> On Sun, 04 Oct 1998 11:34:04 -0700, Ken <tyl### [at] pacbellnet> wrote:
> > So the program sees a situation where the csg operation
> >is going to have perfectly aligned surfaces. Bing ! it quite
> >at random laps one surface over the other say by 0.0001.
>
> So sometimes it gets it right, and sometimes it gets it wrong. How is
> this better than the current situation? It can't decide which is on
> top at random, or half the time it'll end up leaving a 'skin' anyway.
Although I believe you should be looking at the bigger picture here
I ask that you allow me to append the above by removing the
"it quite at random" words from my previous reply and substitute with --
it then evaluates a predefined set of conditional design rules.
Once satisfied that all conditions meet the criteria it then overlaps
one surface by a given amount to eliminate the undesired condition.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: So the program sees a situation where the csg operation
: is going to have perfectly aligned surfaces.
I want to see that function, which takes any two objects and checks if
they have coincident surfaces (note that the coincidence doesn't have to
be 2-dimensional, it may occur also in a 1-dimensional line (which causes
random black dots along this line)). For example it would check if a
7th order poly object and a blob have a coincident surface... Or a lathe
object and a bezier patch... :)
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Oct 1998 10:47:53 -0500, Nieminen Mika <war### [at] assaricctutfi> wrote:
>Ken <tyl### [at] pacbellnet> wrote:
>: So the program sees a situation where the csg operation
>: is going to have perfectly aligned surfaces.
>
> I want to see that function, which takes any two objects and checks if
>they have coincident surfaces (note that the coincidence doesn't have to
>be 2-dimensional, it may occur also in a 1-dimensional line (which causes
>random black dots along this line)). For example it would check if a
>7th order poly object and a blob have a coincident surface... Or a lathe
>object and a bezier patch... :)
Well, one could argue that if the first two intersections it finds while
tracing rays are within a specified tolerance, then it should kick into
"coincident surfaces resolution mode," but it's not entirely clear what
it should do in each case. I think it would have to walk the CSG tree
and determine which operation the two objects found have in common at
the lowest level, then decide whether there's really an intersection
there or not, and if there is which surface it should intersect with.
Then, of course, it should store that decision so it always reaches
a consistent conclusion when it hits that particular pair of surfaces.
(Meaning: if it hits it from the same direction, use the same surface;
if it comes from the other direction, use the other one.)
How to decide if there's really an intersection there? If the common
operation is intersection, should we throw the intersection away or
keep it? I think this depends on whether we're entering both objects,
leaving both objects, or entering one and leaving another. In the
first two cases, keep it. In the last case, throw it away. For
union, always keep it. For merge, keep it using the same criteria
as for intersection. Difference, of course, does not exist as a CSG
type, but the proposed intersection rules seem to do the right thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] my-dejanewscom> wrote:
: How to decide if there's really an intersection there? If the common
: operation is intersection, should we throw the intersection away or
: keep it? I think this depends on whether we're entering both objects,
: leaving both objects, or entering one and leaving another. In the
: first two cases, keep it. In the last case, throw it away. For
: union, always keep it. For merge, keep it using the same criteria
: as for intersection. Difference, of course, does not exist as a CSG
: type, but the proposed intersection rules seem to do the right thing.
Note that the coincident surfaces problem (this is a so used term it should
be abbreviated CSP :) ) can also occur with objects not in the same CSG.
Also note that a very special case of CSP occurs when a light source is
exactly on a surface: Povray can't calculate accurately if the light source
is inside or outside the surface, so black spots will appear in every
place which is illuminated by this light.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
> Note that the coincident surfaces problem (this is a so used term it should
> be abbreviated CSP :) ) can also occur with objects not in the same CSG.
> Also note that a very special case of CSP occurs when a light source is
> exactly on a surface: Povray can't calculate accurately if the light source
> is inside or outside the surface, so black spots will appear in every
> place which is illuminated by this light.
>
> --
> - Warp. -
It can also appear if you have two flat surfaces abutting each other
but otherwise having nothing in common. I have seen it recently when
another pov user asked why one of the example scene files included
with pov, had black artifacts. It was a box resting on a plane and the
coincident surface occurred between them.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Oct 1998 11:14:19 -0500, Nieminen Mika <war### [at] assaricctutfi> wrote:
> Note that the coincident surfaces problem (this is a so used term it should
>be abbreviated CSP :) ) can also occur with objects not in the same CSG.
In this case, treat it as if their common ancestor were a union, since
adding a union around the whole frame should have no net effect.
> Also note that a very special case of CSP occurs when a light source is
>exactly on a surface: Povray can't calculate accurately if the light source
>is inside or outside the surface, so black spots will appear in every
>place which is illuminated by this light.
Well, one could see that the light source and one of the intersections
coincide within the same tolerance while looking for shadow rays. In
this case, one would always discard the intersection.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
