[Opensim-dev] IRegisterInterface for extending scene entities
Toni Alatalo
toni at playsign.net
Sat Dec 29 09:10:38 UTC 2012
On Fri, 2012-12-28 at 19:29 -0800, Dahlia Trimble wrote:
> +2 on a hierarchical entity-component design. I have several prototype
:)
Is certainly interesting how the plan has come to the table again.
> and flexible. I've also used it in a prototype c++/opengl viewer which
> is compatible with SL/OpenSimulator content (prims, sculpties,
> linksets, avatars, meshes, terrain) and it's quite capable of
> functioning in this type of scenario.and has performance which is
> competitive with the fastest LL based viewers I've seen.
We have also been happy with how the EC design has been serving in
practice. First with Naali against Opensim + new ModRex (Taiga) just to
sync & persist custom data in scene entities in Opensimulator. Then now
in the Tundra effort (i.e. using only the new Naali codebase, also as a
simple server instead of Opensimulator) for everything: also the core
features are made with ECs not only in the client side but in the
network protocol and on the servers as well. That seems to allow many
nice things in a uniform manner, for example GUI property editing and
generic network synchronization (*).
The early article where we reported about applying it in reX tells some
of our experiences -- it also discusses that old effort to refactor
Opensimulator SOG/SOP to something like this (just refers to Adam's plan
basically),
"An Entity-Component Model for Extensible Virtual Worlds"
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5928309&url=http%
3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5928309
For those interested & without IEEE lib access, a html view of the
source has the ~same content, misses images and the last edits by the
magazine folks but essentially the same text:
https://github.com/realXtend/doc/blob/master/arch_article/simple.rst
(*) That is, both 1. core things such as EC_Placeable (the scene node),
EC_Mesh, EC_Audio or WebView for that matter, and 2. your own custom
EC_MyAppThing are same kind of components. The entity-component editing
gui handles them identically, and the same builtin network messages are
used to sync the data in them.
The list & docs of bundled ECs in Tundra are in
http://doc.meshmoon.com/doxygen/component_base.html , perhaps
interesting to see examples of scene extensions.
> I do have mixed feelings about trying to refactor the existing
> OpenSimulator codebase into such an architecture. So much of the
> codebase assumes SOG/SOP as the foundation that it may be nearly
> impossible task to convert. If this is the case, I would suggest first
> doing a more detailed analysis of how other shared online environments
> are implemented before attempting a new design; other systems which
> don't duplicate the SL model; This could result in a far more flexible
> design which could take OpenSimulator far beyond what SL users expect
> in a server.
Agreed, some thought certainly doesn't hurt here. Hopefully some
experiences and examples that we can report from the reX side are
helpful, for that analysis of existing envs etc.
Basic extensibility is kind of simple to achieve, for example how IIRC
it was suggested from Intel's dir earlier .. by just adding a dict for
custom data in SOG/SOP or so. Adam's plan was also simple and AFAIK
realistic (he just didn't finish for other reasons). Melanie's plan I
actually haven't seen personally (other folks within reX started that
effort then).
This new proposal by mr. Adams I didn't fully comprehend yet, also
because don't know the code around Opensim's Scene's RegisterModule
interface etc. Did become curious and may take a look when have better
time :)
Quick comments to a couple of points there:
"get me the interface for extracting the physical mesh for this SOG"
In Tundra that is done by accessing entity.rigidbody, i.e. the
EC_RigidBody attached to that entity -- it just wraps Bullet. Basically
what you suggest, we just call them components instead of interfaces.
Wonderland calls them Capabilities (kind of makes sense too, is like a
feature you add to a scene entity .. mesh geom, sit target information,
light emitting values or whatever).
About serialization:
"Not sure of the nuances of serialization. I believe that the registered
interfaces would just be serialized with the SOG (thus saving and
restoring the values in the registered interface instances) but I can't
be totally sure of that."
That's what we do, just save all the data in the components of an entity
when the entity is saved. That is made with an attribute system which
supports opting out (you can mark things temporary so they don't get
saved). Same attribute system is used for the automated network sync.
~Toni
>
> On Fri, Dec 28, 2012 at 3:13 PM, James Hughes
> <jamesh at bluewallgroup.com> wrote:
> The original proposal to the dev list is here:
> http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html
>
> And the attached document here:
> https://lists.berlios.de/pipermail/opensim-dev/attachments/20091211/6e190ca7/attachment.pdf
>
> -BlueWall
>
>
> On 12/28/2012 02:24 PM, Adams, Robert wrote:
> Sounds perfect. The reason I started this here was to
> get the discussion bouncing.
>
> I'm interested in seeing past proposals. I searched
> around the OpenSimulator wiki looking for Adam's old
> proposal (Wiki's are just useless for finding and
> organizing things) but I could not find it.
>
> -- ra
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On
> Behalf Of Melanie
> Sent: Friday, December 28, 2012 10:59 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] IRegisterInterface for
> extending scene entities
>
> I suggest we bounce this about a bit and maybe
> cooperatively work on a test case/POC. That will
> certainly clarify issues. I could also pull out the
> prosal I did for ReX which deals with this
>
> Melanie
>
> On 28 Dec 2012, at 18:38, "Adams,
> Robert"<robert.adams at intel.com> wrote:
>
> I agree with "not reinventing the wheel". And
> your valid concerns about the implementation
> are probably just the tip of the iceberg.
>
> I have been toying with the architectural idea
> that OpenSim core only provides a basic
> framework. Functionalities are added as plugin
> modules rather than implemented as if's and
> tests imbedded in core. For instance, could
> linksets be implemented as a plugin module[1]?
> Or maybe entity physical representation
> (meshing)?
>
> I merely consider llSetKeyFrameMotion as a
> test case to expose needed core features which
> support plugin modules (Necessary events
> available? Correct data-structures
> exposed/hidden? ...) Like you, I am pretty
> sure the ability to programmatically extend
> scene entities will be needed and is a Good
> Thing.
>
> Since llSetKeyframeMotion has already been
> completed and will be incorporated soon, I'll
> look for another simple test case to exercise
> the requirements for full featured plugin
> modules.
>
> -- ra
>
> [1] Why would one want to do this? I've been
> thinking about fancy linksets where the joints
> are not fixed and static but could be
> parameterized and dynamic (hinges, sliders,
> 6DOF, ...). This could be used to support
> skeletons, doors with real hinges and/or weird
> and wonderful vehicles. Rather than mangling
> OpenSim core with lots of experimental code,
> it would be nice if I could build an
> "ExtendedLinksets" module that could be
> plugged in and experimented with.
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de]
> On Behalf Of Melanie
> Sent: Friday, December 28, 2012 12:44 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] IRegisterInterface
> for extending scene
> entities
>
> Hi,
>
> first off, extending scene entities is a Good
> Thing. I'll think a bit about the ins and outs
> of it and the caveats (for instance, module
> load order will have some hidden traps for the
> unwary) and serialization - well, there be
> dragons, you can't serialize module
> refs/interfaces since the destination may not
> have them.....
>
> llSetKeyfranedMotion can most likely not be
> implemented that way. We know, because we have
> implemented it. Also, there is no need to
> reinvent the wheel - llSetKeyframedMotion has
> been slated for core release for a while now,
> we just haven't found the dev time to extract
> it. So there is really no need for a second,
> competing implementation.
>
> So, in summary
>
> +1 on extension points for scene entities
>
> -0 on a second implementation of
> llSetKeyframedMotion as a tested and working
> one already exists.
>
> That's -0 because of you really want it I
> won't kee you from doing it - it's just a
> waste of effort.
>
> Melanie
>
> On 28/12/2012 08:38, Adams, Robert wrote:
> The discussion about the
> implementation of the llKeyframeMotion
> function hinted at a need for region
> modules to be able to add data and
> functions to existing scene items.
> Here is a modest proposal for
> discussion[1].
>
> Define a general module/interface
> registration interface to add to
> EntityBase (and thus to
> SceneObjectGroup and ScenePresence).
>
> IRegisterInterface
> Void
> RegisterInterface<T>(T iface);
> Bool TryGet<T>(out T
> iface);
> T Get<T>();
> Void
> ClearRegisteredInterfaces();
>
> Any class that implements the
> IRegisterInterface interface would
> contain a:
> Private
> Dictionary<Type, object>
> m_registeredInterfaces
> = new Dictionary<Type, object>();
>
> 'Scene' already has a RegisterModule
> interface which has a bunch of neat
> features (like being able to register
> multiple instances of the same
> interface type) but I'm not sure that
> is needed here (discussion?)
> Particularly industrious changing
> could merge this proposed interface
> and the existing 'Scene' functions.
>
> So, something like a llKeyframeMotion
> implementing region module could
> register a KeyframeMotionState type
> structure on the SOG to save
> information about the keyframe for
> that SOG. Other uses could be a
> uniform way for adding classes of
> functionality to scene objects ("get
> me the interface for extracting the
> physical mesh for this SOG") or just
> adding limpet like code to a scene
> entity.
>
> Not sure of the nuances of
> serialization. I believe that the
> registered interfaces would just be
> serialized with the SOG (thus saving
> and restoring the values in the
> registered interface instances) but I
> can't be totally sure of that.
>
> Anyway, run your sword through this
> strawman.
>
> -- ra
>
> [1] This is similar to other
> interfaced proposed in the past
> (particularly one by Adam Frizby).
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list