|
|
On 7/16/2012 3:35 PM, clipka wrote:
> Am 16.07.2012 21:21, schrieb Chaanakya:
>> I'm not sure exactly where this bug lies, but pinning it on difference
>> seems to
>> be the most logical thing. Here's some sample code:
>
> This is actually not really a bug, but merely a (currently) inevitable
> limitation: When tracing a ray from some surface, POV-Ray must make sure
> to ignore intersections with the very same or a coincident surface. To
> be robust against rounding errors, it does this by comparing the
> distance to the intersection with a certain minimum distance threshold.
>
> The threshold was changed during the development of 3.7 (I'm not sure
> why though).
There almost needs to be like either an "infinite" math, which isn't
practical, or some sort of "extra" math, which tells it, when running
across these things, "Are you inside object A, instead of B, and from
which direction are you approaching that side, as a result?". No idea if
that is even practical, but... coincident surfaces (and obviously
intersection code) currently require tricks that, from a practical
standpoint "break" the actual physics of the object, by requiring things
like, "leave a small gap between the contents of a cup, and the actual cup.
This is, kind of a silly situation, especially if you where trying to,
say, "fill" the cup using something like someone's liquid physics
simulations. Now, testing which thing you where just "inside" on the way
to the surface won't work in all cases, probably, but being "aware" that
the surface being hit has its "backside" in front of you, instead of
behind you, in principle, might cut down on some of the issues. Or, it
might create others, but it would, I would think, create a kind of
"sorting", where the side you are headed for would always be, "Belonging
to what I just came from, first, then the other one.", without regard to
any rounding issues.
Or am I just not getting the problem again? lol
Post a reply to this message
|
|