new trimesh vs trimesh code

"Bram Stolk" <[email protected]>
Newsgroups gmane.comp.lib.ode
Message-ID <[email protected]>
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 <[email protected]> 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.

_______________________________________________
ODE mailing list
[email protected]
http://ode.org/mailman/listinfo/ode
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.