Crystal Space
Welcome, Guest. Please login or register.
July 30, 2014, 12:29:40 pm

Login with username, password and session length
Search:     Advanced search
9005 Posts in 2043 Topics by 8260 Members
Latest Member: Lovelymae39
* Home Help Search Login Register
+  Crystal Space
|-+  Crystal Space Development
| |-+  Support
| | |-+  Migrating from csCollider to iDynamics
« previous next »
Pages: [1] Print
Author Topic: Migrating from csCollider to iDynamics  (Read 2502 times)
eventhorizon5
Jr. Member
**
Posts: 53


View Profile WWW
« on: December 01, 2008, 08:13:03 pm »

I'm trying to migrate my project from the csCollider system over to ODE using iDynamics, and am trying to figure out something.  Since my app does massive amounts of polygon creation and deletion during startup, I used the csColliderHelper::InitializeCollisionWrappers call to auto-create colliders for all objects (I'm also using it to allow the user to click on polygons such as buttons, and perform actions).  I'm trying to figure out how to get the dynamic system to create colliders for existing mesh geometry (like InitializeCollisionWrapper), and have tried iDynamicSystemCollider::CreateMeshGeometry but that seems to expects meshes to contain collision polygons (instead of creating collision polygons from existing polygons).  Any recommendations on what I should do for this?

-eventhorizon
Logged
Vincent
Full Member
***
Posts: 191


View Profile WWW
« Reply #1 on: December 01, 2008, 09:01:48 pm »

Hello,

  I think the equivalent would be iRigidBody::AttachColliderMesh().
But if you really have many of them, a few thoughts:
  • try to use more simple shapes like box or sphere collider when possible
  • consider using Bullet plugin instead of ODE
Also, check $CRYSTAL/apps/tutorial/phystut/phystut.cpp for some physics objects creation examples...
Logged
eventhorizon5
Jr. Member
**
Posts: 53


View Profile WWW
« Reply #2 on: December 01, 2008, 09:39:15 pm »

I think the equivalent would be iRigidBody::AttachColliderMesh().
But if you really have many of them, a few thoughts:
  • try to use more simple shapes like box or sphere collider when possible
  • consider using Bullet plugin instead of ODE
Also, check $CRYSTAL/apps/tutorial/phystut/phystut.cpp for some physics objects creation examples...

AttachColliderMesh() is still the same; it expects collision polygons to exist in the mesh.  Also, both plugins use dynamicsystem, so I don't know how that would change anything.  Most of the stuff I changed was modelled after the phystut app, but my app uses thing meshes with massive amounts of dynamic polygons.

Both calls give this error when trying to feed it existing mesh geometry:
csODECollider: No collision polygons, triangles or vertices

-eventhorizon
Logged
bookeater2
Newbie
*
Posts: 45


View Profile Email
« Reply #3 on: December 02, 2008, 04:57:00 pm »

I don't understand everything you are saying, but I do have an example from my own app that initializes all meshes in a list to be static physics objects. I add any rigid bodies after.

Ignore the icollection part if it's a problem.
One change I need to make to it is to check if each object was set to have no collider, and ignore it if so, but I don't know the place to check that yet.


   iCollection *cl = engine->GetCollection(regio.GetData());   
   iMeshList *ml = engine->GetMeshes();
   for(int i = 0; i < ml->GetCount(); i++)
   {
      if(cl->IsParentOf(ml->Get(i)->QueryObject()) )
      {
         dynSys->AttachColliderMesh (ml->Get(i), ml->Get(i)->GetMovable()->GetTransform(),
            friction, restitution);
      }
   }   
         
}
Logged
eventhorizon5
Jr. Member
**
Posts: 53


View Profile WWW
« Reply #4 on: December 02, 2008, 07:40:52 pm »

I don't understand everything you are saying, but I do have an example from my own app that initializes all meshes in a list to be static physics objects. I add any rigid bodies after.

Still getting the same with your code (since it's still basically the same code as mine, except just traverses the engine's meshlist):
"csODECollider: No collision polygons, triangles or vertices on ..." ('...' being each mesh found).

What I was saying before (didn't really explain it right) is that my app (which is a skyscraper simulator) creates polygons at runtime as it parses a script file and then later divides them up into multiple pieces when doing a hole cut operation (one poly turns into 4, with the 5th being dropped); so it's not easy to create separate collider polygons and keep them associated to the original polygons.  The InitializeCollisionWrappers worked because it automatically created collision geometry from all the existing polygons in the engine.

-eventhorizon
Logged
bookeater2
Newbie
*
Posts: 45


View Profile Email
« Reply #5 on: December 04, 2008, 01:51:18 am »

Quote
AttachColliderMesh() is still the same; it expects collision polygons to exist in the mesh

My mistake, I thought you were using irigidbody.AttachColliderMesh() not what I had in mine.
My example does seem to work for normal genmeshes though, and having an icollider beforehand or not makes no difference, but I don't know what the collision polygons are. Also my example probably doesn't compensate for any moving of objects after the setup.
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 5.448 seconds with 15 queries.