ODE with Panda3D?
Danny Price
Has anyone used this and is it any good?
Jon Watte
--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.
I'm looking into using Panda3D for a project I'm working on. It looks like a nice API and to my surprise, has ODE integration (http://www.panda3d.org/wiki/index.php/Using_ODE_with_Panda3D)
Has anyone used this and is it any good?
--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.
Danny Price
Jon Watte
--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.
Danny Price
Daniel K. O.
> I am concerned that ODE's heightmap might not cut it though...
The heightfield geom has long standing bugs of sometimes missing
collisions, or computing incorrect penetration depths. You'll probably
have to fix it, or use a trimesh instead.
--
Daniel K. O.
"The only way to succeed is to build success yourself"
Danny Price
Daniel K. O.
> How come it's not been fixed in all this time? Sounds like a fundamental problem....
How come you didn't fix it?
Numerous people bumped into the problem so far, and decided it was not
worth fixing it (as the trimesh is an easy workaround).
Danny Price
Daniel K. O.
> If the trimesh option is an acceptable workaround, why even have a heightmap feature?
It's not the optimal solution. But the amount of effort required to just
build a trimesh for the terrain (2 nested loop, and a couple of
trimesh creation functions) is less than the effort needed to hunt down
the heightfield bug(s). The heightfield would give you better
performance, less tunneling issues, and support for dynamically updated
height data.
The original heightfield contribution was supposedly bug-free; it seems
something broke after it was integrated into ODE (just in case you are
interested into digging up the commits from the repository). It might be
easier to just rewrite it all from scratch; after all, it just needs to
figure out the cells of the heightmap that are potentially intersecting
the geom, and perform triangle-geom test for each one, being careful to
discard duplicated contacts.
Oleh Derevenko
For example, in VS2005 debug single/double build in demo_heightfield if you
quickly drop two boxes and then, while they are still falling, quickly drop
three more spheres one of those spheres often falls through the ground
(well, these steps might be possible to simplify but they are not difficult
even the way they are). It should be enough to log initial creation position
for each sphere (e.g. output them to console) and then make a custom demo
build with sphere creation position hardcoded to that problematic position.
Just be sure to log floats in binary form (as an array of bytes) and then
hardcode sphere position reversely from that binary form to avoid changing
value during conversion to/from string.
Oleh Derevenko
-- Skype with underscore
Danny Price
For me, the lack of height field will probably be a deal-breaker. I need large battlefield maps for my tank sim and I don't think it's going to be practical to use meshes. This may mean I cannot use ODE for my project. Can you recommend another engine with a similar API and set of constructs?
Daniel K. O.
> for problems like this I have defended it before. If you want to
> improve ODE's standing against competitors like Newton, someone is
> going to have to start tackling problems like this.
It seems nobody have that much free time to start tackling problems that
are not relevant to them. If this problem is relevant for you, why don't
you do it? It's not like switching to a proprietary engine will give you
an engine without issues; it's just that you can't do anything about it.
With ODE at least you can do something about it.
Jon Watte
--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.
Daniel K. O.
> That won't work. A heightmap is infinitely deep. A triangle is paper thin.
> You really want to test the prism made up of the covering triangle into
> semi-infinite depth. That turns out to be a different test than the
> triangle/shape test.
It's only a problem if the geom is below the surface. Just take the
geom's center and do a plane test with the triangle right below.
Jon Watte
It's only a problem if the geom is below the surface. Just take the geom's center and do a plane test with the triangle right below.
Sadly, that won't generate good contacts, or in some cases, even correct contacts. Consider (seen from the side):
--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.
Daniel K. O.
> Sadly, that won't generate good contacts, or in some cases, even correct
> contacts. Consider (seen from the side):
>
> /
> _*__
> /
Well, with deep penetrations it's hard to even define what would be the
correct response anyway. My suggestion is what you would get for a
trimesh-for-terrain approach, minus the cost of "finding the triangle"
step; and it works reasonably well for many cases (even if it requires
some workarounds, like partitioning long, thin geoms, which have bad
AABBs anyway). Assuming the prism test is already implemented properly
in the current heightfield, it could be reused in the case of a rewrite
from scratch; on the other hand, it's possible it is the source of the
bugs (which might account for the "wrong contact depths" issue).
> I think one reason ODE has few contributors is that collision testing is
> really freaking hard
Agreed. Also in the game industry the developers are usually paid to
ship a game, not to come up with the most general and perfect solution.
This might be easier to achieve by a workaround than by fixing the real
bug. That might have been the case so far with the heightfield.
David Black
I think one reason ODE has few contributors is that collision
testing is really freaking hard -- especially compared to web
content management systems or wherever else contributors gather
in droves. I believe many people who attempt to use ODE and run
into some known problem don't actually have the math and
algorithms background to do a proper job of fixing it. Those
skills are fairly rare, IMO.
<<<
I am not sure that is exactly true. I don t think the math is that hard,
if you understand matrices/planes/line intersection. That is all you
really need to write intersection routines. ie not much more difficult
than a college course after high school teaches.
However, I think there is a certain amount of specialist
knowledge/experience required to understand how things fit together and
how to formulate collision problems in a way which can be solved. Not
exactly math, but it certainly uses math. It took me a long time to
figure out(and learn) how to do contact manifold generation, at some
point it just clicked how similar problems could be broken down in a way
which would allow elegant solution.
David
--
http://www.fastmail.fm - mmm... Fastmail...
Danny Price
--
Jon Watte
high-contributor systems, like Drupal, or Rails, or whatever. However,
the low-level C and C++ style of thinking is hardly taught in college
anymore, because for most business needs, high-level languages are the
right trade-off.
Sincerely,
jw
--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world.
Nevertheless, whether we get there willingly or not, we shall soon
have lower consumption rates, because our present rates are
unsustainable.
Klaus Backert
On 18 Jan 2010, at 17:04, Danny Price wrote:
> Or it could just be that one glance at ODE's sourcecode will send
> most sane developers running....
As a full-blown mathematician -- and because of that as an *unsane*
developer -- I can tell you, that I got used to treating annoyingly
complicated things with annoyingly many small details -- well, e.g.
ODE source code ;-). But I have priorities of my own.
Klaus
Jon Watte
The whole point of height maps is that you get deep penetrations, which you don't with a regular trimesh. If you're going to go for the "thin" trimesh version, then you might as well just use the trimesh geom. The heightmap could serve a unique purpose if it correctly resolved deep penetrations, and treating triangles as prisms is one way of doing just that.
with deep penetrations it's hard to even define what would be the correct response anyway
If you get the outline plus the deepest, my experience is that your object will come to rest eventually, and will react fairly naturally even when the time step seems too large (thus allowing deep penetrations).
Sincerely,
jw
--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.
David Black
The whole point of height maps is that you get deep
penetrations, which you don't with a regular trimesh. If
you're going to go for the "thin" trimesh version, then you
might as well just use the trimesh geom. The heightmap could
serve a unique purpose if it correctly resolved deep
penetrations, and treating triangles as prisms is one way of
doing just that.
<<<
Actually I would say the main benefit is the memory(cache footprint)
gain from storing the geometry as a heightmap. In addition heightfields
have well defined depentration directions/easy to compute
depentration(not exactly the same as handling deep penetrations,
although that is a major benefit).
David
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
Daniel K. O.
> I am not sure that is exactly true. I don t think the math is that hard,
> if you understand matrices/planes/line intersection. That is all you
> really need to write intersection routines. ie not much more difficult
> than a college course after high school teaches.
Lines and planes are indeed trivial. Try to come up with a collision
test between cylinders (not just a boolean test, we need contact normals
and penetration depths; and as few contact points as possible).
David Black
Cylinders are indeed painful, much better to use capsules when
possible(or approximate with a convex). However I still dont think the
math is that hard(solving some low order polynomials, point plane
distance, projection and circle intersection). However getting the logic
right and putting all this together is probably rather unpleasant.
David
> --
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ode-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>
>
--
Daniel K. O.
> Cylinders are indeed painful, much better to use capsules when
> possible(or approximate with a convex). However I still dont think the
> math is that hard(solving some low order polynomials, point plane
> distance, projection and circle intersection). However getting the logic
> right and putting all this together is probably rather unpleasant.
It certainly isn't in the same rank as the Clay Institute's Millenium
Problems. But if it requires far more effort than you (or anyone so far)
are willing to spend on it, isn't it considered hard? There are plenty
of theoretical algorithms used to prove lower bounds of problems, that
were never implemented because they are too complicated.
Nguyen Binh
Bullet has pretty stable cylinder collision detection routines.
--------------------------------------------------
Binh Nguyen
Computer Science Department
Rensselaer Polytechnic Institute
Troy, NY, 12180
--------------------------------------------------
David Black
I am not debating the "hardness" of the problem. Just that the
"hardness" is about the logic and how to formulate the problem, not the
maths.
Although I think it is doable, maybe I will have a go at putting it in
my engine and then let someone port it to ODE.
Is it cylinder-cylinder or cylinder-convex which is most interesting?
(dont take this to mean I will do this by a specific date, just that it
does sound like an interesting thing to try).
David
--
http://www.fastmail.fm - Send your email first class
David Black
uses GJK. I thought there already was a Bullet integration(or
vice-versa), but I dont follow either particularly closely.
David
--
Daniel K. O.
> One thing you guys can try is to integrate Bullet with ODE. I think
> Bullet has pretty stable cylinder collision detection routines.
Bullet can handle cylinders the same way it handles every convex geom
(through GJK). One can easily call whatever-is-the-bullet-API instead of
dCollide to produce contacts or this case (or even register a collision
handler at runtime to do it transparently), without having to touch one
line inside ODE. I'm not sure an "integration" is needed for that,
unless the "whatever-is-the-bullet-API" is some non-trivial amount of
code... if so... shame on you, Erwin! :P
Nguyen Binh
> In some senses I think bullet could be regarded as "cheating" since it
> uses GJK. I thought there already was a Bullet integration(or
> vice-versa), but I dont follow either particularly closely.
>
Could you elaborate on why GJK is "cheating"?
@Daniel
Bullet has a recently updated C-style interface so integrating Bulelt
to ODE should be easy.
Binh,
David Black
Well it is cheating in the sense that it does not impliment a
cylinder/cylinder intersection/contact generation routine. It solves the
problem by solving a more general problem. Which of course doesnt make
it any less useful, unless we are debating how hard it is to impliment
intersection routines:-)
I guess there could be numerical robustness or performance issues with
using GJK(or vice-versa). Although a lot of software uses it, so I dont
think it has any major problems.
David
> --
> You received this message because you are subscribed to the Google Groups
> "ode-users" group.
> To post to this group, send email to ode-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ode-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ode-users?hl=en.
>
>
--
Daniel K. O.
> I am not debating the "hardness" of the problem. Just that the
> "hardness" is about the logic and how to formulate the problem, not the
> maths.
Maybe we just have different views of what constitutes Mathematics. I
think logic and problem solving are the heart of Mathematics; so the
hardness is in the maths, not in the root finding or polynomial evaluations.
> Although I think it is doable, maybe I will have a go at putting it in
> my engine and then let someone port it to ODE.
>
> Is it cylinder-cylinder or cylinder-convex which is most interesting?
> (dont take this to mean I will do this by a specific date, just that it
> does sound like an interesting thing to try).
I think cylinder-cylinder has more demand. Even if not as a patch, as
long as it's license-compatible with ODE, any contribution will be more
than welcome.
Erwin Coumans
It is not that simple: GJK only calculates closest distance, so you
also need a penetration depth algorithm, such as EPA (expanding
polytope algorithm).
Even then, GJK only computes a single contact point (distance, normal,
position), which is generally not enough for stable stacking.
To get multiple contact points, Bullet has two methods. By default,
Bullet keeps 'contact manifolds', small contact caches with contacts
that persists over frames.
This way you can add new points and update or remove old points. An
alternative methods, which is slower, computes multiple contact points
at once,
by performing a small rotation around the separating vector. This
might suit ODE better, because the ODE API doesn't have the capability
of persistent contact points.
(all contacts are thrown away each frame). In Bullet, each contact
point can also store the 'lambda' vector of the contraint solver
(almost identical to quickstep, but better optimized using SIMD). This
is used for warmstarting (if you check out the quickstep innerloop,
you will see some mentions of warmstarting and SIMD, both are
implemented in Bullet).
In a nutshell, Bullet improves almost every aspect of ODE aside from 2 things:
1) ODE has a dWorldStep, a direct LCP solver. This could be easily
ported to Bullet. But I think most people use dWorldQuickstep, and in
that case the Bullet solver is equivalent but superior because it is
dWorldQuickstep with additional optimizations such as SIMD.
2) ODE has its familiar C API
If you really want the ODE C API with the proper working cylinder,
convex and heightfield collision detection of Bullet, it is easier to
wrap the Bullet SDK with the ODE C API.
I've actually tried it a while ago for a simple example, and I managed
to compile, link and run the 'boxstack' ODE demo using Bullet+ODE API.
Obviously more work is needed to cover the entire ODE C API, but I
think it is possible. We are busy with OpenCL optimizations, so
wrapping another C API is not high on our todo list, but I'm happy to
assist.
If you are interested in this, you can give feedback in this issue:
http://code.google.com/p/bullet/issues/detail?id=43
Thanks,
Erwin
2010/1/18 Daniel K. O. <danielk...@gmail.com>:
Nguyen Binh
A little OT: How do I use the second slower contact generation mode in Bullet?
Thank you.
--------------------------------------------------
Binh Nguyen
Computer Science Department
Rensselaer Polytechnic Institute
Troy, NY, 12180
--------------------------------------------------
Erwin Coumans
m_collisionConfiguration = new btDefaultCollisionConfiguration();
m_collisionConfiguration->setConvexConvexMultipointIterations(10,3);
The first argument (numPerturbationIterations) defines how many parts
the rotation circle (around the separating normal) is subdivided
If the number of existing contact points exceeds the second argument
(minimumPointsPerturbationThreshold), no further perturbations are
performed.
Back to cylinder collision: please check out Insomniac Games document
http://www.insomniacgames.com/tech/articles/0907/files/cylinderCollision.pdf
Thanks,
Erwin
2010/1/18 Nguyen Binh <ngb...@gmail.com>:
Nguyen Binh
On topic:
An interesting Cylinder stress test:
http://www.youtube.com/watch?v=P2TJeDSPgcs&hd=1
Note that Blender uses Bullet.
--------------------------------------------------
Binh Nguyen
Computer Science Department
Rensselaer Polytechnic Institute
Troy, NY, 12180
--------------------------------------------------
Erwin Coumans
(see my hand drawing for the difference:
http://bulletphysics.com/capsule_versus_cylinder.jpg).
Contact computation for capsule versus capsule is trivial so most have
a special case (handy for ragdolls),
whereas (flat capped) cylinder versus cylinder is harder, so Bullet
uses a generic GJK test, while others (Insomniac Games etc) use a
dedicated test.
I think performance for cylinder versus cylinder between gjk and a
dedicated test is similar, and very unlike a bottleneck,
unless you are working on a platform such as iphone and use many 3D coins ;-)
