No no, min- and max_extent return the boundary
box, and trace() returns the intersection of the
defined ray to the object in question with (I assuming)
most possible precision.

What I was talking about in the other thread is that
when doing iterative estimations (using trace) to find
when and where a particle (which fly curved paths
and thus can't be handled easily with just on straight
trace) hits an object, that is less precise than compared
to solving an actual formula to find when EXACTLY
a curved path will intersect with a plane.
For a particle system it is crucial to know *when* a
particle hits a wall, so its path to the wall isn't suddenly
shorter or longer than it would be in RL. It can also
matter very much *where* a particle hits, because with
imprecision, it might even happen that a very small
object is missed during the iterative trace-ing.

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


> -[Now, you use min_extent and max_extent to get the boundary box of the
> sphere]-
> Cunning stuff. Thanks for this tip: as you can see in the attached test
> render the accuracy doesn't really matter a great deal, as the sparks are
> going all over the place anyway. Just the mystery floating particle and
the
> rather ugly lighting artifacts on the floor to tidy up now (and something
to
> weld, of course...)
>
> Is there any reason why the min_extent/max_extent functions should be
> innaccurate? I noticed in the "PartixGen is BACK!" thread a discussion
about
> innacuracies in the trace function too. I suppose if these are calculated
> using general iterative intersection formulae rather than mathematically
> perfect equations, there is a small accuracy loss, but the renderings
rarely
> show up these accuracy errors, except in the case of two or more
coincident
> surfaces.
>
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message