[ODE] new trimesh vs trimesh code

Bram Stolk b.stolk at gmail.com
Thu Sep 13 11:05:15 MST 2007


Hi,

You are talking about this right?
http://sourceforge.net/tracker/index.php?func=detail&aid=1586733&group_id=24884&atid=382801


According to the comment, hidden_asbestos tested it in his own game.

As far as I can see, the default behaviour is old-style test.
So I don't see that much harm in it.
The feature is clearly marked as experimental.
If it gives improvements for some people, putting it in as an option seems
to have some merrit.

But if it is really broken, it should be fixed of course.

  Bram- Hide quoted text -




On 9/13/07, Oleh Derevenko <oder at eleks.lviv.ua> wrote:
>
> Hi Guys,
>
> Do you ever check the stuff you commit?
> You have added that "new trimesh-to-trimesh collision algorithm" which
> uses
> 32bit hash derived from contact position coordinates up to 4th digit after
>
> decimal truncated to range -1677..1677 as THE ONLY CRITERION OF CONTACT
> COINCIDENCE.  This is 3x24-bit of hash input data and simple shuffling
> algorithm of unknown origin which produce 32-bit output. How do you think,
>
> how long it will take until somebody gets a hash collision and merges
> completely different contact points together?
> Also, if there is a contact node key buffer overflow, the new contact
> replaces the last slot in the hash table and thus it is possible to get
> two
> matching contacts not recognized and both added to contact list.
> Is it really worth to add speed improwements at this cost?
>
> Oleh Derevenko
> -- ICQ: 36361783



-- 
Zapp: Captain's log, stardate...er..
Kif: Ohhh. April 13th.
Zapp: April 13th. Point 2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ode.org/pipermail/ode/attachments/20070913/ec23ddce/attachment-0001.htm


More information about the ODE mailing list