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

[Daniel Huser]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20061023/11f87668/attachment.htm