[ODE] Collision Trimesh-Box

[Jon Watte (ODE)]

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
>
>
>