<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'>I actually have been thinking about border crossings a bit – the
current border crossing code forces us to a square region of 256x256 in
dimension – I’d actually like to remove that constraint at some point in the
future.<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'>I wouldn’t mind seeing that being triggered by a module TBH.<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>Michael
Wright<br>
<b>Sent:</b> Thursday, 6 November 2008 7:00 AM<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Renaming innerscene<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I totally agree that innerscene shouldn't call out to the
Scene. that was one of the things I was looking at when I wrote the original
email about how much confusion there is about what InnerScene is meant to be.<br>
<br>
Scene/Region should handle all uppper level functions and just call InnerScene
to add a new prim to the Scene, or delete a prim. About the only thing that
InnerScene needs to signal to a high level is border crossings. So that the
Scene/Region level code can communicate with the neghbouring Region.<br>
<br>
<b><i>Melanie <melanie@t-data.com></i></b> wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi,<br>
<br>
What I said.<br>
<br>
Look at the flow I illustrated. It should really be:<br>
<br>
Caller calls Region:A<br>
Region:A calls Scene:B<br>
Region:A does region things with the return from Scene:B<br>
Region:A returns<br>
<br>
No need to dip into Scene (current innerscene) twice. No need for ti <br>
to call out to Region (current Scene).<br>
<br>
I would even go as far as saying that, if a method in InnerScene <br>
needs to call a method in Scene, then it doesn't belong into <br>
InnerScene in the first place.<br>
<br>
Melanie<br>
<br>
Michael Wright wrote:<br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Justin Clark-Casey wrote: Heh, InnerScene has always confused me too -
interesting to find out that nobody remembers what it was for (as Alan <br>
> alluded to, this shows the value of writing embedded class level code
documentation ;)<br>
> <br>
> I agree with Melanie - I feel that ultimately a split into functional
units would be better than having two classes, one <br>
> containing all region related information and one providing scene
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 is that
the first provides the core simulation <br>
> services while the latter consists of metadata (e.g. which region the
scene represents). If there was a separate region <br>
> class, I'm not convinced that there would be very much in it, beyond 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 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
[mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Michael 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 scene
handling code into its own class, rather than having it mixed in with more
region level code, like rezzing/inventory handling.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<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>
> <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<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p> <o:p></o:p></p>
</div>
</div>
</body>
</html>