[ODE] C# Access

[John Buehler]

Ben Hutchison writes:

> I'd be interested to see an interface to ODE from C# so please make your
> work available.

I've sent Ben a copy of my effort.  It's not ready for an inclusion in
contrib (not that I know how to go about doing that).

> Im not sure if you're aware of Axiom
> (http://axiomengine.sourceforge.net/), who claim to be writing a physics
> engine layer for their C# game engine based on ODE. They may have
> grappled with the integration issues already.

I looked into Axiom.  The project appears largely dead in the water.  I
located a number of references to some kind of ODE interface, but I was
unable to find the actual interface files.  Perhaps they are in yet another
project.

> I know that the MS .NET tools include a feature (the "/clr" switch) that
> allows normal, unmodified C++ code to compile to IL byte-code, that can
> be executed within the .NET runtime (as opposed to making native<->CLR
> calls). So, it may be possible to recompile ODE as is into .NET IL code,
> rather than calling it as a native library. This area is still in some
> flux, undergoing a name change from "managed C++ extensions" to C++/CLI,
> and some beautification of syntax. Just an option to consider.

I wasn't aware of that, but I wouldn't want to pollute someone's machine
with multiple copies of ODE.  If ODE is distributed as a native DLL, I'm
fine with interfacing to that.

> Another issue you may/may not have hit is the relocation of objects in
> the CLR due to garbage collection. Pointers from native to CLR objects
> are invalidated when such relocation occurs. 2 solutions are the "pin"
> keyword, which prevents relocation, or better, the "gcroot" object
> handle containing a smart pointer that's kept up-to-date when the system
> moves its target object.

In C#, "pin" is "fixed".  There is also the technique of allocating objects
on the stack ("stackalloc" instead of "new") instead of the relocatable heap
if the object's lifetime is going to be appropriately limited.

The "gcroot" technique would be rather invasive to the ODE code.  Far
better, I'd say, to place the onus on the managed code.  At present I just
create an array of objects that I want to pass out to unmanaged code, and
pass out the array index instead of the actual object reference.  Result: a
private, stable heap.  Cumbersome at times, but manageable, especially when
all objects can be handled by the same untyped heap.  Structs are another
matter.

> Re: the "__stdcall" issue when directly calling back from native code, I
> haven't seen any way that can be changed short of a Managed C++
> intermediator.

Having ODE make callouts using "stdcall" on Windows doesn't seem
unreasonable to me at all, so I'd continue to lobby for that change.  The
mediator is a not-unreasonable solution, but it would seem natural to have
that mediator as a part of ODE, not each calling application.  As a result,
I figure the "stdcall" change is again the way to go.

Compatability with existing ODE unmanaged apps would be an issue if the
change were made.

JB