[Opensim-dev] physics architecture

[Stefan Andersson]

I tend not to use implicit destruction in any way on things hogging native resources - explicit is the way to go, ie have a Close() on everything and make sure you call it.
 
IDisposable is fine on things that tend to be destroyed quite immediately and in the same context, but the physical resources aren't like that.The problem with subclassing is that an object can switch between being physical and non-physical at the flick of a switch - so it has a 'state' much like the corresponding ChildAgent/RootAgent has or doesn't have a physical ScenePresence (avatar).
Why we did so that the ScenePresence might or might not have an avatar, instead of subclassing is because we wanted the transition from root to child not invoking destruction and reconstruction of classes.
 
There IS a well-known pattern called 'state' that deals with this; when a class should shift behaviour and state - I think this pattern is the way to go.
 
/Stefan
 



> Date: Fri, 2 Nov 2007 22:52:07 -0700> From: danbmil99 at yahoo.com> To: opensim-dev at lists.berlios.de> Subject: [Opensim-dev] physics architecture> > ok, I'm trying to wrap my head around what we need wrt physics overhaul. A> good example of what I consider close to broken is the fact that we're> calling AddPrimShape() in 5 places (load from storage, load from xml, rez,> copy...)> > This may be all wrong in C#-land, but in my wee little C++ brain I would do> something like this:> > SceneObjectGroup should be subclassed as SceneObjectGroupPhysical for any> object that interacts physically. This way, constructors and destructors> can do the right thing wrt allocating & cleaning up physics-engine stuff. > Other methods and properties such as velocity, position, resize, etc. will> also interact with the physics engine as necessary.> > Support for multiple engines can be accomplished one of two ways. 1) each> engine further subclasses SceneObjectGroupPhysical (ie SceneObjectGroupOde &> so on), or, we design an engine-agnostic physics API. I would lean towards> the former approach, as it is more general, and will be better suited to> handling special cases that are different among engines. In a sense, one> could argue that the unimplemented methods in SceneObjectGroupPhysical,> which are implemented by the physics engines themselves, are in effect an OO> API.> > This is obviously not a fully worked out idea, but I want to get some> initial feedback before I bother to flesh it out.> > -danx0r> > > _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071103/128c7384/attachment-0001.html>