Thread: [cgkit-user] help regarding attached example
Brought to you by:
mbaas
From: Ricardo K. <ric...@gm...> - 2006-05-14 18:36:16
Attachments:
demo.tar.gz
|
Hi: I have been working on a short demo of what I want to achieve. So far I have got some stuff working, but some stuff still fails. Can anyone please look at the code, and tell me what I am doing wrong? Any other suggestions are welcome. Specifically, in this example, the Module object floats above ground when I pass it the pos parameter, ignoring the fact that gravity should pull it downwards. What I would like to achieve later on is to use a mesh model for the Link and Block classes, in order to get more realistic behavior and rendering. If anyone can help me in integrating a mesh model (I did it in blender, so any format blender can export is fine with me) for each of the mentioned classes, I will be greatly thankful. Regards, Ricardo Kirkner |
From: Matthias B. <ba...@ir...> - 2006-05-15 15:51:35
|
Ricardo Kirkner wrote: > Can anyone please look at the code, and tell me what I am doing wrong? > Any other suggestions are welcome. I had a quick look at your demo code and one thing I noticed are the hierarchies. The simulation assumes that every rigid body is given in world space. It doesn't handle hierarchies (as you don't want to do forward kinematics but rather have a simulation algorithm control the position/orientation of the bodies). For example, if you want to simulate a robot you would simply define its rigid body parts (all in world space), position and orient them as desired and connect them with joints. This is already the reason why your bodies float in space. They are part of the Module object which has the position (0,0,2), so you shifted all objects under Module up by two units without ODE noticing it. By the way, using hierarchies can be useful if you want to construct a complex rigid body from simpler rigid bodies. If you add an object to the ODEDynamics component that is a group, the component treats that as one single rigid body that is the union of all the group members. > What I would like to achieve later on is to use a mesh model for the > Link and Block classes, in order to get more realistic behavior and > rendering. It is ok to use meshes to get a more detailed visual appearance, but note that triangle mesh support in ODE is not that stable yet. So using them for all your collision geometry might not be such a good idea. From my own experience it is ok to have a mesh as an environment and use the primitive collision objects for everything else, whereas mesh-mesh collisions sometimes produce somewhat weird results. So I'd suggest to do some tests first to check if ODE really is up to the task. - Matthias - |
From: Ricardo K. <ric...@gm...> - 2006-05-16 11:47:03
|
Hi Matthias: thank you for your reply > It is ok to use meshes to get a more detailed visual appearance, but > note that triangle mesh support in ODE is not that stable yet. So using > them for all your collision geometry might not be such a good idea. > From my own experience it is ok to have a mesh as an environment and > use the primitive collision objects for everything else, whereas > mesh-mesh collisions sometimes produce somewhat weird results. So I'd > suggest to do some tests first to check if ODE really is up to the task. I was thinking of using a mesh, because I cannot build my own geometry using the primitive geoms that are included with cgkit. I can almost construct it using a group, but some parts of the geometry don't match any predefined geom object. I managed to describe my object using a Polyhedron, or even a trimesh, but those objects wouldn't collide with an ODE plane, for example, so they would fall off the ground. |
From: Matthias B. <ba...@ir...> - 2006-05-16 17:20:54
|
Ricardo Kirkner wrote: >> It is ok to use meshes to get a more detailed visual appearance, but >> note that triangle mesh support in ODE is not that stable yet. So using >> them for all your collision geometry might not be such a good idea. >> From my own experience it is ok to have a mesh as an environment and >> use the primitive collision objects for everything else, whereas >> mesh-mesh collisions sometimes produce somewhat weird results. So I'd >> suggest to do some tests first to check if ODE really is up to the task. > > I was thinking of using a mesh, because I cannot build my own geometry > using the primitive geoms that are included with cgkit. I can almost > construct it using a group, but some parts of the geometry don't match > any predefined geom object. Is it really required that the collision geometry exactly matches the actual geometry? I would assume that in robotics it is often enough to only approximate the geometry so that self-collisions, etc, are detected...? > I managed to describe my object using a Polyhedron, or even a trimesh, > but those objects wouldn't collide with an ODE plane, for example, so > they would fall off the ground. I haven't tried that combination myself yet, but I vaguely remember having read that it isn't implemented yet (but this is an ODE issue, there's nothing I can do about that in cgkit (or PyODE)). But you could try using a box instead... - Matthias - |
From: Ricardo K. <ric...@gm...> - 2006-05-16 19:42:10
|
> Is it really required that the collision geometry exactly matches the > actual geometry? I would assume that in robotics it is often enough to > only approximate the geometry so that self-collisions, etc, are detected.= ..? > How can I have a Box collision geometry geometry and a visualization that is different from a box? In my case, the real geometry is something more or less complex. While I can get by using a box in order to represent my block, I need to display it as something more elaborate than a box |
From: Matthias B. <ba...@ir...> - 2006-05-17 08:52:51
|
Ricardo Kirkner wrote: > How can I have a Box collision geometry geometry and a visualization > that is different from a box? > In my case, the real geometry is something more or less complex. Use a Box (or whatever ODE supports) just as you did before and set its visible flag to False ("visible" is an attribute of every WorldObject). This means the box will still be used for dynamics but it won't get rendered. Now link your visualization geometry to the box (for example, using the link() command). This makes it a child object of the box which means it will move just like the box. On your visualization geometry you have to set the "dynamics" flag to False so that ODE will ignore it (i.e. it won't affect the mass properties and it won't be used as collision geometry). - Matthias - |
From: Ricardo K. <ric...@gm...> - 2006-05-17 11:49:20
|
> Use a Box (or whatever ODE supports) just as you did before and set its > visible flag to False ("visible" is an attribute of every WorldObject). > This means the box will still be used for dynamics but it won't get > rendered. ok, understood > Now link your visualization geometry to the box (for example, using the > link() command). This makes it a child object of the box which means it > will move just like the box. On your visualization geometry you have to > set the "dynamics" flag to False so that ODE will ignore it (i.e. it > won't affect the mass properties and it won't be used as collision > geometry). by "visualization geometry" you mean a GeomObject derived class? Is there a way to specify the commands to be issued for drawing the geometry? I have looked at the drawGL method, but I could not override it (maybe I missed something) Thanks again Ricardo |
From: Matthias B. <ba...@ir...> - 2006-05-17 12:18:26
|
Ricardo Kirkner wrote: >> Now link your visualization geometry to the box (for example, using the >> link() command). This makes it a child object of the box which means it >> will move just like the box. On your visualization geometry you have to >> set the "dynamics" flag to False so that ODE will ignore it (i.e. it >> won't affect the mass properties and it won't be used as collision >> geometry). > > by "visualization geometry" you mean a GeomObject derived class? No, I mean a full WorldObject (that has a geom assigned, of course). Example: # Simulation object b = Box( mass = 1.0, visible = False ) # Visualization object (in a real example this will probably be # loaded from a file) s = TriMesh() s.dynamics = False link(s,b) By the way, you can only set "dynamics" to False if the object can actually be used as a rigid body. If this is not the case (Polyhedron, etc) the simulation is already ignored by ODE anyway. > Is there a way to specify the commands to be issued for drawing the > geometry? I have looked at the drawGL method, but I could not > override it (maybe I missed something) This is not required for what I meant above, but as you're asking... You certainly should be able to derive from GeomObject and implement drawGL(). For an example of this, have a look at the file joint.py which implements the JointGeom class in Python. But you only have to do that if you want to implement your own geometry class. But for your visualization purposes I suppose a TriMesh or Polyhedron will already do. - Matthias - |