[ODE] My ODE++

[Nicholas Francis]

I respectfully disagree with this approach: IMO, this ties the physics  
in much too close to the application.

Examples:

* Our engine has a substantial graphics engine, where physics is only a  
small part. No representation that could be tied to ODE would serve.

* Sound depends not one surface, but on which 2 are involved in the  
explosion (e.g. rock hitting rock sounds a lot different than rock  
hitting wood. Also, sounds vary depending on speeds.

Ode is a library that handles dynamics. It does that well. Stick to  
that rather than trying to add everything but the kitchen sink to it.

If you actually try to implement this CKitchenSink you're talking  
about, and then try to apply it to another problem domain, you will  
quickly realize how bad this design is.

Just my 2c...

Nicholas Francis
------------------------------------------------------------------------ 
-------
Scheduling fascist - Over The Edge Entertainments

On Jan 8, 2004, at 6:18 AM, Manohar B.S wrote:

>>> C++ implementation/ wrapping
>
>       Good work. My suggestion is that there should be
> very Clear, Rugged and Hierarchical c++ mplementation.
> My be then ODE will be more ealsily become "Managed
> Code".
>
>  The problem I face is with the Contact Joints. A body
> should have it's own surface property. One class by
> name CBody can have geom, phys & surface prop, audio
> prop, & graphics prop. When two bodies collide, each
> having its own dGeomContact, a method of evaluating a
> single resultant dGeomcontact should be implemented.
>
>  ResultantGeomContact = EvalResult(dGeomCont1,
> dGeomCont2);
>
>  Again the CBody may or may not have physics depending
> on the whether they are static or dynamic.
>
> Cheers!
> Manohar
>
> --- "royce3 at ev1.net" <royce3 at ev1.net> wrote:
>> After a year on the list, we're finally to a point
>> where I need to actually
>> look at ODE. As an attempt to understand how ODE
>> works, I started building
>> some C++ wrappers, and after a couple days of
>> playing with it, I finally
>> have
>> them to a point where I'm somewhat happy with them,
>> for the parts that I
>> have
>> wrapped. I also wrote a header you can insert to get
>> a trace of what ODE
>> functions are being called, and with what
>> parameters. It's not
>> comprehensive, but covers the functions that I was
>> using when trying to
>> figure out why things weren't showing up. ( I
>> finally discovered that I
>> couldn't see anything because I wasn't sending
>> anything to be rendered...
>> oops )
>>
>> Anyways, if someone has a minute, I'd like some
>> feedback on the design. Is
>> there something about the classes that indicates a
>> particular lack of
>> understanding? Is it something that could be useful
>> as a contrib after some
>> more work? Also included is my modified
>> Test_BoxStack.cpp that uses the
>> wrappers.
>>
>> In particular, the classes simplify building bodies
>> out of multiple non-
>> centered geoms, like the complex object in
>> Test_BoxStack. As I said since
>> I'm
>> still pretty new, I'm not sure if the design will
>> scale very well feature-
>> wise.
>>
>> FWIW, we're working on designing an engine for two
>> of our games. One will
>> use
>> physics, and one won't, so I'm designing these
>> classes to eventually plug
>> into that engine.
>>
>>
>>
> --------------------------------------------------------------------
>> mail2web - Check your email from the web at
>> http://mail2web.com/ .
>>
>>
>
>> ATTACHMENT part 2 application/x-zip-compressed
> name=ode++.zip
>> _______________________________________________
>> ODE mailing list
>> ODE at q12.org
>> http://q12.org/mailman/listinfo/ode
>>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>