On pe, 2010-10-08 at 08:37 +0200, Peter Steinlechner wrote: > support. A 1x1km region would be comparable with 16 regular regions > now, without border crossing effect. How was the memory/cpu usage? I > hope this feature will be available in the near future.
Region (an) # show stats MEMORY STATISTICS Allocated to OpenSim : 59 MB On mono in 64bit linux, running that 1km*1km region in standalone. Normally in 3d systems empty space doesn't take any memory, the size of the scene itself doesn't matter. Because the data is essentially points. Example: small region with two objects: a = object(pos=10, 10, 1) b = object(pos=15, 10, 1) huge region with two objects: a = object(pos=100000, 10, 1) b = object(pos=200000, 10, 1) so those two datasets take the same amount of memory. the problem i got with the 10km*10km attempt was something related to terrain or map tile making, perhaps it made a map tile that big writing that to sqlite was too much for my laptop .. hopefully can disable that somehow to get that bigger test done too :) what matters is what you have in the scene: how many objects, how are you processing those (i have ODE disabled 'cause it crashed, perhaps has some 256m assumption in opensim-ode still), and if you have a terrain how do you deal with that etc. i'm quite confident we can make e.g. big quite complex city scenes like this, when just make it with suitable sized meshes (like an object for a whole block or something, if it is e.g. a city racing game or planning vis). that way the object count won't be huge and opensim should be happy. sharing load for different computers and processes etc. is certainly still necessary at least when you have a lot of interactions (especially people) running around in your big scenes, there the linden multiregion system is one solution, but also many kinds of other solutions are there (like just distributing the physics calcs on a server cluster but still having a unified scene communicated to client to make the protocol simpler. the guys at intel research are afaik looking into this sort of stuff related to opensim). > Pedro ~Toni > > On Fri, Oct 8, 2010 at 1:38 AM, Toni Alatalo <ant...@kyperjokki.fi> > wrote: > http://www.youtube.com/watch?v=MOE_WNX05W0 (be patient the > flight takes > a while :) > > we agreed to do this test already in April or May, but the one > who we > figured would do this has been busy with other stuff, so has > been > pending. > > requires opensim 0.7 so now that i had it running for other > reasons > (added a http frontend to an image rendering service there, > but that's a > topic for another post :) figured to do this to finally see > how things > work out. > > worked out of the box, i didn't need to do anything. except > disable ODE > 'cause it crashed. and i tested 10km * 10km first, but that > ended up > with the terrain module creating a huge map image or something > and > writing that to sqlite trashed my laptop so had to kill that > process. > > couldn't put meshes there 'cause modrex doesn't work with 0.7 > yet, but > with that and the new terrain entity-components in Naali now > this should > become really usable (you can now put several terrain entities > in one > scene/region in naali against taiga, and if not yet, later set > their > size and resolution too). > > our plan has been to first test big regions and ensure that > Naali > doesn't have artificial region size limits before possibly > looking into > seamless continuous sl style multiregion support. i think for > many > applications single big regions suffice, but there are of > course others > where separate but for the user continous multiple regions are > needed. > > ~Toni > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
