[ODE] ODE .NET Bindings Performance Issues, Unsafe code, etc...

Mon Oct 30 11:11:56 MST 2006

Dear all,

I am reposting this since my original post with attachment was held in
moderation.

Since my concerns considering efficiency and usability of .NET
wrappers to ODE held even after strong argumentation in this list, I
decided to pursue the implementation of a complete and fully
documented lower- (P/Invoke bindings) and high-level (Class hierarchy)
managed API to this amazing library. In attachment follows the link to the
complete source code of this new alternative, self-contained, wrapper.

It is fully compliant with ODE 0.7, and, to the best of my knowledge,
supports ALL ODE functionalities in a managed and structured
environment.

A word of warning: it has not been extensively tested, so feedback
would be appreciated in every regard. This is my vision of what an ODE
managed wrapper should be, but it doesn't mean it has only good design
decisions. Some of them could perhaps be improved, but I count on your
constructive criticism and improvements.

Currently I have no repository or web storage on which to distribute
this wrapper, so if anyone (hopefully the main ODE team) is willing to
provide hosting, it would of course be appreciated.

This wrapper links dynamically with the ode.dll and I'm willing to
update the API whenever ODE itself is updated. I've tried to take
every step in order to ease maintenance, documentation and portability
of the code, so it should be one of the more compatible
implementations around with both Windows XP and probably Mono too.

I'll post the complete documentation in both CHM and Web format
immediately following this message. I hope you enjoy it and that it
will be as useful to you as it will be to myself and my projects.

Best regards,

Gonçalo

Links:

OdeNet source code: http://pwp.netcabo.pt/himura_kenshin/OdeNet.zip
OdeNet documentation: http://pwp.netcabo.pt/himura_kenshin/OdeNetDoc.zip

> On 10/23/06, Gonçalo Lopes <goncaloclopes at gmail.com> wrote:
> > Dear Daniel,
> >
> > Rayne's ODE.NET showed just how efficient a MC++ wrapper can be, and
> > it's probably even easier to develop, since you don't have to go
> > through the subtleties of P/Invoke and the C# interop to make it
> > happen. That's why the MC++ is called the IJW (It Just Works)
> > approach.
> >
> > Basically, you just have to include the original header files in Ode
> > and presto, you can use Ode in MC++ (it should really compile right
> > off the shelf if you link it statically or dynamically with the
> > ode.dll).
> >
> > Just some considerations about such a project. First, I believe that
> > in the IJW approach what really pays off is a direct implementation of
> > a managed class OOP hierarchy off the Ode functions. It will be more
> > efficient and more effective than just adding managed methods for the
> > lower-level calls. There are two main reasons for this:
> >
> > 1. Developing managed methods will just lead you to something like the
> > C# approach, since you have to perform a 1:1 mapping. This may even be
> > worse efficiency wise than P/Invoke, since you're not even performing
> > a direct invocation of the dll functions, but introducing additional
> > function calls between them.
> >
> > 2. Lower level wrappers is not really what the .NET user wants. That's
> > just the first step towards exposing a clean object-oriented
> > functionality, with delegate calls, managed user data, etc... So if
> > you're already into IJW, why not be more effective and go immediately
> > to this step?
> >
> > So basically what I mean is this: if you go into MC++, you can just
> > bypass the whole lower-level wrapper thing because you already have
> > it. What could be worthy to share between an efficient MC++ ODE and a
> > cross-platform fully C# ODE is the high-level class hierarchy, in my
> > opinion, with the low level methods style being selected in a couple
> > of macro calls. Either you could compile it with access by P/Invoke or
> > directly call the Ode methods if in MC++, but the exposed
> > functionality should be the same.
> >
> > By the way, I still believe that I can harness close to the same level
> > of efficiency of MC++ in C# P/Invoke. But you do need to accept that
> > you will have to include unsafe method calls to avoid triple-copying a
> > Vector or Matrix each time you set some body parameters. I've done
> > just that in my recently completed, fully C# ODE P/Invoke wrapper.
> >
> > I'll be advancing next towards specifying the high-level class
> > wrapper, which, IF everything went well, could be close to core level
> > functionality by the end of the week.
> >
> > But still, maybe I'll think about a MC++ version of the hierarchy as
> > you suggest. It could indeed be worth it since it's a lot easier to
> > do.
> >
> > Best regards,
> >
> > Gonçalo
> >
> > On 10/23/06, Daniel Huser <dhuser at 1eeurope.ch> wrote:
> > >
> > >
> > >
> > > Hi Gonçalo,
> > >
> > > >Although I have to admit that being in MC++, ODE.NET was not only
> > > >faster than Tao.Ode ever was, but it also admitted more bodies on
> > > >screen, whilst OdeDotNet would blow up with a stack overflow a lot
> > > >sooner... don't know why though, could just be my example's fault. And
> > > >this is the main reason why I wanted an efficient and solid low-level
> > > >binding for the ODE API. I've tried practically all the .NET wrappers
> > > >ever made for ODE and I'm still not pleased with any of them so I
> > > >really wanted to make the "official" bindings the definitive solution
> > > >to this problem.
> > >
> > > Well, the .NET wrapper being cross-platform is nice and all, but maybe it
> > > would be nice to also, additionally, have a high-performance MC++ version of
> > > it. Do you think it would be a lot of effort to make a low-level wrapper for
> > > ODE in MC++?
> > > My c++ and c skills are very limited if one can even call it that. My main
> > > skills lay in .NET/C#. So i have no idea what it might take to implement
> > > such a wrapper in MC++, or let's say, what it would take to make ODE compile
> > > in MC++.
> > > How much work would it be compared to a C# wrapper? Would it be worth the
> > > effort to do this side-by-side to a cross-platform .net wrapper?
> > >
> > > Regards,
> > > Daniel
> > >
> > >  ________________________________
> > >  From: Gonçalo Lopes
> > > Sent: Fri 10/20/2006 0:49
> > > To: Terry L. Triplett
> > > Cc: ode at q12.org
> > > Subject: Re: [ODE] ODE .NET Bindings Performance Issues, Unsafe code, etc...
> > >
> > >
> > > Hello Terry,
> > >
> > > I've used OdeDotNet initially and loved the design principles behind
> > > it. Unfortunately its level of completeness didn't allow me to use it
> > > at the time. I've switched to ODE.NET but, as I've said, it's dead
> > > code and not even cross-platform anyway.
> > >
> > > However, though, the higher-level part of ODE.NET has some really nice
> > > design ideas for convenient OOP patterns for such things as collision
> > > joint groups, callbacks, user data in ODE entities, etc... I liked the
> > > approach, even though the concrete realization was lacking.
> > >
> > > Although I have to admit that being in MC++, ODE.NET was not only
> > > faster than Tao.Ode ever was, but it also admitted more bodies on
> > > screen, whilst OdeDotNet would blow up with a stack overflow a lot
> > > sooner... don't know why though, could just be my example's fault. And
> > > this is the main reason why I wanted an efficient and solid low-level
> > > binding for the ODE API. I've tried practically all the .NET wrappers
> > > ever made for ODE and I'm still not pleased with any of them so I
> > > really wanted to make the "official" bindings the definitive solution
> > > to this problem.
> > >
> > > Still, my offer of help stands, and I'll definitely take a look at
> > > what OdeDotNet has become since my last visit, which was somewhere
> > > near July this year, and I'll get in touch again.
> > >
> > > Best regards,
> > >
> > > Gonçalo
> > >
> > > On 10/19/06, Terry L. Triplett <c0d3g33k at gmail.com> wrote:
> > > > On 10/19/06, Gonçalo Lopes <goncaloclopes at gmail.com> wrote:
> > > > > > > * separate the wrapper into two design levels: API bindings level
> > > > > > > (lower-level wrapper) and .NET level types and classes
> > > > > >
> > > > > > I am producing an API binding; I have no plans for a class library but
> > > > > > welcome anyone else to take up the challenge.
> > > > >
> > > > > Ok, I'll be more than happy to help the community on this regard, but
> > > > > first we need a solid and efficient lower-level API bindings.
> > > >
> > > > The 2-design levels approach is the general approach taken by the Tao
> > > > bindings. The highlevel wrapper corresponding to Tao.Ode (those other
> > > > 'solid and efficient lower-level API bindings) is OdeDotNet. Since the new
> > > > Ode bindings will be presenting virtually the same API as Tao, OdeDotNet
> > > > should be easily adaptable to them, and the project could use some help
> > > > anyhow.
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > ODE mailing list
> > > ODE at q12.org
> > > http://q12.org/mailman/listinfo/ode
> > >
> > >
> > > _______________________________________________
> > > ODE mailing list
> > > ODE at q12.org
> > > http://q12.org/mailman/listinfo/ode
> > >
> > >
> > >
> >
>
>
>