POV-Ray : Newsgroups : povray.programming : Coincidence issue.. Server Time
28 Jun 2024 02:03:22 EDT (-0400)
  Coincidence issue.. (Message 1 to 3 of 3)  
From: Patrick Elliott
Subject: Coincidence issue..
Date: 18 Aug 2004 16:00:21
Message: <MPG.1b8c2722aa0cd162989b13@news.povray.org>
I had a thought. And yes, this may slow the engine, but for some 
applications it may be a lot more accurate. Things we know, or should 
know:

1. Direction of the ray.
2. The 'object' that a point the ray hits belongs to.
3. Where in 3D space that 'should' place the surfaces in relation to each 
other.

What is needed is to identify which object when hit is 'behind' the ray 
at the point of intersection. If you know that you are leaving object X, 
but the point you hit, due to precision issues, is on Y, then obviously 
those calculations need to be delayed in cases where you will also hit X 
at roughly the same exact point. It would seem to me that the odds of two 
objects being so close together that they don't coincide, but numerical 
precision makes them seem to, is much less often than intentional direct 
contact between surfaces. If you know that they should occupy the same 
apparent space and that one must mathematically appear prior to the 
other, there should be some way to figure out which is which and act 
accordingly, right? Even if this double checking could only be turned on 
manually in certain CSG where you 'know' such a check is needed it would 
help.

Then again, I don't have a clue about the internal mechanics, so maybe I 
am missing something obvious.. It is definitely not something I could 
code and test for myself.. :( And yeah, I know how you get around it, I 
just think a better way has to be possible.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

From: JWV
Subject: Re: Coincidence issue..
Date: 19 Aug 2004 11:21:34
Message: <4124c57e$1@news.povray.org>
Hi,

Just as Patrick, i don't know all the details of the way povray works, but
i'll try to explain a way to get the effect Patrick means.

- When making the scene one should be able to make some objects "master"
objects, like this:

box{0,1 master}

during the render, when a ray hits an object, the program should check
wether there is an other object nearby (say within a radius of 0.0001).
When there is one, and it's a master object, the ray should pretend to be
hitting the master object. This way one could easely avoid coincident
surfaces.

The drawback will be -as usual- speed, especialy the checking for nearby
objects.

No idea wether it is possible, usefull etc. But this is what i came up with
while reading Patricks post.

Greetings

JWV


"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1b8c2722aa0cd162989b13@news.povray.org...
> I had a thought. And yes, this may slow the engine, but for some
> applications it may be a lot more accurate. Things we know, or should
> know:
>
> 1. Direction of the ray.
> 2. The 'object' that a point the ray hits belongs to.
> 3. Where in 3D space that 'should' place the surfaces in relation to each
> other.
>
> What is needed is to identify which object when hit is 'behind' the ray
> at the point of intersection. If you know that you are leaving object X,
> but the point you hit, due to precision issues, is on Y, then obviously
> those calculations need to be delayed in cases where you will also hit X
> at roughly the same exact point. It would seem to me that the odds of two
> objects being so close together that they don't coincide, but numerical
> precision makes them seem to, is much less often than intentional direct
> contact between surfaces. If you know that they should occupy the same
> apparent space and that one must mathematically appear prior to the
> other, there should be some way to figure out which is which and act
> accordingly, right? Even if this double checking could only be turned on
> manually in certain CSG where you 'know' such a check is needed it would
> help.
>
> Then again, I don't have a clue about the internal mechanics, so maybe I
> am missing something obvious.. It is definitely not something I could
> code and test for myself.. :( And yeah, I know how you get around it, I
> just think a better way has to be possible.
>
> -- 
> void main () {

>     call functional_code()
>   else
>     call crash_windows();
> }


Post a reply to this message

From: Patrick Elliott
Subject: Re: Coincidence issue..
Date: 19 Aug 2004 20:55:28
Message: <MPG.1b8ef9aa3e96301989b14@news.povray.org>
In article <4124c57e$1@news.povray.org>, "JWV" <jwv|at|planet.nl> says...
> "Patrick Elliott" <sha### [at] hotmailcom> wrote in message
> news:MPG.1b8c2722aa0cd162989b13@news.povray.org...
> Just as Patrick, i don't know all the details of the way povray works, but
> i'll try to explain a way to get the effect Patrick means.
> 
> - When making the scene one should be able to make some objects "master"
> objects, like this:
> 
> box{0,1 master}
> 
> during the render, when a ray hits an object, the program should check
> wether there is an other object nearby (say within a radius of 0.0001).
> When there is one, and it's a master object, the ray should pretend to be
> hitting the master object. This way one could easely avoid coincident
> surfaces.
> 
> The drawback will be -as usual- speed, especialy the checking for nearby
> objects.
> 
> No idea wether it is possible, usefull etc. But this is what i came up with
> while reading Patricks post.
> 
Hmm. Using MS LookOut by any chance? The reply/post parts are in a non-
standard order in yours.

As for your idea. It probably wouldn't speed things up any and it is also 
flawed. It doesn't take into account 'where' a ray is when such a 
collision happens. If the correct result should have been object 'A', 
then 'B', then some paths will produce 'B' - 'A' instead, so which one do 
you make the 'master'? This is especially bad in the case of animations, 
since the objects relative locations and the order a ray hits them 
changes, so forcing an order on them will fail. You need to have it 
behave correctly from the perspective of the real order, not one defined 
using some arbitrary setting. If you are already determining which actual 
surface was struck, I can't imagine any gain from setting an arbitrary 
master object, instead of just calculating the 'real' location of the 
surface, based on a vector that points to its physical center, which is 
different then inside/outside, which 'might' otherwise provide the same 
info.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.