[ODE] Re-inventing the wheel

[Shaul Kedem]

Allan,
 IMHO, this are all great suggestions (seeing that I
am not going to be the one which will implement them
as well... probably), so before listing what I think
should be added I must remind you that this is an open
source project and seeing the evolution of it so far
it looks like it is an after hours spare time kind of
a thing (and still its one of the best projects out
there...).

 Anyway, the things I can add to the list below are:

 - A note in each of the emails in this list pointing
to help resources.

 - Different forums: newbies, algorithms, advanced,
error reporting, general discussion etc. - I was
against it about a year ago, but since then the user
base got bigger and nowadays we have 400(!) message in
a good month...

 - A tutorial: part of the "ODE for dummies" should be
a tutorial(s?) giving the basics and maybe the more
advanced stuff later on.

 - Having some sort of common grounds: the
mathematical bases , the physical bases and whatever
is needed are very important as well.

Well, that's it, all in all I think anyone who start
using ODE encounters obstacles , but later on, through
using the library (and turning the knobs) he become
proficient.

Best,
Shaul Kedem.

--- Allan Simonsen <Simonsen@rocketmail.com> wrote:
> 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
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com