[ODE] Collision Trimesh-Box
Oleh Derevenko
oder at eleks.lviv.ua
Wed Aug 15 01:33:28 MST 2007
I have a bit different coding conventions for myself. For example, never to
use global variables, never to make returns from inside of the function,
have all the class fields private and access them via methods only even
within their own classes, have homogeneous code in all the functions, use at
least two words for variable and three words for method identifiers, etc.,
etc. If I would have to make a patch it would be unpleasant for me to
develop in style of ODE.
Though, to be able to use it effectively in my project I may need to make
some changes indeed. If I do so and if you would be interested I could share
them with community.
Oleh Derevenko
----- Original Message -----
From: "Jon Watte (ODE)"
To: "Oleh Derevenko"
Subject: Re: [ODE] Collision Trimesh-Box
> Well, feel free to supply a patch to make it better!
> As you know, optimize for the common case, make the uncommon case
> correct...
>
> Cheers,
>
> / h+
>
>
> Oleh Derevenko wrote:
>> I do not need to simulate physics. I implement collision checking for 3-D
>> object space. So the only thing I need to know is if there is any
>> collision or not. And for that, it's sufficient for me to have only one
>> contact point or even not to have any at all - I just need to test for
>> the fact of collision.
>>
>> Oleh Derevenko
>> ----- Original Message -----
>> From: "Jon Watte (ODE)"
>> Subject: Re: [ODE] Collision Trimesh-Box
>>
>>
>>
>>> For trimeshes, you almost always want at least 10 contacts, preferrably
>>> more. Asking for a single contact with a trimesh is a special case that
>>> don't necessarily need to be tested for.
>>>
>>> Also, in the case you only want one (ray-trimesh with "closest"
>>> contact), you still need to check all the contacts to find the closest
>>> one.
>>>
>>> So, can you optimize for the case where the user asks for fewer contacts
>>> than he really needs to see? Yes, you can, but that's kind-of like
>>> optimizing for a file-not-found error.
>>>
>>> Cheers,
>>>
>>> / h+
>>>
>>>
>>> Oleh Derevenko wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>>
>>>>>> What happens if you reverse the winding of all the faces?
>>>>>>
>>>>>>
>>>>> No. That does not help.
>>>>>
>>>>>
>>>> So, the reason was quite simple. Having believed the comment for
>>>> dCollide,
>>>> -----------------------------
>>>> * @param flags The flags specify how contacts should be generated if
>>>> * the geoms touch. The lower 16 bits of flags is an integer that
>>>> * specifies the maximum number of contact points to generate. Note
>>>> * that if this number is zero, this function just pretends that it is
>>>> * one -- in other words you can not ask for zero contacts. All other
>>>> bits
>>>> * in flags must be zero. In the future the other bits may be used to
>>>> * select from different contact generation strategies.
>>>> -----------------------------
>>>> which says that is flags is zero the function pretends it is one, I had
>>>> made a mistake because this is a complete bullshit and there is no
>>>> special processing of zero-value in the code. If flags is zero the
>>>> function always returns zero contacts.
>>>>
>>>> Also, in GenerateContact() of collision_trimesh_box.cpp there is a
>>>> cycle
>>>> for (int i=0; i<OutTriCount; i++)
>>>> which checks for matches with normals already generated. Why does not
>>>> it bail out after the match has been found and continues checking all
>>>> the rest contacts? Is not it one of the first optimization principles
>>>> every student starting to write programs should know?
>>>>
>>>> Or the same thing in dCollideBTL() of collision_trimesh_box.cpp. If all
>>>> the available contact return slots are already assigned, why the
>>>> function continues executing cycle
>>>> for (int i = 0; i < TriCount; i++){
>>>> checking triangles and calculating intersections just to see every next
>>>> time that there is no more room left to store result and just to ignore
>>>> that result after all?
>>>>
>>>> It's really sad to see code like that. :(
>>>>
>>>> Oleh Derevenko
>>>>
>>>>
>>>> _______________________________________________
>>>> ODE mailing list
>>>> ODE at ode.org
>>>> http://ode.org/mailman/listinfo/ode
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition. Version: 7.5.476 / Virus Database:
>>> 269.11.15/949 - Release Date: 12.08.2007 11:03
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> ODE mailing list
>> ODE at ode.org
>> http://ode.org/mailman/listinfo/ode
>>
>>
>>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition. Version: 7.5.476 / Virus Database:
> 269.11.15/949 - Release Date: 12.08.2007 11:03
>
>
More information about the ODE
mailing list