[Opensim-dev] Renaming innerscene
Justin Clark-Casey
jjustincc at googlemail.com
Thu Nov 6 16:15:21 UTC 2008
Michael Wright wrote:
> 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.
Personally, I'm happy to go with this - at the very least we need some way of making things more intelligible.
>
> */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
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list