[Opensim-dev] Renaming innerscene

Fri Nov 7 08:36:04 UTC 2008

I told you that it would end like this!   <--     random xkcd type statement

This section of code will steal your soul..   much like this EULA:
http://xkcd.com/501/

-Teravus

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