[ODE] new trimesh vs trimesh code
oder at eleks.lviv.ua
Thu Sep 13 12:04:05 MST 2007
Well, I'm just doing some optimizations/improvements in collision detection code and I do not know what to do with this "new algorithm". Spending time for code that is faulty by design does not seem reasonable to me. On the other hand, I can't leave it aside and hope it will be reverted, because the corrections would not cover complete scope of collision related code then. And I can't fix that because it is impossible to implement reliable hashing for unlimited data size in fixed size hash table.
Does anybody know what were the details of that improvement? It seems to me that not only GenerateContact() function was changed but also middle part of the code was replaced. I did not have time to check it well yet because I just have reached that code late in the evening. So I might be mistaking regarding changes in middle part (I mean the code after Collider invocation and before GenerateContact()).
OK, I will try to fix that hashing algorithm tomorrow, but, well, it is not good to have project live by itself. There must be at least few experianced people who would briefly look through the code before they commit it. You can't just commit anything if you want people to treat your project seriously.
-- ICQ: 36361783
----- Original Message -----
From: Bram Stolk
Sent: 13 вересня 2007 р. 21:05
Subject: [ODE] new trimesh vs trimesh code
You are talking about this right?
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.
- Hide quoted text -
On 9/13/07, Oleh Derevenko <oder at eleks.lviv.ua> wrote:
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?
-- ICQ: 36361783
Zapp: Captain's log, stardate...er..
Kif: Ohhh. April 13th.
Zapp: April 13th. Point 2.
ODE mailing list
ODE at ode.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ODE