Re: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"

[Dirk Krause]

... or someone hacks SkyBox support into the Hippo viewer.

Which brings me to the question, is there a place to share 'beyond SL' ideas? 
Are they welcome at all?

I could think of some features that add to the SL-like experience (like the 
above).



-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Dahlia Trimble
Gesendet: Mo 26.01.2009 08:58
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"
 
They look like they could be used for a skybox or a skydome, but I don't
think those work too well in SL unless the client draw distance is set
sufficiently high.

On Sun, Jan 25, 2009 at 11:47 PM, Stefan Andersson wrote:

>  Americo,
>
> do I understand it correctly that these beautiful images are to be used as
> textures on 'wall' prims around an island estate?
>
> Something that might also be of interest, is that a prim can be much larger
> than a region (anybody knows exactly how big?) so a horizon texture could,
> in theory span say 768 metres. Which might yield some interesting effects,
> especially if the horizon is wide-lensed and the avatar is prohibited from
> walking closer to the horizon than say 100 metres.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
> --
>
> From: adama...@hotmail.com
> To: opensim-dev@lists.berlios.de
> Date: Sun, 25 Jan 2009 08:04:47 -0300
> Subject: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"
>
>  I need to confess that the first time I saw "horizons" beeing used in
> OpenSim was by Cristina and I did a big  mistake,  erasing her   panels.
> Trying to compensate this, I am presenting, for download, some "horizons"
> that an old friend, an artist from UK (S. Nectar) made, some years ago, for
> Croquet and are public. The idea of "horizons" is to avoid the "island
> paradigma".
>
> If you are not understanding anything, download the images and take a
> look.  May be, could be created an easy way for the use of "horizons" in
> OpenSim worlds having only one region.
>
> The address for download is:
>
> http://www.dmu.com/croquet2/SNHorizons.zip
>
> Sorry again, Cristina. I promess that I will not to do something like I did
> again.
>
> Americo
>
>
>
>
> --
>
> check out the rest of the Windows LiveT. More than mail-Windows LiveT goes
> way beyond your inbox. More than 
> messages
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

<>___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Source tree cleanup

[Mike Mazur]

Hi,

On Mon, 26 Jan 2009 10:56:31 +0900
Jeff Ames  wrote:

> There are a few dusty corners in trunk from before
> forge.opensimulator.org was up, but I was wondering about moving them
> over, or merging them with core.
> 
> [...]
> 
> * ThirdParty/*
> 
>   Could these either be merged into the OpenSim namespace or moved to
>   forge?

Either Johan or I will move the Load Balancer code to forge later this
week.

Thanks!
Mike
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Proposal: Removal of the Data Framework

[Stefan Andersson]

As I understand it, we have no longer anything actually using the Data Mapper 
Framework introduced as a proposed alterantive to NHibernate a year ago.
 
I propose we now retire that piece of code. These are the projects that will be 
removed:
 
* OpenSim.Data.MySQLMapper
* OpenSim.Data.MSSQLMapper
* OpenSim.Data.Base
In OpenSim.Data, the following classes would be removed:
* OpenSimDatabaseConnector.cs
* OpenSimDataReader.cs
* OpenSimObjectFieldMapper.cs* PrimitiveBaseShapeTableMapper.cs
 
Also, the AvatarFactoryModule erroneously still references these namespaces, 
but that's a minor fix.
 
If nobody has a strong objection, I will start removing these files Feb 2 2009.
Best regards,Stefan AnderssonTribal Media AB___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Regions larger then 256x256

[Teravus Ovares]

Hey all,

I've been thinking about this supposed limitation of 256x256m sized
regions because of the recent discussion on integrating GIS data with
it and I wanted to discuss all of the known limitations, mitigating
factors, and potentially some solutions to dealing with this.

Now, from what I understand, the Linden client only really knows about
256x256.   However, also, so far, the only two things that I've found
that really make use of that limitation is terrain, and maptiles.
The terrain system is designed in such a way that it makes a region
have 256x256m split into 16x16 blocks and therefore there's only space
for that. Map Blocks just assume 256x256.Mind you, the client
also seems to use it for caching the terrain and objects as well, so
it really shouldn't change whatever it is or the client will have an
issue

Now, the kicker is object positions, avatar positions, textures,
border crossings and just about everything else *doesn't care about
256x256 on the client side*.The rest of the 256x256 limitations
are in the service.

So, solutions..

Now, technically, it's possible to make a region 512x512 and have it
generate 4 maptiles and 3 'psudo regions' in the client stack..  the
psudo regions would simply be 'terrain senders' and 'terrain update'
mechanisms..   and that would work!

Any thoughts on this?

Best Regards

Teravus
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Proposal: Killing off AvatarFactory

[Stefan Andersson]

It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that 
really just look up the CommsManager AvatarService and forwards a request to 
that.
I propose we either modularize the whole thing (the prefferrable thing) or 
merge the AvatarFactory module code into the IAvatarService.
 
If nobody has objected strongly until Jan 2 2009, I will mantis this.
Best regards,Stefan AnderssonTribal Media AB___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Ryan McDougall]

On Mon, Jan 26, 2009 at 10:13 AM, Stefan Andersson
 wrote:
> It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that
> really just look up the CommsManager AvatarService and forwards a request to
> that.
>
> I propose we either modularize the whole thing (the prefferrable thing) or
> merge the AvatarFactory module code into the IAvatarService.
>
> If nobody has objected strongly until Jan 2 2009, I will mantis this.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB

+1 to the general house-cleaning effort!

Hiphip-hurrah!

Cheers,
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Teravus Ovares]

Ryan.. all about house cleaning. :)


On 1/26/09, Ryan McDougall  wrote:
> On Mon, Jan 26, 2009 at 10:13 AM, Stefan Andersson
>  wrote:
> > It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that
> > really just look up the CommsManager AvatarService and forwards a request to
> > that.
> >
> > I propose we either modularize the whole thing (the prefferrable thing) or
> > merge the AvatarFactory module code into the IAvatarService.
> >
> > If nobody has objected strongly until Jan 2 2009, I will mantis this.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
>
> +1 to the general house-cleaning effort!
>
> Hiphip-hurrah!
>
> Cheers,
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Stefan Andersson]

Teravus,
 
you're revisiting our old, old, vision of having a many-to-many between scenes 
and regions, I think. (Where regions would be the IP endpoints, and the scene 
the graph)
 
If I understand you correctly, we would separate region from scene, letting the 
regions manage their bit of terrain, but having one region have a 'scene' that 
was 768x768, centered on the mid 'region'.
 
(Btw, can you terraform in a neighbour region? If not, a hacked setup might be 
a bit cumbersome to administrate)
 
So, the physics engine would communicate with the scene, but something would 
have to 'route' scene updates to the right scenepresence (avatar to the root, 
terrain to the right child). 
 
And if it does, as all presences are 'root' presences today (as per an earlier 
post by Diva) I think that that would mean we are on our way towards a _true_ 
(as in 'not a one-off hack') many-to-many scene/region relationship.
Which I believe could seriously rock, eventually.
And yes, in the 'hack' version, you would have to disable the moving the avatar 
and objects between regions bit.
Best regards,Stefan AnderssonTribal Media AB
> Date: Mon, 26 Jan 2009 03:11:51 -0500> From: tera...@gmail.com> To: 
> opensim-dev@lists.berlios.de> Subject: [Opensim-dev] Regions larger then 
> 256x256> > Hey all,> > I've been thinking about this supposed limitation of 
> 256x256m sized> regions because of the recent discussion on integrating GIS 
> data with> it and I wanted to discuss all of the known limitations, 
> mitigating> factors, and potentially some solutions to dealing with this.> > 
> Now, from what I understand, the Linden client only really knows about> 
> 256x256. However, also, so far, the only two things that I've found> that 
> really make use of that limitation is terrain, and maptiles.> The terrain 
> system is designed in such a way that it makes a region> have 256x256m split 
> into 16x16 blocks and therefore there's only space> for that. Map Blocks just 
> assume 256x256. Mind you, the client> also seems to use it for caching the 
> terrain and objects as well, so> it really shouldn't change whatever it is or 
> the client will have an> issue> > Now, the kicker is object positions, avatar 
> positions, textures,> border crossings and just about everything else 
> *doesn't care about> 256x256 on the client side*. The rest of the 256x256 
> limitations> are in the service.> > So, solutions..> > Now, technically, it's 
> possible to make a region 512x512 and have it> generate 4 maptiles and 3 
> 'psudo regions' in the client stack.. the> psudo regions would simply be 
> 'terrain senders' and 'terrain update'> mechanisms.. and that would work!> > 
> Any thoughts on this?> > Best Regards> > Teravus> 
> ___> Opensim-dev mailing list> 
> Opensim-dev@lists.berlios.de> 
> https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Ryan McDougall]

HA! Tell that to the pile of empties in my kitchen!

On Mon, Jan 26, 2009 at 10:25 AM, Teravus Ovares  wrote:
> Ryan.. all about house cleaning. :)
>
>
> On 1/26/09, Ryan McDougall  wrote:
>> On Mon, Jan 26, 2009 at 10:13 AM, Stefan Andersson
>>  wrote:
>> > It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that
>> > really just look up the CommsManager AvatarService and forwards a request 
>> > to
>> > that.
>> >
>> > I propose we either modularize the whole thing (the prefferrable thing) or
>> > merge the AvatarFactory module code into the IAvatarService.
>> >
>> > If nobody has objected strongly until Jan 2 2009, I will mantis this.
>> >
>> > Best regards,
>> > Stefan Andersson
>> > Tribal Media AB
>>
>> +1 to the general house-cleaning effort!
>>
>> Hiphip-hurrah!
>>
>> Cheers,
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Stefan Andersson]

In the beginning of OpenSim, I went under the nickname 'the housekeeper'. Nice 
to see people are taking over.
 
* hands over the broom *Best regards,Stefan AnderssonTribal Media AB> Date: 
Mon, 26 Jan 2009 03:25:48 -0500> From: tera...@gmail.com> To: 
opensim-dev@lists.berlios.de> Subject: Re: [Opensim-dev] Proposal: Killing off 
AvatarFactory> > Ryan.. all about house cleaning. :)> > > On 1/26/09, Ryan 
McDougall  wrote:> > On Mon, Jan 26, 2009 at 10:13 AM, 
Stefan Andersson> >  wrote:> > > It's kind of crazy that 
we have a RegionModule (AvatarFactoryModule) that> > > really just look up the 
CommsManager AvatarService and forwards a request to> > > that.> > >> > > I 
propose we either modularize the whole thing (the prefferrable thing) or> > > 
merge the AvatarFactory module code into the IAvatarService.> > >> > > If 
nobody has objected strongly until Jan 2 2009, I will mantis this.> > >> > > 
Best regards,> > > Stefan Andersson> > > Tribal Media AB> >> > +1 to the 
general house-cleaning effort!> >> > Hiphip-hurrah!> >> > Cheers,> > 
___> > Opensim-dev mailing list> > 
Opensim-dev@lists.berlios.de> > 
https://lists.berlios.de/mailman/listinfo/opensim-dev> >> 
___> Opensim-dev mailing list> 
Opensim-dev@lists.berlios.de> 
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Dahlia Trimble]

anyone ever tried creating a larger region just to see what would happen?

On Mon, Jan 26, 2009 at 12:11 AM, Teravus Ovares  wrote:

> Hey all,
>
> I've been thinking about this supposed limitation of 256x256m sized
> regions because of the recent discussion on integrating GIS data with
> it and I wanted to discuss all of the known limitations, mitigating
> factors, and potentially some solutions to dealing with this.
>
> Now, from what I understand, the Linden client only really knows about
> 256x256.   However, also, so far, the only two things that I've found
> that really make use of that limitation is terrain, and maptiles.
> The terrain system is designed in such a way that it makes a region
> have 256x256m split into 16x16 blocks and therefore there's only space
> for that. Map Blocks just assume 256x256.Mind you, the client
> also seems to use it for caching the terrain and objects as well, so
> it really shouldn't change whatever it is or the client will have an
> issue
>
> Now, the kicker is object positions, avatar positions, textures,
> border crossings and just about everything else *doesn't care about
> 256x256 on the client side*.The rest of the 256x256 limitations
> are in the service.
>
> So, solutions..
>
> Now, technically, it's possible to make a region 512x512 and have it
> generate 4 maptiles and 3 'psudo regions' in the client stack..  the
> psudo regions would simply be 'terrain senders' and 'terrain update'
> mechanisms..   and that would work!
>
> Any thoughts on this?
>
> Best Regards
>
> Teravus
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"

[Teravus Ovares]

Yes, welcome, so long as they don't break what is there :)

On 1/26/09, Dirk Krause  wrote:
> ... or someone hacks SkyBox support into the Hippo viewer.
>
> Which brings me to the question, is there a place to share 'beyond SL' ideas? 
> Are they welcome at all?
>
> I could think of some features that add to the SL-like experience (like the 
> above).
>
>
>
> -Ursprüngliche Nachricht-
> Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Dahlia Trimble
> Gesendet: Mo 26.01.2009 08:58
> An: opensim-dev@lists.berlios.de
> Betreff: Re: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"
>
> They look like they could be used for a skybox or a skydome, but I don't
> think those work too well in SL unless the client draw distance is set
> sufficiently high.
>
> On Sun, Jan 25, 2009 at 11:47 PM, Stefan Andersson 
> wrote:
>
> >  Americo,
> >
> > do I understand it correctly that these beautiful images are to be used as
> > textures on 'wall' prims around an island estate?
> >
> > Something that might also be of interest, is that a prim can be much larger
> > than a region (anybody knows exactly how big?) so a horizon texture could,
> > in theory span say 768 metres. Which might yield some interesting effects,
> > especially if the horizon is wide-lensed and the avatar is prohibited from
> > walking closer to the horizon than say 100 metres.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> > --
> >
> > From: adama...@hotmail.com
> > To: opensim-dev@lists.berlios.de
> > Date: Sun, 25 Jan 2009 08:04:47 -0300
> > Subject: [Opensim-dev] "Horizons" (panels) and a public "I am sorry"
> >
> >  I need to confess that the first time I saw "horizons" beeing used in
> > OpenSim was by Cristina and I did a big  mistake,  erasing her   panels.
> > Trying to compensate this, I am presenting, for download, some "horizons"
> > that an old friend, an artist from UK (S. Nectar) made, some years ago, for
> > Croquet and are public. The idea of "horizons" is to avoid the "island
> > paradigma".
> >
> > If you are not understanding anything, download the images and take a
> > look.  May be, could be created an easy way for the use of "horizons" in
> > OpenSim worlds having only one region.
> >
> > The address for download is:
> >
> > http://www.dmu.com/croquet2/SNHorizons.zip
> >
> > Sorry again, Cristina. I promess that I will not to do something like I did
> > again.
> >
> > Americo
> >
> >
> >
> >
> > --
> >
> > check out the rest of the Windows LiveT. More than mail-Windows LiveT goes
> > way beyond your inbox. More than 
> > messages
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Dr Scofield]

Paul Fishwick wrote:
> People do a lot of web-browsing and perhaps anon accounts will help better
> integrate opensim with the web. Consider the following:
> 
>  1. Someone is browsing the web for a topic such as "red wine"
>  2. They get to various wine distributor and vineyard web pages
>  3. They find out that one of the vineyards has a "hot link" to a 3D space
>  4. They click on it and find themselves in the opensim world for the 
> vineyard
> 
> We need to find ways of making it easier, and more transparent, to go 
> between
> #2 and #4. It may be that a stepping-stone is required such as Xenki, 
> which is
> browser embedded (before launching a full-blown viewer).
> 
> Anon accounts may help because it is similar to unrestricted web browsing.
> And, these accounts may ease the transition between #2 and #4, and thus
> grow the metaverse.
> 

interesting thoughts. we could give anonymous guests black and white avatars :-)

i like the idea of a randomly chosen first (or last) name. we could even
integrate that with gridinfo and the rezzme URI scheme and protocol handlers: a
rezzme URI such as

rezzme://anonymous%20anonym...@vineyard.com:9000/merlot/

could obtain as part of the mandatory gridinfo retrieval from vineyard.com:9000
also obtain an anonymous user name generated by the grid and the client would
then use that as the avatar name; for example, vineyard.com's gridinfo might 
return

Joe Anonymous

the restriction on the anonymous user class would be as specified (and they'd
get a black & white avatar :-)

cheers,
DrS/dirk

-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Dr Scofield]

Charles Krinke wrote:
> Overweight tourist with a camera like There.com ??
> 
> But, yes, that is another good question, how should we represent the
> avatar and what features should a sim allow to a guest avatar. All good
> things to consider as we evolve the Metaverse off into the future.
> 
> Personally, I would think a guest should have the ability to read
> notecards, experience scripts, probably be able to "touch". Things that
> would fit into the paradigm of a naive user entering the Metaverse for
> the first time.
> 

i like the idea of this being configurable per grid.

> I like the browser Xenkii idea. I rather suspect most of these folks
> will enter our Metaverse through some sort of browser interface as a
> result of a hyperlink on a 'Flat Web Site'.

or a rezzme: URI


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dr Scofield]

MW wrote:
> I have to say I'm not a big fan of what I've seen of mono.addins so far.
> Maybe ExtensionLoader is better, so I do think we should look at that.
> As I think it is better to only have one system of loading plugins/modules.
> 
> As for initialise vs Initialize, hehe. Well personally I think it should
> stay as it is. I really see no reason to change it. I do know of other
> opensource projects that use initialise, Ogre being one. And it would be
> as hard for me to remember to look/search for Initialize as it would be
> for you to look for initialise.
> 
> So my vote is a strong keep to UK english or even the mix we have
> (because some bits are in US english). But I really don't think people
> should have to switch code that is there to US english. Sorry thats a
> point I do feel quite strongly on.
> 
> But saying that if everyone else voted in favour of that switch I
> wouldn't stand in the way. Just would think it was wrong. Any code I
> write is just likely to have uk spelling. The same way any code you
> write is likely to have US spelling. And opensim has had the UK spelling
> from the start.

so, +1 on keeping the UK spelling :-)


DrS/dirk



-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dr Scofield]

Charles Krinke wrote:
> ROFL. Oh, it was the 'z' versus the 's' you were discussing.
> 
> I thought it was the "i" versus the "I".

ROFL. yeah, i can imagine there are folks out there that object to the capital
"I" as being too capitalistic...


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[MW]

My preference is that we modulariSe the whole avatar creation, its much more 
flexible. 

Also on that subject I suggest we move the server side avatar data from the 
user server to one of the other servers (most likely the inventory server). I 
don't think it should be in the user server for a number of reasons. But one 
reason we have came across is wanting to share a single user server with 
multiple grids. I think the user server really should just be account 
infomation.

But anyway back onto the AvatarFactoryModule, yes if we aren't going to 
modularise it then we should just move it all to IAvatarService. No point in 
having the current half way solution.

Also I think the process should even a more general, start modularising the 
whole of the CommsManager.

But not sure anyone is going to be able to give a +1 or -1 on any idea before 
"Jan 2 2009" ;)

Stefan Andersson  wrote:.hmmessage P { margin:0px; 
padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana }   It's 
kind of crazy that we have a RegionModule (AvatarFactoryModule) that really 
just look up the CommsManager AvatarService and forwards a request to that.

 I propose we either modularize the whole thing (the prefferrable thing) or 
merge the AvatarFactory module code into the IAvatarService.
  
 If nobody has objected strongly until Jan 2 2009, I will mantis this.
 
Best regards,
Stefan Andersson
Tribal Media AB


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


   ___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dr Scofield]

Ryan McDougall wrote:
> My apologies for thread-jacking...
> 
> I just want to be clear I didn't propose it because I came later and
> decided I didn't like UK spelling. I am Canadian and historically
> Canadians have used UK spelling.
> 
> I proposed it for the same reason (US) English is the standard
> language of all things international; business, science, open source,
> etc: we have to pick one anyway, there will be more people unhappy
> with the choice than happy, so might as well just pick the most common
> one and suck it up.

so, to balance things a bit, if we actually do want to standardize one spelling
system, i'd say, let's standardize on the UK variant then, given that that is
the one OpenSim was born with.


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Source tree cleanup

[Dr Scofield]

Sean Dague wrote:
> Jeff Ames wrote:
>> Hello,
>>
>> There are a few dusty corners in trunk from before
>> forge.opensimulator.org was up, but I was wondering about moving them
>> over, or merging them with core.

[...]
>> * share/python

i've cleaned out that one. was just example code.


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] the weird idea collection

[Dirk Krause]

Hi,

I hope it's ok if I start a couple of mails here with several ideas I
initially wanted to bring into the AWG channels, but ... well, you know.
Charles' mail and blog entry sort of encouraged me to do so, so blame
him :-). If it's not ok, please stop me.

Regarding these ideas: some of them might be not feasible, some plain
wrong. I suspect most of them are not even weird or new :-/.

Thank you for your time.

Dirk/Barth

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

One problem with SL that is addressed quite often is the limited number
of AVs that one region can hold ('the number of people on an island').

This comes up in the 'big number' discussion and especially in nearly
every meeting scenario that is of high interest to the community.
Somehow this is also influencing the 'relevance of SL' (and thus
OpenSim)technology and grid technology in general ('I can have hundreds
of people in a Habbo place but only around 50 in SL')

I really want to dodge the official 'big numbers' discussion by stating
what would happen when there would be hundreds of people in one IRC
channel and all of them were writing at the same time. But I do believe
that one viable 'big number' scenario is a podium discussion where a
couple of persons are discussing and most of the other people are
listening/watching/reading in general. Or a sports event of sorts, with
- well :-) - 22 people acting and many more watching.

So what I think what would be valuable is a 'lightweight agent'
construction. This would be an AV that basically can't do much except
listening/watching/reading, she especially couldn't rezz anything. It's
a bit like the 'spectator mode' in some games. This way there could be
big numbers of watchers, thus giving more people the opportunity to
attend a meeting - practically increasing the number of virtual beings
in a region, without bringing the region down.

I could think of at least two ways to acchieve this:
- a camera woman AV that 'lightweight agents' could hook up to, using
the client only as a viewer; this would be a bit like a video stream,
just with less impact, since the rendering is still done in the viewer.
- a stripped down agent that got rid of everything that causes too much
stress on either network or server. Unfortunately I don't know how to do
that because I don't know the OpenSim construction enough. These
lightweight agents could have a representation (a sphere?) while they
are online, a distinct place and the ability to look around and maybe
move slowly.

By having something like that we could get rid of the 'theres just a
small number of AVs in every region' dilemma.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Teravus Ovares]

* watches MW and stefan catch each other's spelling mistakes*

:D

-T

On 1/26/09, MW  wrote:
> My preference is that we modulariSe the whole avatar creation, its much more
> flexible.
>
> Also on that subject I suggest we move the server side avatar data from the
> user server to one of the other servers (most likely the inventory server).
> I don't think it should be in the user server for a number of reasons. But
> one reason we have came across is wanting to share a single user server with
> multiple grids. I think the user server really should just be account
> infomation.
>
> But anyway back onto the AvatarFactoryModule, yes if we aren't going to
> modularise it then we should just move it all to IAvatarService. No point in
> having the current half way solution.
>
> Also I think the process should even a more general, start modularising the
> whole of the CommsManager.
>
> But not sure anyone is going to be able to give a +1 or -1 on any idea
> before "Jan 2 2009" ;)
>
> Stefan Andersson  wrote:
> It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that
> really just look up the CommsManager AvatarService and forwards a request to
> that.
>
> I propose we either modularize the whole thing (the prefferrable thing) or
> merge the AvatarFactory module code into the IAvatarService.
>
> If nobody has objected strongly until Jan 2 2009, I will mantis this.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Killing off AvatarFactory

[Stefan Andersson]

Argh.
 
s/Jan/Feb/ Best regards,Stefan AnderssonTribal Media AB



Date: Mon, 26 Jan 2009 09:54:12 +From: michaelwr...@yahoo.co.ukto: 
opensim-...@lists.berlios.desubject: Re: [Opensim-dev] Proposal: Killing off 
AvatarFactoryMy preference is that we modulariSe the whole avatar creation, its 
much more flexible. Also on that subject I suggest we move the server side 
avatar data from the user server to one of the other servers (most likely the 
inventory server). I don't think it should be in the user server for a number 
of reasons. But one reason we have came across is wanting to share a single 
user server with multiple grids. I think the user server really should just be 
account infomation.But anyway back onto the AvatarFactoryModule, yes if we 
aren't going to modularise it then we should just move it all to 
IAvatarService. No point in having the current half way solution.Also I think 
the process should even a more general, start modularising the whole of the 
CommsManager.But not sure anyone is going to be able to give a +1 or -1 on any 
idea before "Jan 2 2009" ;)Stefan Andersson  wrote:


It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that 
really just look up the CommsManager AvatarService and forwards a request to 
that.I propose we either modularize the whole thing (the prefferrable thing) or 
merge the AvatarFactory module code into the IAvatarService. If nobody has 
objected strongly until Jan 2 2009, I will mantis this.Best regards,Stefan 
AnderssonTribal Media 
AB___Opensim-dev mailing 
listopensim-...@lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[MW]

But do we standardize on one variant or standardise on that?

Sorry couldn't stop myself :)

Dr Scofield  wrote: Ryan McDougall wrote:
> My apologies for thread-jacking...
> 
> I just want to be clear I didn't propose it because I came later and
> decided I didn't like UK spelling. I am Canadian and historically
> Canadians have used UK spelling.
> 
> I proposed it for the same reason (US) English is the standard
> language of all things international; business, science, open source,
> etc: we have to pick one anyway, there will be more people unhappy
> with the choice than happy, so might as well just pick the most common
> one and suck it up.

so, to balance things a bit, if we actually do want to standardize one spelling
system, i'd say, let's standardize on the UK variant then, given that that is
the one OpenSim was born with.


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


   ___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Teravus Ovares]

Mostly, the road block to working to solve this issue is actually
getting many people on a region at once consistantly.It's hard to
coordinate tons of people on in a testing scenario :)

Anyway, yes, noted!

Teravus

On 1/26/09, Dirk Krause  wrote:
> One problem with SL that is addressed quite often is the limited number
> of AVs that one region can hold ('the number of people on an island').
>
> This comes up in the 'big number' discussion and especially in nearly
> every meeting scenario that is of high interest to the community.
> Somehow this is also influencing the 'relevance of SL' (and thus
> OpenSim)technology and grid technology in general ('I can have hundreds
> of people in a Habbo place but only around 50 in SL')
>
> I really want to dodge the official 'big numbers' discussion by stating
> what would happen when there would be hundreds of people in one IRC
> channel and all of them were writing at the same time. But I do believe
> that one viable 'big number' scenario is a podium discussion where a
> couple of persons are discussing and most of the other people are
> listening/watching/reading in general. Or a sports event of sorts, with
> - well :-) - 22 people acting and many more watching.
>
> So what I think what would be valuable is a 'lightweight agent'
> construction. This would be an AV that basically can't do much except
> listening/watching/reading, she especially couldn't rezz anything. It's
> a bit like the 'spectator mode' in some games. This way there could be
> big numbers of watchers, thus giving more people the opportunity to
> attend a meeting - practically increasing the number of virtual beings
> in a region, without bringing the region down.
>
> I could think of at least two ways to acchieve this:
> - a camera woman AV that 'lightweight agents' could hook up to, using
> the client only as a viewer; this would be a bit like a video stream,
> just with less impact, since the rendering is still done in the viewer.
> - a stripped down agent that got rid of everything that causes too much
> stress on either network or server. Unfortunately I don't know how to do
> that because I don't know the OpenSim construction enough. These
> lightweight agents could have a representation (a sphere?) while they
> are online, a distinct place and the ability to look around and maybe
> move slowly.
>
> By having something like that we could get rid of the 'theres just a
> small number of AVs in every region' dilemma.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] "Horizons" (panels) and a public "I am sorry"‏

[Americo Damasceno]

 Yes, Stefan. They are to be used like walls and ceilling. Cristina did  a 
first test at the "hypergrided  world":
ucigrid04.nacs.uci.edu 9003 using transparence and not a ceilling to mantain 
the effect of day/night. 
 One problem that I see is the FOV (distance that the avatar can see anything) 
that needs to be changed or sometimes we will see the panel, sometimes not.
 
 Americo
_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

This wouldn't hold for the camera woman approach, I hoped, since she is there 
'only once' and ... well from there, I admit I don't know what is to be done, 
but maybe the stream can be proxied (via akamai and the likes?) and serve the 
'big numbers'.

-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Teravus Ovares
Gesendet: Montag, 26. Januar 2009 11:24
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

Mostly, the road block to working to solve this issue is actually
getting many people on a region at once consistantly.It's hard to
coordinate tons of people on in a testing scenario :)

Anyway, yes, noted!

Teravus

On 1/26/09, Dirk Krause  wrote:
> One problem with SL that is addressed quite often is the limited number
> of AVs that one region can hold ('the number of people on an island').
>
> This comes up in the 'big number' discussion and especially in nearly
> every meeting scenario that is of high interest to the community.
> Somehow this is also influencing the 'relevance of SL' (and thus
> OpenSim)technology and grid technology in general ('I can have hundreds
> of people in a Habbo place but only around 50 in SL')
>
> I really want to dodge the official 'big numbers' discussion by stating
> what would happen when there would be hundreds of people in one IRC
> channel and all of them were writing at the same time. But I do believe
> that one viable 'big number' scenario is a podium discussion where a
> couple of persons are discussing and most of the other people are
> listening/watching/reading in general. Or a sports event of sorts, with
> - well :-) - 22 people acting and many more watching.
>
> So what I think what would be valuable is a 'lightweight agent'
> construction. This would be an AV that basically can't do much except
> listening/watching/reading, she especially couldn't rezz anything. It's
> a bit like the 'spectator mode' in some games. This way there could be
> big numbers of watchers, thus giving more people the opportunity to
> attend a meeting - practically increasing the number of virtual beings
> in a region, without bringing the region down.
>
> I could think of at least two ways to acchieve this:
> - a camera woman AV that 'lightweight agents' could hook up to, using
> the client only as a viewer; this would be a bit like a video stream,
> just with less impact, since the rendering is still done in the viewer.
> - a stripped down agent that got rid of everything that causes too much
> stress on either network or server. Unfortunately I don't know how to do
> that because I don't know the OpenSim construction enough. These
> lightweight agents could have a representation (a sphere?) while they
> are online, a distinct place and the ability to look around and maybe
> move slowly.
>
> By having something like that we could get rid of the 'theres just a
> small number of AVs in every region' dilemma.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dirk Krause]

You should have signed with DrZ ...

-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
Gesendet: Montag, 26. Januar 2009 11:25
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] Proposal for a cleanup/correction of the 
region-module system

MW wrote:
> But do we standardize on one variant or standardise on that?
> 
> Sorry couldn't stop myself :)

that was a test :-) or was that a tezt? :-D

DrS/dirk


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Regions larger then 256x256

[Americo Damasceno]

  Like there are the problem of performance when we have more than 15/20 
avatares inside one sim , I believe that is important to have regions smaller 
than 256x256. By example, a "mini-region" having  32x32. Using grid and a 
server for each of 64 glued mini-regions we can have a superpopulated area of 
256x256   running well.
 
Americo
_
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dr Scofield]

MW wrote:
> But do we standardize on one variant or standardise on that?
> 
> Sorry couldn't stop myself :)

that was a test :-) or was that a tezt? :-D

DrS/dirk


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Stefan Andersson]

Again, that could be accomplished by having a 3x3 region matrix, where all 
three put 'their' objects onto the central region.
 
This of course means that they all need to share that regions state, to be able 
to do physics for it.
Another concept that we've toyed with in the past is to let a region place a 
scenepresence in another region to be informed of what's going on there; this 
could be one way of doing it.Best regards,Stefan AnderssonTribal Media AB



From: adama...@hotmail.comto: opensim-...@lists.berlios.dedate: Mon, 26 Jan 
2009 07:46:04 -0300Subject: [Opensim-dev] Regions larger then 256x256

  Like there are the problem of performance when we have more than 15/20 
avatares inside one sim , I believe that is important to have regions smaller 
than 256x256. By example, a "mini-region" having  32x32. Using grid and a 
server for each of 64 glued mini-regions we can have a superpopulated area of 
256x256   running well. Americo



check out the rest of the Windows Live™. More than mail–Windows Live™ goes way 
beyond your inbox. More than messages___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Eugen Leitl]

On Mon, Jan 26, 2009 at 11:21:15AM +0100, Dirk Krause wrote:

> So what I think what would be valuable is a 'lightweight agent'
> construction. This would be an AV that basically can't do much except

I typically use a 6DOF-controlled flycam to circumvent issues
with clunky avatars. It would be nice to highlight the flycam
position with a minimal marker, like a point of light with
an optional avatar label or something.

How is the sound broadcast implemented in the server?

> listening/watching/reading, she especially couldn't rezz anything. It's
> a bit like the 'spectator mode' in some games. This way there could be
> big numbers of watchers, thus giving more people the opportunity to
> attend a meeting - practically increasing the number of virtual beings
> in a region, without bringing the region down.
> 
> I could think of at least two ways to acchieve this:
> - a camera woman AV that 'lightweight agents' could hook up to, using
> the client only as a viewer; this would be a bit like a video stream,
> just with less impact, since the rendering is still done in the viewer.
> - a stripped down agent that got rid of everything that causes too much
> stress on either network or server. Unfortunately I don't know how to do
> that because I don't know the OpenSim construction enough. These
> lightweight agents could have a representation (a sphere?) while they
> are online, a distinct place and the ability to look around and maybe
> move slowly.
> 
> By having something like that we could get rid of the 'theres just a
> small number of AVs in every region' dilemma.

-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dahlia Trimble]

I thought that the biggest contributors to agent related overhead were the
object updates and asset downloads that had to be sent to each viewer - not
sure that a "simple observer" would reduce that overhead all that much.
Perhaps if these data transfers could somehow be offloaded from the host
that was managing the scene, some sort of "sharding" but only scene content
and updates, and let the clients still send their individual updates to the
main host? This may accomplish something similar to what you are describing.

On Mon, Jan 26, 2009 at 2:21 AM, Dirk Krause wrote:

> One problem with SL that is addressed quite often is the limited number
> of AVs that one region can hold ('the number of people on an island').
>
> This comes up in the 'big number' discussion and especially in nearly
> every meeting scenario that is of high interest to the community.
> Somehow this is also influencing the 'relevance of SL' (and thus
> OpenSim)technology and grid technology in general ('I can have hundreds
> of people in a Habbo place but only around 50 in SL')
>
> I really want to dodge the official 'big numbers' discussion by stating
> what would happen when there would be hundreds of people in one IRC
> channel and all of them were writing at the same time. But I do believe
> that one viable 'big number' scenario is a podium discussion where a
> couple of persons are discussing and most of the other people are
> listening/watching/reading in general. Or a sports event of sorts, with
> - well :-) - 22 people acting and many more watching.
>
> So what I think what would be valuable is a 'lightweight agent'
> construction. This would be an AV that basically can't do much except
> listening/watching/reading, she especially couldn't rezz anything. It's
> a bit like the 'spectator mode' in some games. This way there could be
> big numbers of watchers, thus giving more people the opportunity to
> attend a meeting - practically increasing the number of virtual beings
> in a region, without bringing the region down.
>
> I could think of at least two ways to acchieve this:
> - a camera woman AV that 'lightweight agents' could hook up to, using
> the client only as a viewer; this would be a bit like a video stream,
> just with less impact, since the rendering is still done in the viewer.
> - a stripped down agent that got rid of everything that causes too much
> stress on either network or server. Unfortunately I don't know how to do
> that because I don't know the OpenSim construction enough. These
> lightweight agents could have a representation (a sphere?) while they
> are online, a distinct place and the ability to look around and maybe
> move slowly.
>
> By having something like that we could get rid of the 'theres just a
> small number of AVs in every region' dilemma.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

Sounds good.

 

Remember that someone (you?)  in the openviewer discussion back then
told me, that there were server updates everytime you turn around?  I
was really surprised at first because of the inefficiency that I
suspected. Then I thought, ok, this is not WoW - the scenery can change
anytime so the next time you look back the wall behind you could be
gone, so it is a good thing that the server does send it again.  

 

But then again ... if there was a flag saying 'this is a wall' and it is
not going to change anytime soon and 'this is a powerpoint presenter'
this *will*l change anytime soon ... the stream of updates for a regular
agent viewer wouldn't need to change then (thus not breaking SL
compatibility), but for a 'simple observer' I would hope that the number
of updates decreases dramatically.

 

I am not saying this is the solution, but I think it's worth the while
thinking along these lines.

 

 

Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dahlia
Trimble
Gesendet: Montag, 26. Januar 2009 12:23
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

 

I thought that the biggest contributors to agent related overhead were
the object updates and asset downloads that had to be sent to each
viewer - not sure that a "simple observer" would reduce that overhead
all that much. Perhaps if these data transfers could somehow be
offloaded from the host that was managing the scene, some sort of
"sharding" but only scene content and updates, and let the clients still
send their individual updates to the main host? This may accomplish
something similar to what you are describing.

 

 

On Mon, Jan 26, 2009 at 2:21 AM, Dirk Krause 
wrote:

One problem with SL that is addressed quite often is the limited number
of AVs that one region can hold ('the number of people on an island').

This comes up in the 'big number' discussion and especially in nearly
every meeting scenario that is of high interest to the community.
Somehow this is also influencing the 'relevance of SL' (and thus
OpenSim)technology and grid technology in general ('I can have hundreds
of people in a Habbo place but only around 50 in SL')

I really want to dodge the official 'big numbers' discussion by stating
what would happen when there would be hundreds of people in one IRC
channel and all of them were writing at the same time. But I do believe
that one viable 'big number' scenario is a podium discussion where a
couple of persons are discussing and most of the other people are
listening/watching/reading in general. Or a sports event of sorts, with
- well :-) - 22 people acting and many more watching.

So what I think what would be valuable is a 'lightweight agent'
construction. This would be an AV that basically can't do much except
listening/watching/reading, she especially couldn't rezz anything. It's
a bit like the 'spectator mode' in some games. This way there could be
big numbers of watchers, thus giving more people the opportunity to
attend a meeting - practically increasing the number of virtual beings
in a region, without bringing the region down.

I could think of at least two ways to acchieve this:
- a camera woman AV that 'lightweight agents' could hook up to, using
the client only as a viewer; this would be a bit like a video stream,
just with less impact, since the rendering is still done in the viewer.
- a stripped down agent that got rid of everything that causes too much
stress on either network or server. Unfortunately I don't know how to do
that because I don't know the OpenSim construction enough. These
lightweight agents could have a representation (a sphere?) while they
are online, a distinct place and the ability to look around and maybe
move slowly.

By having something like that we could get rid of the 'theres just a
small number of AVs in every region' dilemma.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

>> How is the sound broadcast implemented in the server?
Well, this I didn't worry too much about, since for meetings (or
concerts etc) the usual workaround is to have an audio stream available
for the particular parcel.  My guess is one can live with that. If you
need spatial audio - I *think* most of it is handled by the vivox client
anyways, so my guess is that this is all solvable out of the box. (well,
in SL anyways, since there is no out of the box voice solution right now
for OpenSim).
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] mantis resolved vs. closed

[Sean Dague]

nlin wrote:
> Hello,
> 
> One possible source of confusion is that the OpenSim wiki says "Please leave
> closing of bugs to core team. A closed bug means we think it's gone forever,
> or the bug report is invalid." (http://opensimulator.org/wiki/Bugs) That may
> explain why lots of issues remain in the "resolved" state. Is the wiki
> statement no longer valid?

I think the wiki statement still is valid, but it's something I put
together a long time ago.  I know we at least partially follow that flow
 now, but I'd be up for suggestions on what people have found makes sense.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] mantis resolved vs. closed

[James Stallings II]

Yes this caused quite a lot of confusion, frustration and embarrassment in
mixed amounts for nlin and myself last evening.

Even though the ticket I submitted was only 'resolved', it had to be
'reopened' when the results did not test true - thus giving the appearance
the ticket had been closed.

This is not good - it doesn't accurately describe the status of the ticket
nor it's disposition, and resulted in a tremendous amount of unnecesary
friction.

I dont want to rush into any particular solution, but I do think we need to
examine this and do something that is both more developer/tester friendly
and that accurately reflects the state of an issue.

Cheers
James


On Mon, Jan 26, 2009 at 1:21 AM, Nebadon Izumi wrote:

> I agree this is confusing and should be changed to be more inline with the
> reality of things, though i wont rush to change it right now so we can
> gather more comments and come to some sort of consensus on the terms of
> this.
>
> Neb
>
>
> On Sun, Jan 25, 2009 at 9:29 PM, nlin  wrote:
>
>> Hello,
>>
>> One possible source of confusion is that the OpenSim wiki says "Please
>> leave closing of bugs to core team. A closed bug means we think it's gone
>> forever, or the bug report is invalid." (
>> http://opensimulator.org/wiki/Bugs) That may explain why lots of issues
>> remain in the "resolved" state. Is the wiki statement no longer valid?
>>
>> -nlin
>>
>> 2009/1/26 Nebadon Izumi 
>>
>>>  I always saw it as that when a developer or someone marked a ticket as
>>> resolved it meant they made an attempt to resolve this item and that the
>>> filer needs to test it and either close the ticket or re-open back to a true
>>> bug status, and only the reporter should close the ticket, that is until a
>>> certain amount of time passes then either a manager or developer should
>>> close the ticket as they see fit.
>>>
>>> Hope this helps.
>>>
>>> Nebadon
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>


-- 
===
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Removal of the Data Framework

[Sean Dague]

Stefan Andersson wrote:
> As I understand it, we have no longer anything actually using the Data Mapper 
> Framework introduced as a proposed alterantive to NHibernate a year ago.
>  
> I propose we now retire that piece of code. These are the projects that will 
> be removed:
>  
> * OpenSim.Data.MySQLMapper
> * OpenSim.Data.MSSQLMapper
> * OpenSim.Data.Base
> In OpenSim.Data, the following classes would be removed:
> * OpenSimDatabaseConnector.cs
> * OpenSimDataReader.cs
> * OpenSimObjectFieldMapper.cs* PrimitiveBaseShapeTableMapper.cs
>  
> Also, the AvatarFactoryModule erroneously still references these namespaces, 
> but that's a minor fix.
>  
> If nobody has a strong objection, I will start removing these files Feb 2 
> 2009.

+1, sounds good to me.  Thanks for volunteering for the cleanup.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Removal of the Data Framework

[Melanie]

+1 from me, too

Sean Dague wrote:
> Stefan Andersson wrote:
>> As I understand it, we have no longer anything actually using the Data 
>> Mapper Framework introduced as a proposed alterantive to NHibernate a year 
>> ago.
>>  
>> I propose we now retire that piece of code. These are the projects that will 
>> be removed:
>>  
>> * OpenSim.Data.MySQLMapper
>> * OpenSim.Data.MSSQLMapper
>> * OpenSim.Data.Base
>> In OpenSim.Data, the following classes would be removed:
>> * OpenSimDatabaseConnector.cs
>> * OpenSimDataReader.cs
>> * OpenSimObjectFieldMapper.cs* PrimitiveBaseShapeTableMapper.cs
>>  
>> Also, the AvatarFactoryModule erroneously still references these namespaces, 
>> but that's a minor fix.
>>  
>> If nobody has a strong objection, I will start removing these files Feb 2 
>> 2009.
> 
> +1, sounds good to me.  Thanks for volunteering for the cleanup.
> 
>   -Sean
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Sean Dague]

Dahlia Trimble wrote:
> I thought that the biggest contributors to agent related overhead were the
> object updates and asset downloads that had to be sent to each viewer - not
> sure that a "simple observer" would reduce that overhead all that much.
> Perhaps if these data transfers could somehow be offloaded from the host
> that was managing the scene, some sort of "sharding" but only scene content
> and updates, and let the clients still send their individual updates to the
> main host? This may accomplish something similar to what you are describing.

A year ago a China research team at IBM went digging here, did a bunch
of changes, and got up to 1000 pCampbots running around at once.
Unfortunately they threw the baby out with the bathwater in what they
optimized away, so it wasn't useful for anything other than their
experiment.

What was learned in that process, as I sifted through results, is we've
got this N^2 bottle neck on avatars that is really our issue.  My
information is a bit out of date, as its been a few months since I've
been in Clientview, so corrections here would be appreciated.

When an avatar moves it's head that information needs to be propogated
around to  everyone else in the environment.  That's N new packets.  But
in any real situation all Avatars are moving around, or looking around,
or in other ways asking the server to send around updates.  And they
need to send as many updates as avatars in the environment.

Part of the problem is the sender is in the Clientview.  So in order to
get that packet back out you need to get it in, distribute it to your 20
client view threads, then signal them all, and they send things back
out.  Because they have to look up a bunch of info, there is a whole
series of locks in those Clientviews that get taken all the time.  And I
mean *all* the time.  At some point we're effectively spending more time
dealing with locks then doing anything else.  People in a Linux
environment running the serverstats plugin will see this as the
Systemtime spike.  At some point System Time ends up consuming more
processor than User Time, which is very bad.  That means lots of context
switches into your kernel.

One solution here would be to get the execution out of clientview, and
have a single network stack for OpenSim.  User clientviews to convert
packets to objects, and objects to packets, but don't let it send them.
 Leave that up to a global packet system.  That would also let you damp
bandwidth at a global level, which today, there isn't really a view off,
because each client view is rather isolated with it's own execution
stack (5 threads or so).  It turns out that in this case our paralism is
actually slowing us down.

That would take a good chunk of work, and it would probably break stuff
for a while, both of which is why I've not gone after it.  It could also
be a wrong approach, given other data on the table.

At any rate, I really think we need to be able to do 40 full avatars
prior to opening things up for lightweight avatars, that will drive more
load (though not N^2 load if we don't give them an appearance or
animations or look at updating).

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Mircea Kitsune]

I too had this wish for Opensim, but gave up on it understanding it would be 
too difficult to implement and would hold too many issues. Sure, region *x* 
arrangements are possible and commonly used, but it does cause more complexity 
that way and moving all of them together or tweaking each individually could be 
a bit harder.

My idea back then was being allowed to create regions in powers of 2 (eg: 
256x256 as now, then 128x128 smaller or larger 512x512). First thing which 
wouldn't work here however would be positioning them correctly over certain X 
and Y coordinates in order to fit smaller sims around larger ones, which would 
end up causing grid coordinates such as 1000.5, 1001.25. Second, I don't think 
the client actually supports simulators larger then 256 x 256 so the client 
would probably need modifying as well to do that. Third, exporting and 
importing settings and stuff (such as terrain or .oar archives) between 
different sizes of simulators could be problematic and buggy. And fourth, 
larger single sims could possibly cause performance issues even with computers 
in our days.

If some of these issues didn't exist though this might be doable and could be 
fun. Anyway the best practical way at the moment are region groups of 2x2 or 
3x3 or how many you wish for having a larger square, which isn't that bad in 
the end.

From: adama...@hotmail.com
To: opensim-dev@lists.berlios.de
Date: Mon, 26 Jan 2009 07:46:04 -0300
Subject: [Opensim-dev] Regions larger then 256x256








  Like there are the problem of performance when we have more than 15/20 
avatares inside one sim , I believe that is important to have regions smaller 
than 256x256. By example, a "mini-region" having  32x32. Using grid and a 
server for each of 64 glued mini-regions we can have a superpopulated area of 
256x256   running well.

 

Americo

check out the rest of the Windows Live™.
More than mail–Windows Live™ goes way beyond your inbox.
 More than messages
_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

Well, I don't dare to hope this ... but if there would be an existing approach 
that relieves the bottleneck even for normal avatars - this would be obviously 
tremendously better!

Two points:
- if it would be worthwhile to think about how to implement such a thing, it 
might be good to introduce a second avatar mechanism ('lightweight' or 
whatever) to not break the compatibility. Because from what you write my 
feeling is that the update per head movement dilemma is an inherent 'feature' 
of the whole grid thought.

- about the five threads: are these corresponding to the roundabout additional 
5 processes I see when I log in to a Linux box? I ask because I found out (and 
documented in a previous mail) that these threads add up over time when you log 
in and out. So the overall number of processes increases over time by simply 
logging an agent in and out again. If this is the case then this might be a bug 
worth to be mantissed.



-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Sean Dague
Gesendet: Montag, 26. Januar 2009 14:03
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

Dahlia Trimble wrote:
> I thought that the biggest contributors to agent related overhead were 
> the object updates and asset downloads that had to be sent to each 
> viewer - not sure that a "simple observer" would reduce that overhead all 
> that much.
> Perhaps if these data transfers could somehow be offloaded from the 
> host that was managing the scene, some sort of "sharding" but only 
> scene content and updates, and let the clients still send their 
> individual updates to the main host? This may accomplish something similar to 
> what you are describing.

A year ago a China research team at IBM went digging here, did a bunch of 
changes, and got up to 1000 pCampbots running around at once.
Unfortunately they threw the baby out with the bathwater in what they optimized 
away, so it wasn't useful for anything other than their experiment.

What was learned in that process, as I sifted through results, is we've got 
this N^2 bottle neck on avatars that is really our issue.  My information is a 
bit out of date, as its been a few months since I've been in Clientview, so 
corrections here would be appreciated.

When an avatar moves it's head that information needs to be propogated around 
to  everyone else in the environment.  That's N new packets.  But in any real 
situation all Avatars are moving around, or looking around, or in other ways 
asking the server to send around updates.  And they need to send as many 
updates as avatars in the environment.

Part of the problem is the sender is in the Clientview.  So in order to get 
that packet back out you need to get it in, distribute it to your 20 client 
view threads, then signal them all, and they send things back out.  Because 
they have to look up a bunch of info, there is a whole series of locks in those 
Clientviews that get taken all the time.  And I mean *all* the time.  At some 
point we're effectively spending more time dealing with locks then doing 
anything else.  People in a Linux environment running the serverstats plugin 
will see this as the Systemtime spike.  At some point System Time ends up 
consuming more processor than User Time, which is very bad.  That means lots of 
context switches into your kernel.

One solution here would be to get the execution out of clientview, and have a 
single network stack for OpenSim.  User clientviews to convert packets to 
objects, and objects to packets, but don't let it send them.
 Leave that up to a global packet system.  That would also let you damp 
bandwidth at a global level, which today, there isn't really a view off, 
because each client view is rather isolated with it's own execution stack (5 
threads or so).  It turns out that in this case our paralism is actually 
slowing us down.

That would take a good chunk of work, and it would probably break stuff for a 
while, both of which is why I've not gone after it.  It could also be a wrong 
approach, given other data on the table.

At any rate, I really think we need to be able to do 40 full avatars prior to 
opening things up for lightweight avatars, that will drive more load (though 
not N^2 load if we don't give them an appearance or animations or look at 
updating).

-Sean

--
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] mantis resolved vs. closed

[nlin]

2009/1/26, James Stallings II :
> Yes this caused quite a lot of confusion, frustration and embarrassment in
> mixed amounts for nlin and myself last evening.

There seems to be a case of mistaken identity here, as I wasn't
involved in any mantis issues last evening. I was responding to Jeff's
query about mantis usage in general, but was not aware of any specific
instances of mantis problems recently.

Thanks,
-nlin
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] mantis resolved vs. closed

[James Stallings II]

Heh, my bad, nlin is correct - it was idb I had the mantis issues with last
evening.

Mark it up to emailling before I've had my coffee :)

Cheers,
James


On Mon, Jan 26, 2009 at 7:41 AM, nlin  wrote:

> 2009/1/26, James Stallings II :
> > Yes this caused quite a lot of confusion, frustration and embarrassment
> in
> > mixed amounts for nlin and myself last evening.
>
> There seems to be a case of mistaken identity here, as I wasn't
> involved in any mantis issues last evening. I was responding to Jeff's
> query about mantis usage in general, but was not aware of any specific
> instances of mantis problems recently.
>
> Thanks,
> -nlin
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



-- 
===
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[MW]

This is more to do with how we use Mono.Addins, but we really should make it a 
lot easier to separate the various UGAIM servers, so that each one can be in 
its own directory without needing the other UGAIM exe's to be in there. 

By default we have the loading of plugins referencing all the UGAIM servers. So 
that if all the UGAIM servers.exe's aren't in that directory, then no plugins 
will be loaded. 



Mike Mazur  wrote: Hi,

On Sat, 24 Jan 2009 22:59:26 +0200
Ryan McDougall  wrote:

> 1. Can we unify RegionModules with IPlugin system I did a while ago?
> This would mean learning and using Mono.Addins, or ExtensionLoader if
> that is Mono.Addins's replacement.

I'd like to suggest sticking with Mono.Addins.

While it is a bit big, has a steeper learning curve and requires more
calls to load a module, it may prove to be pretty useful in the future
when people want to do more complicated things with modules. It is
being actively developed by a wider community, is used in large
projects and is based on the Eclipse add-in engine[1].

ExtensionLoader is nice and small and loads modules well. If/when
OpenSim graduates to more complex module use cases, we may find
ExtensionLoader lacking. Any missing features in ExtensionLoader would
need to be coded by those who need it.

Mike


[1] http://www.mono-project.com/Introduction_to_Mono.Addins
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


   ___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Frank Nichols]

Well, one solution to getting a lot of people on at one time would be a 
heavy weight bot that loaded a system the same as a client does. It 
would need to be based on a viewer code base, but be light enough on the 
client side to run hundreds of connections/accounts.


Teravus Ovares wrote:
> Mostly, the road block to working to solve this issue is actually
> getting many people on a region at once consistantly.It's hard to
> coordinate tons of people on in a testing scenario :)
>
> Anyway, yes, noted!
>
> Teravus
>
> On 1/26/09, Dirk Krause  wrote:
>   
>> One problem with SL that is addressed quite often is the limited number
>> of AVs that one region can hold ('the number of people on an island').
>>
>> This comes up in the 'big number' discussion and especially in nearly
>> every meeting scenario that is of high interest to the community.
>> Somehow this is also influencing the 'relevance of SL' (and thus
>> OpenSim)technology and grid technology in general ('I can have hundreds
>> of people in a Habbo place but only around 50 in SL')
>>
>> I really want to dodge the official 'big numbers' discussion by stating
>> what would happen when there would be hundreds of people in one IRC
>> channel and all of them were writing at the same time. But I do believe
>> that one viable 'big number' scenario is a podium discussion where a
>> couple of persons are discussing and most of the other people are
>> listening/watching/reading in general. Or a sports event of sorts, with
>> - well :-) - 22 people acting and many more watching.
>>
>> So what I think what would be valuable is a 'lightweight agent'
>> construction. This would be an AV that basically can't do much except
>> listening/watching/reading, she especially couldn't rezz anything. It's
>> a bit like the 'spectator mode' in some games. This way there could be
>> big numbers of watchers, thus giving more people the opportunity to
>> attend a meeting - practically increasing the number of virtual beings
>> in a region, without bringing the region down.
>>
>> I could think of at least two ways to acchieve this:
>> - a camera woman AV that 'lightweight agents' could hook up to, using
>> the client only as a viewer; this would be a bit like a video stream,
>> just with less impact, since the rendering is still done in the viewer.
>> - a stripped down agent that got rid of everything that causes too much
>> stress on either network or server. Unfortunately I don't know how to do
>> that because I don't know the OpenSim construction enough. These
>> lightweight agents could have a representation (a sphere?) while they
>> are online, a distinct place and the ability to look around and maybe
>> move slowly.
>>
>> By having something like that we could get rid of the 'theres just a
>> small number of AVs in every region' dilemma.
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.13/1915 - Release Date: 1/25/2009 
> 6:13 PM
>
>   

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Nebadon Izumi]

the only bad thing about bringing up the Pcampbot login test was at the time
pcampbot was not pulling assets down from the scene locally to itself, so
realisticly those 1000 pcampbots were probably generating about the same
amount of login traffic that about 10-20 avatars would have been likely.
The only real solution to this problem will likely be load balancing and
many servers working together to break the 100 avatar limit, the chances
that 1 server will be serving 1000 avatars is completely impossible, i
honestly dont think we can ever optimize it enough for even the fastest
servers to deal in 1000 avatars, though i do hope we can atleast get to
around 100 or more.  One test I have done recently that throws a monkey
wrench into my thinking about this, my Region (OKC) Ka which is about 12000
prims and running just over 1000 scripts, when trying to log into the region
with just 1 avatar that is wearing a 1700 prim avatar that uses every single
attach point, i am 100% unable to log into the sim ever.  One other thing to
note is that my avatar has between 11k-12k inventory items and basiclly
trying to access any simulator with more than about 1000 variously textured
prims in the ballpark of about 500+ textures or so (even afer running the
predecode-j2k) i am unable to log in at all.  So again if 1 avatar cant
access the sim, i personallly dont see 1000 avatars entering a  simulator
anytime soon if at all ever, atleast like I said in the 1 server world, this
is probably going to require some major hardware/pipes to achieve.

Neb
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Nebadon Izumi]

Minor mistake in my last posting, it should have read (8000 variously
texture prims in the ballpark of about 500+ texures or so).

and since i am recommenting again, i think its important that when we talk
about 1000 users, we are not talking about 1000 ruths with zero inventory
and not chatting and doing real world things, pcampbot is a horrible
representaion of 1000 like i said before every 1000 pcampbots is probably
not even equal to 20 real world avatars actually doing something with the
simulator.

Neb

On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi wrote:

> the only bad thing about bringing up the Pcampbot login test was at the
> time pcampbot was not pulling assets down from the scene locally to itself,
> so realisticly those 1000 pcampbots were probably generating about the same
> amount of login traffic that about 10-20 avatars would have been likely.
> The only real solution to this problem will likely be load balancing and
> many servers working together to break the 100 avatar limit, the chances
> that 1 server will be serving 1000 avatars is completely impossible, i
> honestly dont think we can ever optimize it enough for even the fastest
> servers to deal in 1000 avatars, though i do hope we can atleast get to
> around 100 or more.  One test I have done recently that throws a monkey
> wrench into my thinking about this, my Region (OKC) Ka which is about 12000
> prims and running just over 1000 scripts, when trying to log into the region
> with just 1 avatar that is wearing a 1700 prim avatar that uses every single
> attach point, i am 100% unable to log into the sim ever.  One other thing to
> note is that my avatar has between 11k-12k inventory items and basiclly
> trying to access any simulator with more than about 1000 variously textured
> prims in the ballpark of about 500+ textures or so (even afer running the
> predecode-j2k) i am unable to log in at all.  So again if 1 avatar cant
> access the sim, i personallly dont see 1000 avatars entering a  simulator
> anytime soon if at all ever, atleast like I said in the 1 server world, this
> is probably going to require some major hardware/pipes to achieve.
>
> Neb
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Chris Hart]

If a 1700 prim avatar using every attach point is not a mildly extreme
case I don't know what is! J The same rules apply to OpenSim as it does
on SL - performance and headcount depends on the crowd you get in for an
event and the design of the sim itself. Build a sim with many thousands
of highly textured prims and complex scripts and you might as well just
cut down your ram, step down your processor, and accept defeat. Code
optimisation is nothing without a little care and attention on the part
of the sim designer to make the experience as smooth as possible for
attendees.

 

Maybe there's a requirement / option to have an "event" mode where you
block all attachments and deny access to inventory items to maximise the
number of visitors if you really want to get 1000 users in a confined
space, and consider using some texture simplification on the regions in
question, configurable for a region server at startup?

 

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: 26 January 2009 17:01
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

 

Minor mistake in my last posting, it should have read (8000 variously
texture prims in the ballpark of about 500+ texures or so).

and since i am recommenting again, i think its important that when we
talk about 1000 users, we are not talking about 1000 ruths with zero
inventory and not chatting and doing real world things, pcampbot is a
horrible representaion of 1000 like i said before every 1000 pcampbots
is probably not even equal to 20 real world avatars actually doing
something with the simulator.

Neb

On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi 
wrote:

the only bad thing about bringing up the Pcampbot login test was at the
time pcampbot was not pulling assets down from the scene locally to
itself, so realisticly those 1000 pcampbots were probably generating
about the same amount of login traffic that about 10-20 avatars would
have been likely.  The only real solution to this problem will likely be
load balancing and many servers working together to break the 100 avatar
limit, the chances that 1 server will be serving 1000 avatars is
completely impossible, i honestly dont think we can ever optimize it
enough for even the fastest servers to deal in 1000 avatars, though i do
hope we can atleast get to around 100 or more.  One test I have done
recently that throws a monkey wrench into my thinking about this, my
Region (OKC) Ka which is about 12000 prims and running just over 1000
scripts, when trying to log into the region with just 1 avatar that is
wearing a 1700 prim avatar that uses every single attach point, i am
100% unable to log into the sim ever.  One other thing to note is that
my avatar has between 11k-12k inventory items and basiclly trying to
access any simulator with more than about 1000 variously textured prims
in the ballpark of about 500+ textures or so (even afer running the
predecode-j2k) i am unable to log in at all.  So again if 1 avatar cant
access the sim, i personallly dont see 1000 avatars entering a
simulator anytime soon if at all ever, atleast like I said in the 1
server world, this is probably going to require some major
hardware/pipes to achieve.

Neb

 

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.12/1909 - Release Date:
25/01/2009 18:13

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Nebadon Izumi]

well i think your sorta missing the point, say i did reduce my avatar login
footprint by 10, that would only mean that if 10 people simulatanously
logged in, which if your talking about 1000 avatars at once is going to
happen, it means that you will get the same results if 10 avatars hit at
once, so honestly even if we reduce the footprint by 90% we still have the
same problem on logins, the biggest problem i see is mass login, when your
talking about getting 1000 avatars into a region for a single event,
especially if it crashes you could be potentially looking at over 100
avatars trying to log in at the same time, how do we handle this??  if your
talking about 1000 avatars you need to talk about exteme usage case, not
just fractional usage.

Neb

On Mon, Jan 26, 2009 at 10:17 AM, Chris Hart  wrote:

>  If a 1700 prim avatar using every attach point is not a mildly extreme
> case I don't know what is! J The same rules apply to OpenSim as it does on
> SL – performance and headcount depends on the crowd you get in for an event
> and the design of the sim itself. Build a sim with many thousands of highly
> textured prims and complex scripts and you might as well just cut down your
> ram, step down your processor, and accept defeat. Code optimisation is
> nothing without a little care and attention on the part of the sim designer
> to make the experience as smooth as possible for attendees.
>
>
>
> Maybe there's a requirement / option to have an "event" mode where you
> block all attachments and deny access to inventory items to maximise the
> number of visitors if you really want to get 1000 users in a confined space,
> and consider using some texture simplification on the regions in question,
> configurable for a region server at startup?
>
>
>
>
>
> *From:* opensim-dev-boun...@lists.berlios.de [mailto:
> opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Nebadon Izumi
> *Sent:* 26 January 2009 17:01
> *To:* opensim-dev@lists.berlios.de
> *Subject:* Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
>
>
> Minor mistake in my last posting, it should have read (8000 variously
> texture prims in the ballpark of about 500+ texures or so).
>
> and since i am recommenting again, i think its important that when we talk
> about 1000 users, we are not talking about 1000 ruths with zero inventory
> and not chatting and doing real world things, pcampbot is a horrible
> representaion of 1000 like i said before every 1000 pcampbots is probably
> not even equal to 20 real world avatars actually doing something with the
> simulator.
>
> Neb
>
> On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi 
> wrote:
>
> the only bad thing about bringing up the Pcampbot login test was at the
> time pcampbot was not pulling assets down from the scene locally to itself,
> so realisticly those 1000 pcampbots were probably generating about the same
> amount of login traffic that about 10-20 avatars would have been likely.
> The only real solution to this problem will likely be load balancing and
> many servers working together to break the 100 avatar limit, the chances
> that 1 server will be serving 1000 avatars is completely impossible, i
> honestly dont think we can ever optimize it enough for even the fastest
> servers to deal in 1000 avatars, though i do hope we can atleast get to
> around 100 or more.  One test I have done recently that throws a monkey
> wrench into my thinking about this, my Region (OKC) Ka which is about 12000
> prims and running just over 1000 scripts, when trying to log into the region
> with just 1 avatar that is wearing a 1700 prim avatar that uses every single
> attach point, i am 100% unable to log into the sim ever.  One other thing to
> note is that my avatar has between 11k-12k inventory items and basiclly
> trying to access any simulator with more than about 1000 variously textured
> prims in the ballpark of about 500+ textures or so (even afer running the
> predecode-j2k) i am unable to log in at all.  So again if 1 avatar cant
> access the sim, i personallly dont see 1000 avatars entering a  simulator
> anytime soon if at all ever, atleast like I said in the 1 server world, this
> is probably going to require some major hardware/pipes to achieve.
>
> Neb
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.12/1909 - Release Date:
> 25/01/2009 18:13
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Chris Hart]

I certainly don't see 1000 on a single region as remotely possible under
current architecture, not disputing that. I do have to wonder what
people consider as being an event suitable for 1000 people in a single
region - that's a lot of people in not a lot of space (though thinking
in three dimensions might help), but what do you gain from such an
event? Chat alone would be almost overwhelming, and with 95% of
attendees not knowing how to pan the camera most of them would see
nothing but the head of the person infront of them - so I guess if you
want to emulate real life, you got it.

 

You're right to push the parameters to the extreme, because in the
absence of 1000 friends to test a simultaneous login, we all have to
improvise, so if it's a case of loading up as many avatars as possible
with all clothing layers made with high-res textures, wearing a thousand
prims each, etc. then yes, it's not an entirely unreasonable scale test.

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: 26 January 2009 17:19
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

 

well i think your sorta missing the point, say i did reduce my avatar
login footprint by 10, that would only mean that if 10 people
simulatanously logged in, which if your talking about 1000 avatars at
once is going to happen, it means that you will get the same results if
10 avatars hit at once, so honestly even if we reduce the footprint by
90% we still have the same problem on logins, the biggest problem i see
is mass login, when your talking about getting 1000 avatars into a
region for a single event, especially if it crashes you could be
potentially looking at over 100 avatars trying to log in at the same
time, how do we handle this??  if your talking about 1000 avatars you
need to talk about exteme usage case, not just fractional usage.

Neb

On Mon, Jan 26, 2009 at 10:17 AM, Chris Hart 
wrote:

If a 1700 prim avatar using every attach point is not a mildly extreme
case I don't know what is! J The same rules apply to OpenSim as it does
on SL - performance and headcount depends on the crowd you get in for an
event and the design of the sim itself. Build a sim with many thousands
of highly textured prims and complex scripts and you might as well just
cut down your ram, step down your processor, and accept defeat. Code
optimisation is nothing without a little care and attention on the part
of the sim designer to make the experience as smooth as possible for
attendees.

 

Maybe there's a requirement / option to have an "event" mode where you
block all attachments and deny access to inventory items to maximise the
number of visitors if you really want to get 1000 users in a confined
space, and consider using some texture simplification on the regions in
question, configurable for a region server at startup?

 

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: 26 January 2009 17:01
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

 

Minor mistake in my last posting, it should have read (8000 variously
texture prims in the ballpark of about 500+ texures or so).

and since i am recommenting again, i think its important that when we
talk about 1000 users, we are not talking about 1000 ruths with zero
inventory and not chatting and doing real world things, pcampbot is a
horrible representaion of 1000 like i said before every 1000 pcampbots
is probably not even equal to 20 real world avatars actually doing
something with the simulator.

Neb

On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi 
wrote:

the only bad thing about bringing up the Pcampbot login test was at the
time pcampbot was not pulling assets down from the scene locally to
itself, so realisticly those 1000 pcampbots were probably generating
about the same amount of login traffic that about 10-20 avatars would
have been likely.  The only real solution to this problem will likely be
load balancing and many servers working together to break the 100 avatar
limit, the chances that 1 server will be serving 1000 avatars is
completely impossible, i honestly dont think we can ever optimize it
enough for even the fastest servers to deal in 1000 avatars, though i do
hope we can atleast get to around 100 or more.  One test I have done
recently that throws a monkey wrench into my thinking about this, my
Region (OKC) Ka which is about 12000 prims and running just over 1000
scripts, when trying to log into the region with just 1 avatar that is
wearing a 1700 prim avatar that uses every single attach point, i am
100% unable to log into the sim ever.  One other thing to note is that
my avatar has between 11k-12k inventory items and basiclly trying to
access any simulator with more than about 1000 variously textured prims
in the ballpark of about 500+ textur

Re: [Opensim-dev] Opensim-dev Digest, Vol 17, Issue 83

[Ralf Haifisch]

Heho,

there has been a JIRA i can remember where a "only allow avatar up to x
attachments" function was discussed.

The avatar lagmeter in the viewer was born from this idea.


And I guess, the idea is still pretty cool - would love to have that.


Cheers
Ralf

---
Date: Mon, 26 Jan 2009 17:17:33 -
From: "Chris Hart" 
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
To: 
Message-ID: <6abfbbbfa9738e47a00f30bc3c74171c1da...@kitt.ct.local>
Content-Type: text/plain; charset="us-ascii"

If a 1700 prim avatar using every attach point is not a mildly extreme
case I don't know what is! J The same rules apply to OpenSim as it does
on SL - performance and headcount depends on the crowd you get in for an
event and the design of the sim itself. Build a sim with many thousands
of highly textured prims and complex scripts and you might as well just
cut down your ram, step down your processor, and accept defeat. Code
optimisation is nothing without a little care and attention on the part
of the sim designer to make the experience as smooth as possible for
attendees.

 

Maybe there's a requirement / option to have an "event" mode where you
block all attachments and deny access to inventory items to maximise the
number of visitors if you really want to get 1000 users in a confined
space, and consider using some texture simplification on the regions in
question, configurable for a region server at startup?

 

 

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Cristina Videira Lopes]

It should be possible to have regions larger than 256, at least in 
multiples of 256. The LL client assumes that as the size, and that is 
hardocded all over the place (regionhandles etc), so if we continue to 
use this client we need to live with that;  but I strongly suspect it is 
possible to trick it, to some extent.

Mircea Kitsune wrote:
> I too had this wish for Opensim, but gave up on it understanding it 
> would be too difficult to implement and would hold too many issues. 
> Sure, region *x* arrangements are possible and commonly used, but it 
> does cause more complexity that way and moving all of them together or 
> tweaking each individually could be a bit harder.
>
> My idea back then was being allowed to create regions in powers of 2 
> (eg: 256x256 as now, then 128x128 smaller or larger 512x512). First 
> thing which wouldn't work here however would be positioning them 
> correctly over certain X and Y coordinates in order to fit smaller 
> sims around larger ones, which would end up causing grid coordinates 
> such as 1000.5, 1001.25. Second, I don't think the client actually 
> supports simulators larger then 256 x 256 so the client would probably 
> need modifying as well to do that. Third, exporting and importing 
> settings and stuff (such as terrain or .oar archives) between 
> different sizes of simulators could be problematic and buggy. And 
> fourth, larger single sims could possibly cause performance issues 
> even with computers in our days.
>
> If some of these issues didn't exist though this might be doable and 
> could be fun. Anyway the best practical way at the moment are region 
> groups of 2x2 or 3x3 or how many you wish for having a larger square, 
> which isn't that bad in the end.
>
> 
> From: adama...@hotmail.com
> To: opensim-dev@lists.berlios.de
> Date: Mon, 26 Jan 2009 07:46:04 -0300
> Subject: [Opensim-dev] Regions larger then 256x256
>
>   Like there are the problem of performance when we have more than 
> 15/20 avatares inside one sim , I believe that is important to have 
> regions smaller than 256x256. By example, a "mini-region" having  
> 32x32. Using grid and a server for each of 64 glued mini-regions we 
> can have a superpopulated area of 256x256   running well.
>  
> Americo
>
> 
> check out the rest of the Windows Live™. More than mail–Windows Live™ 
> goes way beyond your inbox. More than messages 
> 
> 
> Invite your mail contacts to join your friends list with Windows Live 
> Spaces. It's easy! Try it! 
> 
>  
>
> 
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>   

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Frank Nichols]

I personally think that there are two issues here - one is the current 
architecture and the other is the future. I think that while working on 
current "pragmatic" solutions we should always have in mind the future - 
the future to me is unlimited concurrent online and the number of agents 
within a giving location/area being limited to only how close each can 
be packed - ie. how many college students in a phone booth.

So, when adding/changing/fixing the pragmatic, we should always ask 
ourselves does this advance us to the future, stand in place, or regress 
toward the past...

Chris Hart wrote:
>
> I certainly don’t see 1000 on a single region as remotely possible 
> under current architecture, not disputing that. I do have to wonder 
> what people consider as being an event suitable for 1000 people in a 
> single region – that’s a lot of people in not a lot of space (though 
> thinking in three dimensions might help), but what do you gain from 
> such an event? Chat alone would be almost overwhelming, and with 95% 
> of attendees not knowing how to pan the camera most of them would see 
> nothing but the head of the person infront of them – so I guess if you 
> want to emulate real life, you got it.
>
> You’re right to push the parameters to the extreme, because in the 
> absence of 1000 friends to test a simultaneous login, we all have to 
> improvise, so if it’s a case of loading up as many avatars as possible 
> with all clothing layers made with high-res textures, wearing a 
> thousand prims each, etc. then yes, it’s not an entirely unreasonable 
> scale test.
>
> *From:* opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Nebadon Izumi
> *Sent:* 26 January 2009 17:19
> *To:* opensim-dev@lists.berlios.de
> *Subject:* Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
> well i think your sorta missing the point, say i did reduce my avatar 
> login footprint by 10, that would only mean that if 10 people 
> simulatanously logged in, which if your talking about 1000 avatars at 
> once is going to happen, it means that you will get the same results 
> if 10 avatars hit at once, so honestly even if we reduce the footprint 
> by 90% we still have the same problem on logins, the biggest problem i 
> see is mass login, when your talking about getting 1000 avatars into a 
> region for a single event, especially if it crashes you could be 
> potentially looking at over 100 avatars trying to log in at the same 
> time, how do we handle this?? if your talking about 1000 avatars you 
> need to talk about exteme usage case, not just fractional usage.
>
> Neb
>
> On Mon, Jan 26, 2009 at 10:17 AM, Chris Hart  > wrote:
>
> If a 1700 prim avatar using every attach point is not a mildly extreme 
> case I don't know what is! J The same rules apply to OpenSim as it 
> does on SL – performance and headcount depends on the crowd you get in 
> for an event and the design of the sim itself. Build a sim with many 
> thousands of highly textured prims and complex scripts and you might 
> as well just cut down your ram, step down your processor, and accept 
> defeat. Code optimisation is nothing without a little care and 
> attention on the part of the sim designer to make the experience as 
> smooth as possible for attendees.
>
> Maybe there's a requirement / option to have an "event" mode where you 
> block all attachments and deny access to inventory items to maximise 
> the number of visitors if you really want to get 1000 users in a 
> confined space, and consider using some texture simplification on the 
> regions in question, configurable for a region server at startup?
>
> *From:* opensim-dev-boun...@lists.berlios.de 
>  
> [mailto:opensim-dev-boun...@lists.berlios.de 
> ] *On Behalf Of *Nebadon 
> Izumi
> *Sent:* 26 January 2009 17:01
> *To:* opensim-dev@lists.berlios.de 
> *Subject:* Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
> Minor mistake in my last posting, it should have read (8000 variously 
> texture prims in the ballpark of about 500+ texures or so).
>
> and since i am recommenting again, i think its important that when we 
> talk about 1000 users, we are not talking about 1000 ruths with zero 
> inventory and not chatting and doing real world things, pcampbot is a 
> horrible representaion of 1000 like i said before every 1000 pcampbots 
> is probably not even equal to 20 real world avatars actually doing 
> something with the simulator.
>
> Neb
>
> On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi  > wrote:
>
> the only bad thing about bringing up the Pcampbot login test was at 
> the time pcampbot was not pulling assets down from the scene locally 
> to itself, so realisticly those 1000 pcampbots were probably 
> generating about the same am

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Ideia Boa]

I think it was a te5t not a te2t
:)


Dr Scofield wrote:

MW wrote:
  

But do we standardize on one variant or standardise on that?

Sorry couldn't stop myself :)



that was a test :-) or was that a tezt? :-D

DrS/dirk


  
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Dirk Krause]

My original point was exactly the one both of you made – there are two 
different use cases:
1) the ability to access a full featured avatar with the ability to walk, talk, 
dress etc - like it is now. I didn’t want to touch this first, but when I read 
Sean Dague analysis (keyword: N^2) from a couple of hours ago, I am not sure if 
everything is done from a technical architecture side to achieve the best 
performance. 

So my point was rather
2) that there is a use case for this 'event mode'. But instead of blocking all 
attachments and Ruth everyone, I would introduce this mode of what I called a 
lightweight agent.

Being able to create events with a couple of people acting and the majority of 
people recepting it, could IMHO be a big advantage over the original SL 
limitation that could really make a difference from a strategic standpoint for 
OpenSim as a software solution.



Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Chris Hart
Gesendet: Montag, 26. Januar 2009 18:32
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

I certainly don’t see 1000 on a single region as remotely possible under 
current architecture, not disputing that. I do have to wonder what people 
consider as being an event suitable for 1000 people in a single region – that’s 
a lot of people in not a lot of space (though thinking in three dimensions 
might help), but what do you gain from such an event? Chat alone would be 
almost overwhelming, and with 95% of attendees not knowing how to pan the 
camera most of them would see nothing but the head of the person infront of 
them – so I guess if you want to emulate real life, you got it.

You’re right to push the parameters to the extreme, because in the absence of 
1000 friends to test a simultaneous login, we all have to improvise, so if it’s 
a case of loading up as many avatars as possible with all clothing layers made 
with high-res textures, wearing a thousand prims each, etc. then yes, it’s not 
an entirely unreasonable scale test.

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: 26 January 2009 17:19
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

well i think your sorta missing the point, say i did reduce my avatar login 
footprint by 10, that would only mean that if 10 people simulatanously logged 
in, which if your talking about 1000 avatars at once is going to happen, it 
means that you will get the same results if 10 avatars hit at once, so honestly 
even if we reduce the footprint by 90% we still have the same problem on 
logins, the biggest problem i see is mass login, when your talking about 
getting 1000 avatars into a region for a single event, especially if it crashes 
you could be potentially looking at over 100 avatars trying to log in at the 
same time, how do we handle this??  if your talking about 1000 avatars you need 
to talk about exteme usage case, not just fractional usage.

Neb
On Mon, Jan 26, 2009 at 10:17 AM, Chris Hart  wrote:
If a 1700 prim avatar using every attach point is not a mildly extreme case I 
don't know what is! ☺ The same rules apply to OpenSim as it does on SL – 
performance and headcount depends on the crowd you get in for an event and the 
design of the sim itself. Build a sim with many thousands of highly textured 
prims and complex scripts and you might as well just cut down your ram, step 
down your processor, and accept defeat. Code optimisation is nothing without a 
little care and attention on the part of the sim designer to make the 
experience as smooth as possible for attendees.
 
Maybe there's a requirement / option to have an "event" mode where you block 
all attachments and deny access to inventory items to maximise the number of 
visitors if you really want to get 1000 users in a confined space, and consider 
using some texture simplification on the regions in question, configurable for 
a region server at startup?
 
 
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: 26 January 2009 17:01
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
 
Minor mistake in my last posting, it should have read (8000 variously texture 
prims in the ballpark of about 500+ texures or so).

and since i am recommenting again, i think its important that when we talk 
about 1000 users, we are not talking about 1000 ruths with zero inventory and 
not chatting and doing real world things, pcampbot is a horrible representaion 
of 1000 like i said before every 1000 pcampbots is probably not even equal to 
20 real world avatars actually doing something with the simulator.

Neb
On Mon, Jan 26, 2009 at 9:55 AM, Nebadon Izumi  wrote:
the only bad thing about bringing up the Pcampbot login

Re: [Opensim-dev] Source tree cleanup

[Dr Scofield]

while we are on the topic of cleaning up: could we move OpenSim/Region/Modules/*
to (appropriate) subdirectories under OpenSim/Region/Environment/Modules? at
least to me it's not clear what the difference between those two directories is
(made worse by the fact that we have SvnSerializer in OpenSim/Region/Modules but
 the OAR archiver in OpenSim/Region/Environment/Modules.

if there are no objections, i'd even do the move ;-)

cheers,
DrS/dirk


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] A Online HyperGrid Link list forOpenSim's 2ndbirthday

[Brianna]

I have had a few region/grid owners hint that HG is too complex to setup for 
our Birthday.
!!WRONG!!
I find is is very easy to enable, fast and reliable in use. 
Though I prefer to use a scripted TP with osfunction to the map, either method 
is simple.
Show off your hard work, for the virtual tourists.

If I can, anyone can.
  - Original Message - 
  From: Diva Canto 
  To: opensim-dev@lists.berlios.de 
  Sent: Friday, January 16, 2009 9:14 AM
  Subject: Re: [Opensim-dev] A Online HyperGrid Link list forOpenSim's 
2ndbirthday


  These are all great ideas. The only problem is whether someone will be able 
to pull this off in time for the celebrations. I might take on this, except 
that I have another trip coming up, and I'd rather spend my OpenSim-time until 
then making sure that TPs are rock solid; so I don't think I'll have time to do 
this.

  The next best thing is this list:
  http://opensimulator.org/wiki/Hypergrid#Public_Hypergrid_Nodes

  People can add their node info there; and everyone else can add that info to 
their startup_commands or whatever other link-region means they use.

  In the UCI Grid, for example, I already have several of those nodes on the 
Map; I will add all of them as they show up on that list. And i'll also add any 
others that are not there but that show up on this other list:
  http://opensimulator.org/wiki/Second_Birthday

  So, unless someone pulls something automated soon, plan B is to do it 
manually.

  MW wrote: 
well I wasn't planning/hoping to be the one who hosted this list myself. 

I was hoping that someone in the community would make a simple website and 
host it. 

I guess if no one else takes it up, then I'll have to see.

Brianna  wrote: 
  I changed the scope of what we were building for a Birthday event and 
deleted Hypergrid work. 
  Yours will be perfect, please drop the info so we can place a teleporter 
- web link for our guests to your show n tell for Hypergrid. Thanks MW

- Original Message - 
From: MW 
To: opensim-dev@lists.berlios.de 
Sent: Friday, January 16, 2009 5:31 AM
Subject: Re: [Opensim-dev] A Online HyperGrid Link list for OpenSim's 
2ndbirthday


I think this is a great idea, but the questions that come to mind, are: 
how is the mapping handled for these sub lists and how does a user say that 
they don't want these sub lists on their map. I think the number of options 
required could be quite high and think its something that needs some thought 
before any attempt to add these functions is made.

Dahlia Trimble  wrote: 
  It might also be interesting if there could be some sort of p2p 
transfer of hypergrid links, where a web site might send a list of seed 
regions, and as a link were made of each of those regions, another exchange 
could occur where each party exchanges a list of public regions. That way a 
larger grid could configure itself and individual regions could join in without 
requiring an update to a central web site.


  On Thu, Jan 15, 2009 at 8:11 AM, MW  wrote:

I've just added some very initial support for reading Hypergrid 
link data from xml files, that includes support for the xml files being on a 
webserver.

The xml file has a format like:




  
   
   
   

   
   

 
  
   ...
 

 ...

And to make a region load it and create the links, you use the 
console command:  link-region  []

The excludeList parameter is so that certain links in those xml 
files are ignored.

With the format: excludeList[;]. 

The main thinking for this is so that a single list for a certain 
group/event could be created. Then everyone interested in it, just adds their 
own region data to the list. 

But so they can also point their own region at that list, they just 
add the section name they used to the exclude list, so that it doesn't try to 
link to itself.

If we can find a way of having a xml file on a webserver that 
people can add new entries to (maybe through a form script). Then I think it 
would be a good idea to have such a list for OpenSim's 2nd birthday.

Although this idea really needs some sort of automapping or at 
least better configuration of the map locations that the regions are placed at. 

I think if everyone just agrees that a certain area on the map [so 
say x,y - x+25, y+25] is reserved for link regions, that it is workable for 
now. 

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



  ___
  Opensim-dev mailing list
  Opensim-dev@lists.berlios.de
  https://lists.berlios.de/mailman/listinfo/opensim-dev




---

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Dr Scofield]

Ideia Boa wrote:
> I think it was a te5t not a te2t
> :)

oop5, m3 b4d.

Dr5/d1rk
> 
> 
> Dr Scofield wrote:
>> MW wrote:
>>   
>>> But do we standardize on one variant or standardise on that?
>>>
>>> Sorry couldn't stop myself :)
>>> 
>>
>> that was a test :-) or was that a tezt? :-D
>>
>>  DrS/dirk
>>
>>
>>   
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator

[Teravus Ovares]

Currently, PCampBot downloads all of the textures for each client it
connects with.  This makes it a better load tester then it was
previously.

Best Regards

Teravus

On 1/26/09, Dirk Krause  wrote:
> My original point was exactly the one both of you made – there are two 
> different use cases:
> 1) the ability to access a full featured avatar with the ability to walk, 
> talk, dress etc - like it is now. I didn't want to touch this first, but when 
> I read Sean Dague analysis (keyword: N^2) from a couple of hours ago, I am 
> not sure if everything is done from a technical architecture side to achieve 
> the best performance.
>
> So my point was rather
> 2) that there is a use case for this 'event mode'. But instead of blocking 
> all attachments and Ruth everyone, I would introduce this mode of what I 
> called a lightweight agent.
>
> Being able to create events with a couple of people acting and the majority 
> of people recepting it, could IMHO be a big advantage over the original SL 
> limitation that could really make a difference from a strategic standpoint 
> for OpenSim as a software solution.
>
>
>
> Von: opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Chris Hart
> Gesendet: Montag, 26. Januar 2009 18:32
> An: opensim-dev@lists.berlios.de
> Betreff: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
> I certainly don't see 1000 on a single region as remotely possible under 
> current architecture, not disputing that. I do have to wonder what people 
> consider as being an event suitable for 1000 people in a single region – 
> that's a lot of people in not a lot of space (though thinking in three 
> dimensions might help), but what do you gain from such an event? Chat alone 
> would be almost overwhelming, and with 95% of attendees not knowing how to 
> pan the camera most of them would see nothing but the head of the person 
> infront of them – so I guess if you want to emulate real life, you got it.
>
> You're right to push the parameters to the extreme, because in the absence of 
> 1000 friends to test a simultaneous login, we all have to improvise, so if 
> it's a case of loading up as many avatars as possible with all clothing 
> layers made with high-res textures, wearing a thousand prims each, etc. then 
> yes, it's not an entirely unreasonable scale test.
>
> From: opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
> Sent: 26 January 2009 17:19
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
> well i think your sorta missing the point, say i did reduce my avatar login 
> footprint by 10, that would only mean that if 10 people simulatanously logged 
> in, which if your talking about 1000 avatars at once is going to happen, it 
> means that you will get the same results if 10 avatars hit at once, so 
> honestly even if we reduce the footprint by 90% we still have the same 
> problem on logins, the biggest problem i see is mass login, when your talking 
> about getting 1000 avatars into a region for a single event, especially if it 
> crashes you could be potentially looking at over 100 avatars trying to log in 
> at the same time, how do we handle this??  if your talking about 1000 avatars 
> you need to talk about exteme usage case, not just fractional usage.
>
> Neb
> On Mon, Jan 26, 2009 at 10:17 AM, Chris Hart  wrote:
> If a 1700 prim avatar using every attach point is not a mildly extreme case I 
> don't know what is! ☺ The same rules apply to OpenSim as it does on SL – 
> performance and headcount depends on the crowd you get in for an event and 
> the design of the sim itself. Build a sim with many thousands of highly 
> textured prims and complex scripts and you might as well just cut down your 
> ram, step down your processor, and accept defeat. Code optimisation is 
> nothing without a little care and attention on the part of the sim designer 
> to make the experience as smooth as possible for attendees.
>
> Maybe there's a requirement / option to have an "event" mode where you block 
> all attachments and deny access to inventory items to maximise the number of 
> visitors if you really want to get 1000 users in a confined space, and 
> consider using some texture simplification on the regions in question, 
> configurable for a region server at startup?
>
>
> From: opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
> Sent: 26 January 2009 17:01
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
>
> Minor mistake in my last posting, it should have read (8000 variously texture 
> prims in the ballpark of about 500+ texures or so).
>
> and since i am recommenting again, i think its important that when we talk 
> about 1000 users, we are not talking about 1000 ruths with zero in

[Opensim-dev] weird idea #2: inworld applications

[Dirk Krause]

Hi,

this thing came up when I was thinking about what to do for OpenSims 2nd 
birthday.

I thought it would be really funny to reconstruct the Sony Home Arcades in 
OpenSim, basically for giggles. I unfortunately don't have access to Sony Home 
for now so I don't know exactly what effort it means to model this, being not a 
good builder myself (for reference - http://tinyurl.com/def8fn )

The interesting point would be the ability to play either MAME or C64 games on 
the machines in these 'OpenSim Home (tm) Arcades'. So I looked up a C# c64 
emulator on the web ( http://tinyurl.com/bobw9y ) but then came to think where 
such an emulator would run.

(the following holds probably true for all kinds of applications running in the 
OpenSim context, namely:
- graphic-heavy c# or c++ applications
- flash/silverlight/moonlight applications
- 'co-browsing', works in Rex with this nice trick: 
http://therexfiles.cybertechnews.org/?p=183 )

So, to stick with the arcade example, the good question is - where does the 
process run?
I think there are these possibilities in general
1) SERVER - the application totally runs on the server side. One av takes over 
the game machine and his key strokes are transmitted to the server (via HUD?) 
and the emulator creates the graphic output. This would be a series of textures 
(not really good) or a video stream of sorts.
2) CLIENT - the applications totally runs on the client. This is possibly the 
easiest way to implement it (and out of scope for opensim-dev) since it needs 
hacking the client. But just for the record: as soon as the client detects 
arcade.jp2 as the texture, it fires up ye old space invaders and 
renders2texture the graphic output to the client.  Other people would see either
a) nothing but the standard texture as long as they are not playing it or
b) a screenshot every 5 secs or so,  since the client sends every 5 secs or so 
a screenshot to the server, updating the view for the cheering bystanders
c) the real game, since their clients also fire up the emulator, receive the 
key strokes from the current player (while they are near him) which must be 
sent from the server of course. 
3) BOTH- the application runs on both server and client with synchronicity 
calls every N secs with some prediction by the client side when the calls don't 
get through fast enough (basically like networked physics in professional games 
works)

All in all you are in synchronicity hell the more 'real' the output for 
everyone gets because there can be no real simultaneousness.

So sorted by applications:
- Physics:
either only server sided (like it is now) which is sufficient for most use 
cases, or both when the physics is fast and heavy like in games.
- Video:
Number 2c is used to play video in SL right now - one av activates the script 
that start the media playing on all clients in the vicinity. if they didn't 
activate media support then they see nothing. If they did the video starts on 
all clients, probably 1 to N secs off each, depending on their network, also 
slowly drifting into asynchronicity the longer the video runs. If it should be 
more synchronous then a streaming server is mandatory.

- Turn based games
could be implemented completely on server side. So a simple text adventure 
(Zork, anyone) or even a MUD could be implemented even on a different server 
with a gateway of sort. Come to think of it this could even be a tty terminal.
  Same goes for 
- co-browsing web pages, powerpoint projectors
Could be either server sided (like it is now via the php render trick) or 
client sided (via the Rex trick)

So the interesting part stays where to implement, say, a moonlight application? 
Let's say people want to create micro/casual games or small apps,then it would 
be interesting to see whether there would be an infrastructure to hook these 
things into?

I would even go so far that there could be a mechanism that handles LL or OS 
scripts in a way that it either runs on the client (libomv Test.exe with some 
script) or on the server side (the existing scripting architecture).

Best regards,
  Dirk/Barth
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev