<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-AU link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It’s in the PDF attached to the original post – basically we
merge SceneObjectGroup+Part together; then make it possible to chain them
directly.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>IE:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>SceneObject.Parent<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>SceneObject.Children[]<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Then you can represent hierarchies by making a group a parent of
another group.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Adam<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>Morgaine<br>
<b>Sent:</b> Saturday, 19 December 2009 12:36 AM<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing
Components<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <<a
href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>> wrote: <o:p></o:p></p>
<div>
<div>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Enable full inheritance & linking (ie, hierarchical linking)<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
This is terrific news, Adam!<br>
<br>
There's a bunch of us who have been "hierarchical object activists"
in SL for some years, regularly trying to get the benefits of hierarchical
objects across to Linden developers at their Office Hours. We have a wiki
page on <a href="https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy">Prim
and Object Hierarchy</a> , and a number of Jiras also address the issue,
including <a href="http://jira.secondlife.com/browse/MISC-428">MISC-428</a>, <a
href="http://jira.secondlife.com/browse/MISC-1434">MISC-1434</a>, and <a
href="http://jira.secondlife.com/browse/MISC-2237">MISC-2237</a>.<br>
<br>
We've been successful <i>on the principle</i> (several LL devs now support it
wholeheartedly) but not in practice, because the development process within the
Labs appears to be quite logjammed and stifled so that individual developer
opinion has no effect. As noted on the wiki page above though, Lindens <i>know</i>
that they made a mistake in not supporting object hierarchy. They just
can't do anything about it now.<br>
<br>
Hierarchical objects provide many different types of benefit, so you'll hear
different people advocate different aspects about them, but they're all
complementary. My angle stems from the needs of pure engineering, in that
hierarchical object composition is the basis of all engineered products in
RL. Almost everything in modern life is manufactured by putting together <i>complex
components</i>, not from raw materials, and that's how you ride on the
shoulders of giants. You can't do that in SL.<br>
<br>
It's wonderful to see hierarchical objects finally gaining in profile in
Opensim. Is there a design for this?<br>
<br>
We've been examining the pro's and con's of various approaches, including
evolutionary ones that extend the current very poor linkset paradigm, as well
as new designs that either encapsulate linksets transparently or else create a
completely new and separate hierarchical object system in parallel with the
current non-hierarchical one. Each approach has its own advantages and
disadvantages.<br>
<br>
More info on your current thinking would be very welcome. Designs tend to
stick around for longer than planned, and getting it partially right from the
start would be a good idea.<br>
<br>
Morgaine.<br>
<br>
<br>
<br>
<br>
==============================<o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam <<a
href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi
Folks,<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I’ve
got a fairly complicated proposal to deliver here today – the short of it is;
I’d like to go ahead and replace the current Scene Object representation model
– at a fairly comprehensive & complete level. Some of you have had the
misfortune of working with SceneObjectPart/SceneObjectGroup and should
understand what I am talking about.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There
are several stages to this proposal – but I would like to talk about today the
first big one (and a small outline of the larger project – the reason for this
being some of the later details require a little more nutting out before I have
a complete proposal for them).<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So
– the larger proposal in a nutshell; I would like to:<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Merge SceneObjectGroup & SceneObjectPart<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Enable full inheritance & linking (ie, hierarchical linking)<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Make programming with SceneObjects possible & reasonable from the
outside (ie have a clean API).<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Provide the ability to extend SceneObjects with “components” to
introduce new properties and behaviours.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The
item I’d like to talk about today would be implementing Components. Components
are small C# classes that may be attached to any SceneObject arbitrarily. <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>A
component is any class inheriting from IComponent – IComponent carries only two
properties; a serialisation property (returns the current ‘state’ for
serialisation purposes), and a type property (which recognises the ‘type’ of
component that it is) – components allow you to attach arbitrary data to an
object for the purposes of interacting with a region module. For instance, a
“Mesh” module (which is my current best example) would have a MeshComponent
that included all the extra data to tag an object with related to meshes –
which would get serialised and passed around with the main object. When
deserialized – a “Factory” handles making sure the MeshComponent is
deserialized with the main object.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I’ve
attached a document which is my current state of the whole proposal which
includes some examples & more detail. Please note that Phase 2 is not
finalised yet – and some decisions were discussed about changing two facets in
particular.<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Enabling inheritance of components+sceneobject to make speedy-classes
for common use cases (eg PrimObject inherits PrimComponent and SceneObject)<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Allowing more than one factory potentially; for manufacturing said
speedy-classes.<o:p></o:p></p>
<p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>
</span>Note that these shorthand classes would still use the standard .Has /
.Get methods; they would just return ‘this’ where the particular component type
is concerned.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>To
begin with – I would like to implement components as an extra non-serialised
property of the SceneObjectPart; this will occur very shortly after 0.7 is
tagged; which I would like to do once ROBUST covers all the main services (I
heard something about late-december/early-jan); this first stage should not
break anything in particular – however once that Is complete, I would like to
migrate properties into components in order to modularised the codebase better.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>An
example of this would be PrimData – primdata is unique to the Second Life use
case, and irrelevant to others; in this case, we’ll move PrimData into a
commonly accessed component (eg “SceneObject.Get<PrimData>.Hollow =
0.9f;”) – once the move to components is complete for the common data; then
creating the final SceneObject class which merges SceneObjectGroup+Part should
be a fairly painless process.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Please
take a read of the document attached for more information – and I am very keen
to hear anyones thoughts as to use cases that this model will make more
difficult; or could not support. The goal with this project is to make OpenSim
support more with less – allowing third party modules to really take OpenSim as
a framework to the next level; and make a more modular server for other clients
& platforms.<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks!<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#888888'>Adam<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>