[ODE] Re-inventing the wheel
Allan Simonsen
Simonsen at rocketmail.com
Fri May 16 07:45:02 2003
Just a thought that came to me after lurking on this
list for 6 months: Most new programmers that starts
using ODE is forced to reinvent the wheel (in some
cases quite literally).
Have a look at the past messages, and you'll see some
clear trends:
* "How do I compile ODE for VS6 / VS.NET"; most new
programmers are comming in from the Windows world, and
some have a fair amount of problems setting up a
correct ODE workspace. A lack of good "idiot's guide
to ODE" style tutorials is probably not helping.
* "How do I collide with triangles?" (quickly followed
by someone posting a link to OpCode, and the
subsequent frantic pleas for help as the new ODE user
frantically tries to hack OpCode into his system with
varying degrees of success). Variations on this
include "How do I collide against a BSP?" and "How do
I collide against a heightmap?"
* "How do I make a car?", followed by the
heart-wrenching pain as the poor fellow learns all the
fun and games of the wriggly-wheel problem, colliding
against non-primitive geometry, etc.
* "How do I make a rag-doll?"; well.. haven't seen
this as much as I would have expected. Most of those
that WOULD have asked are still suffering from several
mental trauma from trying to integrate OpCode
Most of the experienced users on this list have
already solved these problems: in some cases they've
even released the source-code, drifting around on the
net, which the enterprising young coder can cobble
together with varying degrees of success...
I would postulate that the biggest barrier ODE needs
to cross to increase it's user-base is to lower the
entry-threshold, and decrease the learning curve. One
way to do that is to *stop re-inventing the wheel*.
Everyone that wants to use ODE goes through the same
steps, hunts for the same answers, and meets the same
problems: surely there must be a better way to spend
our time (such as making the actual games ? ;)
* Someone previously suggested that we should include
a VC6 and/or VC.NET workspace zipped up inside the
tarball: SDL already does this, and it greatly reduces
the trauma a fresh windoze programmer goes through
when first meeting the package.
* Introduce new collision primitives: most of you have
already made these: why not make a move to include a
complete "OpCode Collision Primitive" and "Heightmap
Collision Primitive", with support for collision
against all other primitives. This would go a LONG way
towards making ODE usable out of the box, and save
everyone time. It'll also save people from
implementing sub-optimal solutions (such as
implementing a heightmap through OpCode, or
implementing only a subset of vs. Primitive
functions). Surely people like David Whittaker, Nate
Waddoups and Anselm Hook already have this source-code
lying around; why not integrate it into the main
code-base ?
* Providing classes that encapsulate advanced
behaviour: Two examples that spring to mind would be a
functional and stable Car, and a rag-doll. While this
wouldn't be a universally usable solution, it would at
least serve as a better starting point. (How many of
you have made at least one car-simulation based on the
little Tri-wheeled Rover example that comes with the
default distro). The idea would be to provide a
real-world example on how you COULD use this ODE for
the task, complete with the requisite hacks to get
around slidy/bendy wheels, etc.
Anyways: it's easy to suggest these things when I
probably won't be the person implementing it, so I'll
just crawl back to Karma (which is what we use at
work), and go back to lurking...
Thanks,
Allan Simonsen
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com