<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Actually, the innerscene vs scene bit was a step in the 'right' direction given that at the time we were trying to move to a better MVC separation. In the beginning, everything was a tangly mess, and classes couldn't be used for anything but the context they were coded for. Slowly, we've been inching away from that, so that we can re-use components for other contexts.<BR>
<BR>
The goal is to be able to have a full SceneGraph class family that could be used for data manipulation of an OpenSim region without actually running a region. This is a need we've run into on several occasions, especially when modifying/transferring content.<BR>
<BR>
And regarding the sog/sop - it makes sense to have a common baseclass, the 'object' but it also makes GREAT sense to have differentiated behaviours depending on context.<BR>
<BR>
Again, the scene model that is expressed in the SL Protocol, and the non-normalized transfer of data is perfectly good for an application, but not for a platform. We need better API:s than what would be rendered into any protocol.<BR><BR>
Regarding the InnerScene calling the Scene, that is probably a case that should have been solved with events firing instead - OR move the parts in InnerScene that depended on information in Scene out to Scene.<BR>
<BR>
So,<BR>
+1 on keeping, and deepining the Scene (Scene Controller) vs InnerScene (Scene Model) divide.<BR>
+1 on thinking MVC and layered separation.<BR>
+1 on re-viewing the SOG/SOP<BR>
+1 on having a base class SceneObject<BR>
+1 on having a clean API that lets code add and interact with object in an intelligble and straightforward manner, with no request for implicit and auxiliary knowledge about object state.<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/">http://tribalnet.se/</A><BR> <BR><BR><BR><BR><BR>> Date: Thu, 6 Nov 2008 17:02:26 +0000<BR>> From: melanie@t-data.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] Renaming innerscene<BR>> <BR>> Precisely. Let's not perpetuate SOG that locks us into the SL model <BR>> forever. New viewers are emerging as we speak and the potential for <BR>> bugs like the ones you allude to can be minimized. Where sensible, <BR>> any call to a "group" type method on a child can be made to act on <BR>> the group, so that "group move", for instance, can be done using any <BR>> object in the group, rather than looking up the root first. Also, <BR>> every child prim can indeed be delinked separately - why not? SL <BR>> doesn't support it, but we can. Other viewers can. I see that, <BR>> though i have been bashed for being too sl centric, i see more sl <BR>> centric thinking in here than mine. Let's do the sensible thing and <BR>> dump SOG, R.I.P.<BR>> <BR>> Melanie<BR>> <BR>> <BR>> Justin Clark-Casey wrote:<BR>> > Michael Wright wrote:<BR>> >> Yeah I don't care what base class the actual link/etc code goes in. Just <BR>> >> meant there should be some seperation of the levels. So I was actually <BR>> >> thinking of SceneObjectGroup as part of the InnerScene level and not at <BR>> >> this point really concerned which class has which functions.<BR>> >> <BR>> >> And with SceneObjectPart I believe the general opinion of just about <BR>> >> everyone is that we should get rid of it and just have SceneObjects.<BR>> > <BR>> > I dunno, I'll confess that I'm not 100% convinced. Certainly in Second Life setup there are some things you can do to <BR>> > objects as a whole which it's not sensible to do for individual prims/objects within the group. If a scene object is <BR>> > just a hierarchy of objects, then there may be potential for bugs which wouldn't occur if the non-root objects didn't <BR>> > have all the methods of the 'root' scene object.<BR>> > <BR>> > For example, if you attach an object, then it doesn't make sense to be able to go and detach individual child objects <BR>> > without first delinking the whole group. The SOG can enforce this by only exposing attach methods at that level (even <BR>> > though it effectively doesn't at the moment). A tree of SOPs where every SOP has public attach methods cannot enforce <BR>> > this so easily. Perhaps this is a constraint that should be somehow policed separately from a core scene object model.<BR>> > <BR>> > I also understand the argument that having a scene object be a hierarchy of objects might make multi-level linking (as <BR>> > opposed to Second Life's single level of linking), easier.<BR>> > <BR>> >> <BR>> >> */"Frisby, Adam" <adam@deepthink.com.au>/* wrote:<BR>> >> <BR>> >> I actually think that linking/etc probably doesn’t belong in scene.<BR>> >> <BR>> >> Rather – it belongs in SceneObjectGroup – I actually think that<BR>> >> SceneObjectPart doesn’t belong in Scene either.<BR>> >> <BR>> >> Eg:<BR>> >> <BR>> >> InnerScene -> IEntity[]<BR>> >> <BR>> >> IEntity[] += SceneObjectGroup<BR>> >> <BR>> >> SceneObjectGroup Parts[];<BR>> >> <BR>> >> We do the conversions/etc in LLClientView and other clientstacks<BR>> >> which support a IClientPrimitive interface.<BR>> >> <BR>> >> Adam<BR>> >> <BR>> >> <BR>> >> *From:* opensim-dev-bounces@lists.berlios.de<BR>> >> [mailto:opensim-dev-bounces@lists.berlios.de] *On Behalf Of *Michael<BR>> >> Wright<BR>> >> *Sent:* Thursday, 6 November 2008 8:01 AM<BR>> >> *To:* opensim-dev@lists.berlios.de<BR>> >> *Subject:* Re: [Opensim-dev] Renaming innerscene<BR>> >> <BR>> >> Well parts of the Linking /attaching code would need to be in there.<BR>> >> The code to actually connect the prims. But the actually handling of<BR>> >> the client commands and anything above the actual connect commands<BR>> >> should be in the Region level. Like with attachments if we update<BR>> >> the attachment db list, that should be handled in the Region level.<BR>> >> <BR>> >> Same with Rezzing a object. There would be a base command in the<BR>> >> InnerScene to add a new prim(s), but the handling of the Client<BR>> >> command, and the fetching of the Prim data from Inventory would be a<BR>> >> higher level function.<BR>> >> <BR>> >> So I just mean we should keep the very base level of functionality<BR>> >> related to the 3D objects in the InnerScene. And anything above that<BR>> >> should be in a high level.<BR>> >> <BR>> >> */Justin Clark-Casey <jjustincc@googlemail.com>/* wrote:<BR>> >> Michael Wright wrote:<BR>> >> > Well I think the plan/design was always meant to be based on<BR>> >> functional<BR>> >> > units. Region/current Scene was never meant to be a metadata wrapper<BR>> >> > around InnerScene. It was meant to contain high level functions,<BR>> >> at the<BR>> >> > region level. Like rezzing a object/ derezzing a object. Linking<BR>> >> > objects, attaching objects to a Avatar. I wouldn't class those as<BR>> >> base<BR>> >> > scene level functions. And they can be seperated however we want.<BR>> >> <BR>> >> So what kind of things would be in InnerScene/SceneGraph, if not<BR>> >> things link linking/delink and attachment/detachment<BR>> >> (both of which are there at the moment)? I'm not that familiar with<BR>> >> exactly what one would normally expect to be in a<BR>> >> scene graph, coming as I do from an enterprise programming environment.<BR>> >> <BR>> >> ><BR>> >> > I just firmly believe we should have a base layer that has the<BR>> >> > functionality that is focused on the 3D and sending/receiving<BR>> >> clients<BR>> >> > related to the movement of objects in the scene.<BR>> >> ><BR>> >> > */Justin Clark-Casey /* wrote:<BR>> >> ><BR>> >> > Heh, InnerScene has always confused me too - interesting to find out<BR>> >> > that nobody remembers what it was for (as Alan<BR>> >> > alluded to, this shows the value of writing embedded class level<BR>> >> > code documentation ;)<BR>> >> ><BR>> >> > I agree with Melanie - I feel that ultimately a split into<BR>> >> > functional units would be better than having two classes, one<BR>> >> > containing all region related information and one providing scene<BR>> >> > services. Especially if the outer class just wraps<BR>> >> > the inner classes' methods (but I suspect that wouldn't be the plan).<BR>> >> ><BR>> >> > I assume that the conceptual difference between scene and a region<BR>> >> > is that the first provides the core simulation<BR>> >> > services while the latter consists of metadata (e.g. which region<BR>> >> > the scene represents). If there was a separate region<BR>> >> > class, I'm not convinced that there would be very much in it, beyond<BR>> >> > what is already in RegionInfo.<BR>> >> ><BR>> >> ><BR>> >> > Melanie wrote:<BR>> >> > > As one who has spent a lot of time in InnerScene with the local<BR>> >> > > dragons, I see that in lots of cases, even having it InnerScene at<BR>> >> > > all complicates things horrendously.<BR>> >> > > There are actions that change between Scene and InnerScene 4 times<BR>> >> > > to get the job done. That could be done much more efficiently if<BR>> >> > > those methods were combined and then split up into functional<BR>> >> units,<BR>> >> > > rather than "3d" scoped.<BR>> >> > ><BR>> >> > > One flow I found was like this:<BR>> >> > ><BR>> >> > > Caller calls Scene:A<BR>> >> > > Scene:A calls InnerScene:A<BR>> >> > > Scene:A calls Scene:B<BR>> >> > > Scene:A calls InnerScene:C<BR>> >> > > InnerScene:C calls Scene:C<BR>> >> > > Scene:A returns.<BR>> >> > ><BR>> >> > > This is overcomplex and baffling to new coders. I am not surprised<BR>> >> > > that many people choose not to touch it.<BR>> >> > ><BR>> >> > > Needless to say, I removed the above flow and made it into a single<BR>> >> > > call into InnerScene. It was part of attachment rezzing. When i did<BR>> >> > > that, I streamlined that flow.<BR>> >> > ><BR>> >> > > I believe InnerScene and Scene should not be separate, or not be<BR>> >> > > separated along the line they are separated now.<BR>> >> > ><BR>> >> > > On the name, I don't really care.<BR>> >> > ><BR>> >> > > +-0 there.<BR>> >> > ><BR>> >> > > Melanie<BR>> >> > ><BR>> >> > ><BR>> >> > > Frisby, Adam wrote:<BR>> >> > >> +1'ing,<BR>> >> > >><BR>> >> > >> I had no idea what InnerScene was for myself.<BR>> >> > >><BR>> >> > >> Adam<BR>> >> > >><BR>> >> > >> From: opensim-dev-bounces@lists.berlios.de<BR>> >> > [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Michael<BR>> >> > Wright<BR>> >> > >> Sent: Thursday, 6 November 2008 5:22 AM<BR>> >> > >> To: opensim-dev@lists.berlios.de<BR>> >> > >> Subject: [Opensim-dev] Renaming innerscene<BR>> >> > >><BR>> >> > >> A long time ago, we started the process of separating the 3d<BR>> >> > scene handling code into its own class, rather than having it mixed<BR>> >> > in with more region level code, like rezzing/inventory handling.<BR>> >> > >><BR>> >> > >> It was always planned to renamed the InnerScene and Scene<BR>> >> > classes, once this separation of the 3d scene graph code was<BR>> >> > completed. The original plan being that Scene became Region (or<BR>> >> > something like that) and InnerScene changed to Scene.<BR>> >> > >><BR>> >> > >> It might be a bit to much work to rename the Scene class at this<BR>> >> > stage. But what are everyone thoughts on renaming InnerScene to<BR>> >> > something like SceneGraph.<BR>> >> > >><BR>> >> > >> I think the InnerScene class is one of the more confusing areas<BR>> >> > as a lot new coders aren't really aware what design role it is meant<BR>> >> > to play.<BR>> >> > >><BR>> >> > >><BR>> >> > >><BR>> >> > >><BR>> >> > >><BR>> >> > >><BR>> >> ><BR>> >> ------------------------------------------------------------------------<BR>> >> > >><BR>> >> > >> _______________________________________________<BR>> >> > >> Opensim-dev mailing list<BR>> >> > >> Opensim-dev@lists.berlios.de<BR>> >> > >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> > > _______________________________________________<BR>> >> > > Opensim-dev mailing list<BR>> >> > > Opensim-dev@lists.berlios.de<BR>> >> > > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> > ><BR>> >> ><BR>> >> ><BR>> >> > --<BR>> >> > justincc<BR>> >> > Justin Clark-Casey<BR>> >> > http://justincc.wordpress.com<BR>> >> > _______________________________________________<BR>> >> > Opensim-dev mailing list<BR>> >> > Opensim-dev@lists.berlios.de<BR>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> ><BR>> >> ><BR>> >> ><BR>> >> ><BR>> >> ------------------------------------------------------------------------<BR>> >> ><BR>> >> > _______________________________________________<BR>> >> > Opensim-dev mailing list<BR>> >> > Opensim-dev@lists.berlios.de<BR>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> <BR>> >> <BR>> >> -- <BR>> >> justincc<BR>> >> Justin Clark-Casey<BR>> >> http://justincc.wordpress.com<BR>> >> _______________________________________________<BR>> >> Opensim-dev mailing list<BR>> >> Opensim-dev@lists.berlios.de<BR>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> <BR>> >> <BR>> >> _______________________________________________<BR>> >> Opensim-dev mailing list<BR>> >> Opensim-dev@lists.berlios.de<BR>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >> <BR>> >> <BR>> >> <BR>> >> ------------------------------------------------------------------------<BR>> >> <BR>> >> _______________________________________________<BR>> >> Opensim-dev mailing list<BR>> >> Opensim-dev@lists.berlios.de<BR>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > <BR>> > <BR>> <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>