[ODE] test program problems

[Jaroslav Sinecky]

Hi,
I just tried rapidly all the test cases and they do more or less the same
for me as for you. I think actually these test cases reflect quite well the
state of ODE. This is a non commercial package and has no consistent
maintenance. And these programs are called test cases, which suggests they
are ment more for testing various features of ODE (after someone makes some
change in code, after applying some patch etc.) more than a proud show
cases. They also show problems that ODE has, for example we know that moving
trimeshes don't work well, and that's probably the reason for what happens
in test_moving_trimesh.

I agree they shouldn't crash hard as they do in some cases and definetly
there should be some brief documentation explaining what is the expected
behaviour of each test case, because if you don't know what it should do, it
can hardly serve you as a test case. Someone familiar with these test cases
has some free time left to do that?

Still, you can learn a lot from them and some of them works without problem,
don't they? ODE is not without problem, that's the reality (no other even
commercial package is) but the big advantage is (apart of being free) that
you have all the code at your disposition and with some patience great
things can be done with ODE.

Jaroslav



> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
> Of Martijn Buijs
> Sent: Wednesday, August 24, 2005 11:03 AM
> To: ode at q12.org
> Subject: Re: [ODE] test program problems
>
>
> Holger Urbanek wrote:
> > To learn ODE I would suggest that you
> >
> > 1) Read the manual from beginning to the end. It's not complicated. If
> > you dont understand something, don't worry, read on.
> >
> > 2) Than look at the boxstack example.
> >
> > 3) Try to make your own program where a box falls down on a
> second fixed box.
> >
> > 4) Read again the section about joints.  Fix one box by a joint and
> > hang another box to the first one with another joint.
> >
> > 5) Try to apply forces (e.g. dBodyAddTorque).
> >
> > 6) Now think of what you are planning to do and look at the more
> > advanced examples.
> >
> > So: At the beginning don't let you bother with the difficult examples.
> > Start easy. Recognize the simplicity of ODE.
> > And yes, I think, that the examples don't have a fixed framerate ...
> > they are yust examples for ODE, so people can lern of that, not
> > examples for the art of game-programming, which complicates things and
> > brings no deep insight to ODE. (Perhaps for clarification: ODE ist
> > just the physics-engine, NO graphics engine. I don't even use the
> > supplied OpenGL library, as I more like the inventor-stuff ...)
> >
> > Have fun with ODE -- its great.
> >
> > Just my $0.02
> >
> >   Holger
>
> Hi,
>
> The problem for me is not how to get started, but rather the
> behavior of test programs themselves. I
> find it quite worrying that they crash. If its ODE itself that
> causes them to crash, can one
> guarantee my own test programs won't do that?
> Besides that, it may scare off others who want to use ODE. And if
> these programs ARE written to
> learn from, they just have to work correctly imho.
>
> And about the framerate; I do think it's important. It only takes
> ~10 lines, and when well
> commented, anyone can understand what it does. What I mean is, if
> the demo programs do have a
> textured and animated sky, why not make them framerate
> independent to make them work physically correct?
>
> Anyway, I still want to solve the crashing problem. It doesn't
> seem to be an OS or hardware problem
> as I'm having the same trouble on all of my machines (Windows
> 98/XP, Intel/AMD). Assuming the
> problem lies either within ODE itself or the test programs code,
> I have no idea where to start
> looking. Any hints on that? :)
>
> -Martijn
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode