[Opensim-dev] IRegisterInterface for extending scene entities
Dahlia Trimble
dahliatrimble at gmail.com
Tue Jan 1 05:11:56 UTC 2013
The existing 2 level SOG/SOP concept may be a usable concept but it is far
from optimal for anything other than emulating SL as it appears to exist
*today*. There really is no forced 2-level hierarchy defined in the LLUDP
protocol from which much of OpenSimulator is modeled. In fact, the
existence parent id and local id in both root parts and child parts
suggests a underlying multi-level hierarchy and this suggests that SOG/SOP
may not adequately emulate what SL servers may be capable of doing.
If you're concerned that individual nodes in a tree each need to contain
all the properties that any other node need to contain, they really don't
have to. An "entity node" only need contain the properties and methods
which are common to all nodes, and a collection of "components", then the
other nodes can contain individual components which can really be anything
from executable code, collections of properties, generic objects, geometry,
even physics engine simulation instances. Often implementations will
include means for addressing and passing messages between entities in a
tree or even in different trees. There can even be a co-existing flat
collection of references to the tree entity nodes that can be used to speed
up addressing single nodes without having to traverse a tree or pass
messages around; i.e., receiving a network message or event destined to a
single node. In the SL/OpenSImulator model there may exist properties which
are used on a per-linkset basis however such properties could also be
stuffed into a "object properties collection object" and added to a entity
node in the form of a component.
I'll repeat what I've learned from my prototyping efforts: the
SL/OpenSimulator 2 level model can fit well into an entity-component design
and from there be extended into a more flexible system.
Unity3D uses an implementation of a entity-component architecture which
seems to be well regarded; perhaps it could serve as a reference.
On Mon, Dec 31, 2012 at 4:04 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:
> On 29/12/12 03:29, Dahlia Trimble wrote:
>
>> +2 on a hierarchical entity-component design. I have several prototype
>> servers and viewers implemented in various
>> languages which use variations of this architecture and I've found it to
>> be very efficient 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.
>>
>
> Yes, I think entity-component is the way forward. There's a good, basic
> introduction in Programming Gems 6 [1], as well as Toni's links. It would
> be interesting to see how this plays with region modules if this involves
> behaviour (the actions) as well as the data.
>
>
>
>> 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.
>>
>
> I strongly agree that POC for review with a high-level explanation is
> essential for this, building on other people's experience. Seeing
> Melanie's original ReX proposal would also be very good. We need to have
> agreement amongst ourselves on the general direction.
>
> I have no real game coding experience, but I don't think that the basic
> SOG/SOP entities are too bad of a foundation. I think something like a SOG
> is essential to hold attributes that only apply to the object as a whole -
> if every SOP has the required properties then you end up wasting memory,
> doing CPU busy work and having pointlessly confusing code.
>
> If you're referring to compatibility with the existing SOG/SOP properties
> and methods then I think that these should migrate over time. If all the
> existing stuff was left as 'legacy' code then it would be horribly crufty.
> Now is the time for change whilst OpenSimulator is still 'alpha' and none
> of the internals are a blessed API for region modules. We must increase
> flexibility otherwise we'll end up in a dead-end over the long term. But
> we must also always have a working simulator and take the community on the
> journey.
>
> I did create working code to save arbitrary data for SOPs in the
> dynamic-attributes branch which is in the opensimulator git repo. I don't
> think I got as far as serializing for across the wire transfer, though
> conceptually this shouldn't be too difficult for SOPs.
>
> I intended to use this for MOAP but never got around to it since I had
> already previously created hard-coded properties. However, that might be a
> good test case since all the MOAP logic is in region modules, with just a
> few properties stuck on SOP for data storage.
>
> We also need a similar mechanism for ScenePresence.
>
> [1] http://www.amazon.com/Game-**Programming-Gems-Book-CD-ROM/**
> dp/1584504501<http://www.amazon.com/Game-Programming-Gems-Book-CD-ROM/dp/1584504501>
>
>
>> On Fri, Dec 28, 2012 at 3:13 PM, James Hughes <jamesh at bluewallgroup.com<mailto:
>> jamesh at bluewallgroup.**com <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<http://lists.berlios.de/__pipermail/opensim-dev/2009-__December/008098.html>
>>
>> <http://lists.berlios.de/**pipermail/opensim-dev/2009-**
>> December/008098.html<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<https://lists.berlios.de/__pipermail/opensim-dev/__attachments/20091211/6e190ca7/__attachment.pdf>
>>
>> <https://lists.berlios.de/**pipermail/opensim-dev/**
>> attachments/20091211/6e190ca7/**attachment.pdf<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.__be**rlios.de<http://berlios.de><mailto:
>> opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>
>> >
>> [mailto:opensim-dev-bounces at __**lists.berlios.de<http://lists.berlios.de><mailto:
>> opensim-dev-bounces@**lists.berlios.de<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 <mailto:opensim-dev at lists.**
>> berlios.de <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<mailto:
>> 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.__be**rlios.de<http://berlios.de><mailto:
>> opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>
>> >
>> [mailto:opensim-dev-bounces at __**lists.berlios.de<http://lists.berlios.de><mailto:
>> opensim-dev-bounces@**lists.berlios.de<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 <mailto:opensim-dev at lists.**
>> berlios.de <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 <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev>
>> <https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>>
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>>
>>
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>> >
>>
>>
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**berlios.de<Opensim-dev at lists.berlios.de>
>> >
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<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<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> ______________________________**_________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20121231/7693dc5c/attachment-0001.html>
More information about the Opensim-dev
mailing list