Hi, > I'm writing b/c I wanted to add special iTerraFormer collider to cs. > The problem is that now special interface for it is located in > csOPCODECollideSystem::CreateCollider (iTerraFormer* mesh)
> I think that it will be more wise to put this somehow to > collider.cpp and use cs opcode plugin as ODE does (only for trimesh > collider), adding special code for other primitives (like obb, > sphere etc.) cd. I would also remove the use of polygons in places > where more primitive shapes could be used (like csColliderActor, > instead of box shaped polygons I would use obb, wouldn't it be > faster?). The problem is that this resolution will just copy current ODE > plugin functionality (but could be simpler/faster)... > Second resolution will be to keep things as they are now and either > build opcode mesh data for iTerraFormer or write special query for > height data <-> trimesh. After struggling with producing 'right' triangles for height data after collision I think it will be best to do it higher (in collider.cpp). This again leads me to rewriting things that are already possible with ode. Using ode will lead to writing cel property classes that are already done for cs cd system based on opcode - I don't know which is worst ;). -- greetings, Piotr Obrzut mailto:[EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
