[Opensim-dev] Renaming innerscene

Fri Nov 7 11:34:20 UTC 2008

+1 to what Stefan said
+1 to the even cosmetic renaming (cosmetics can add up!)
-1 to top posting! :)

Cheers,

On Fri, Nov 7, 2008 at 9:42 AM, 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
>
>