|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|