[ODE] Complie to a Lib

[Anselm Hook]

> On Sat, 2 Nov 2002, Ander Taylor wrote:
> > I am new to ODE and C++. I am working on a wrapper to allow the use of ODE
> > from .Net, extending the work already done by Jeff Weber.

Cool!

> Have a look at Anselm Hook's work too, if you haven't seen it yet:

I recently moved my version here - you'll want this copy if you use this:
  http://p2pmap.org/cgi-bin/cvsweb.cgi/p2pmap/src/ode/contrib/csharp/

> > Anyway, my qestion, how should I compile ODE to a Lib from VC++7? Does
> > anyone know the settings I should use?
>
> If you want to build a DLL, have a look at the contrib/msvc7/ CVS folder,
> it's got .sln files for regular ODE and ODE with the tri-collider
> extension.

Some misc thoughts re C# ODE bindings:

I think it's a good idea to do a C# wrapper.  I have one that you can grab
pieces from as Nate pointed out - although I simply haven't had time to
finish it up.

There might be some merit in my approach however - regardless of if you do
your own or not:

   1) I made C# methods that directly bind to all DLL methods.  All of the
      raw dll methods I stuck into a single class - and made them static.
      (so effectively I have a big bucket of static methods)

   2) Then - separately - I made C# classes that called the static
      methods.

   3) I used no-arg constructors so that it was easier to manufacture my
      ODE objects using an XML notation.  The factory methods that
      discover the ODE objects (using the C# type reflection) are easier
      to deal with if you can invoke no-arg constructors on them...

      This *is* a bit of a hassle; it means that you have to 'late submit'
      ODE bodies to the world...  my code does that.

      Oh, one other reason for no-arg constructors - it allows out of
      order instantiation of objects.

The reason for the two stage approach is that it allows other developers
to build their own class abstraction layer on top of the ODE API.

...um... otherwise I think the only thing that I did that (while actually
pretty lame and pretty incomplete) was to try to keep the collision
callback in C.  I slightly extended the ODE DLL to have a new self
managing callback method for collision.

[ The reason that Russ makes us normally handle collision ourselves is
because collision is subjective to the application.  There are many ways
two surfaces can interact.  Imagine sandpaper and granite, or granite and
granite, or gummy bears and ceramic tile...  It turns out that finding
ways to abstract surface properties in the general case is not easy to
solve.]

In the case of C# you really don't want to have an inner loop like this
being exposed to C# - my own tests and others show that it is slow:

  http://www.tempest-sw.com/benchmark/
  http://www.kuro5hin.org/story/2002/6/25/122237/078

(although I expect that this will be untrue soon)

It might be possible to build intersection tables that are exposed to C# -
you could define the intersection of material properties.

Finally...  I just gave a little talk recently on using C# for games - I
will post my notes somewhere on my website - I'll make a link at:

  http://p2pmap.org/technology/csharp.html for now.

Basically I think binding ODE to C# is good but I wouldn't use C# for the
mainloop if you want performance...

 - a