Elf Clan Social Network

In a recent issue of Hypergrid Business there appeared an article talking about grids offering larger regions at no additional cost.  HB quotes one of the grid owners:

"“We don’t raise the price as long as they don’t need to scale the server resources,” he said. This means that long as region renters continue to have the same amount of prims, scripts and other content, the land that this content sits on can be expanded at no additional cost."

An expanded region means the same prim count and resources are applied to the region... but the land itself is expanded in size.  The popular configurations seem to be 512x512 and 768x768.  There are many advantages to this (credit: some of this borrowed from Hypergrid Busienss ):

Standard regions:

Four regions running as separate region in a single instance of OpenSim.

  • Four sims each with a separate server
  • Works with all viewers.
  • Border crossings can be rough on vehicles and avatars.
  • Each region bears full region cost:  $ x 4
  • Four different region names on the map.
  • Can only be saved as four separate OARs.

4-region varregion in one simulator

  • Four or more times the land, same number of prims as a single region
  • Works on a single server.   Cost:  $ x 1. 
  • No added costs server-side, "elbow-room" benefits customer-side
  • Greater customer enticement-- more room for the same money.
  • Works only with the latest viewers, such as  FirestormKokua or Singularity.
  • No teleport issues due to viewer support.
  • One single region name on a map.
  • More room for scenery

  • More "elbow room", encouraging exploration.

  • More realistic land feel (we don't feel like we're living on a postage stamp)

  • Greater realistic simulation-- land space rather than builds being crowded together.

  • Saved as one large OAR file.

This was recently discussed in an Inworldz forum, and at least for the current time discarded.  Yet when the "competition" begins such process... such a step may be inevitable (somewhat like mesh, which was practically forced on Inworldz due to a mesh adoption by Second Life). 

This is something I perceive as an essential trend of Virtual Reality future.  So thought I'd post it here as an "item of note" for consideration.

-- Wayfinder


Views: 250

Comment by Zauber Paracelsus on June 19, 2014 at 11:21am

That table with MegaRegions has inaccurate data.  You're showing data for VAR Regions, which are a radically different competing implementation, and anyone taking that table at face value will run into problems if they try megaregions out for themselves.

As well, MegaRegions are nothing new, and they have been around for about as long as InWorldz has.  If they really were such a killer feature, all the other grids would have eaten the InWorldz grid's lunch by now.  In reality though, I've heard greater demand from people for smaller regions because normal ones are just too big for them.  They want region sizes such as 64x or 128x, since 256m is simply more than most ordinary users need, which is also part of the reason why parcel rentals are popular.

Also, on the InWorldz forums, Tranquillity made the statement "I don't consider bigger regions a win, I consider them a compromise for not being able to achieve nice regions crossings."  His meaning is the same as the aphorism you've commonly used to critisize Linden Lab, "treating the symptoms instead of curing the disease".

And on that note, that is exactly why opensim implemented MegaRegions in the first place.  Due to system limitations in opensim, vehicle crossings did not work period, regardless of whether they were physical or non-physical (though physical vehicles had a host of other problems).  This was due to the old limitation of scripts being unable to survive teleports, region crossings, re-rezzes, or region restarts.  And that is a limitation that, as far as I know, opensim continues to suffer from.  Avination was working on something to fix it though, but I don't know how far they got, and in typical fashion I suspect that the grid owner (also the project director of opensim) has yet again chosen to withold the changes from opensim for purposes of competitive advantage.

Oh, and as another note (/me says just as he was about to submit his comment), there is a rendering bug in V2-based viewers which can cause crossings to appear more visually jarring, even if they were silky smooth.  Here's what is going on:

Terrain textures repeat across the terrain's "face" multiple times so that they are more crisp.  However, through some unusual decision by Linden Lab, they chose to set the repeats such that each repeat was 12 meters wide.  Divide 256 by 12, and you get a remainder of 4, so 1/3 of the repeat carries over into the next region.  Linden Lab coded the viewers to offset the textures of each region, so that they would stitch over seamlessly into the next region.

Under V2 viewer's, however, that code isn't working.  The result is that when you cross over into another region, you see the terrain textures visibly "jump" or "shift".  There is a common-sense workaround for the problem, however.  Go into Advanced->Debug Settings, and find the setting RenderTerrainScale, then set it to either 8 or 16 (depending on your preference).  That will ensure that it cleanly divides into the region border and avoids the problem, though going with 16 will make the terrain blurrier.  If you want it closer to what it is now, you can try setting it to 12.8, which also divides cleanly, though doing so might upset some people's OCD :P

Comment by Wayfinder Wishbringer on June 19, 2014 at 12:34pm

Good post Zauber.  And while I don't personally totally agree with all of it, it's a very good "other side of the coin" post. : )

I do agree that if they can fix region crossings and offer us land packages based on prims rather than sim count... that would be a viable solution.  If we could get land space of 512sq or 756sq with 45k prims for what we're currently paying for a limited 256sq... that would be great.   Will that actually happen?  No seer here. : )

Regarding people wanting smaller sims, there is a caveat with that:  that's not on OpenSim.  That's on Inworldz, and the reason they want smaller sims is because they want a private-sim home at less price.  They want the full capabilities and security of a privately owned sim but for $15-$20 a month instead of $75.   So if they could get say, a 128msq sim with 12k prims for $20 a month... sure they'd like that.  Who wouldn't?  : )

I've never really, ever heard anyone say, "Oh, my 256m sim is far too large!"  ; )

I have heard people say, "I don't need 256m, I need a smaller sim for less $."  And that makes sense.  I long ago stated in these blogs that the "magic golden ring" number is $25 a month for a sim.  I still believe that is the case.  It doesn't have to be 256m and 45k prims.

It can be clearly seen on the Inworldz forums that there is a great desire and need for larger land mass without incurring the cost of buying 4 to 9 sims.  We don't need more prims, we need more land... because the 256m size is too limiting for many purposes.   If Inworldz could put themselves in a position to offer a larger landmass with the same number of prims and same server requirements as a current 256m sim... that could be a major marketing winner.  However that is achieved would likely be a winner.  If Tranq can do it by making sim crossing impact not really an impact... that would work.

Comment by Balpien Hammerer on June 19, 2014 at 2:21pm

I agree with Zauber abut the OpenSim mega/var region hacks. They were and are there to workaround fatal crossing problems in the OpenSim grid. Right now the OpenSim codebase has some massive synchronization bugs that blow up scripts on crossings and can cause attachment corruption too. It's good they came up with >256m regions to get around that mess but the resulting change has created a lot of incompatibilities too.

That said, there is a compelling desire to be able to simulate space. Space itself ought not be a limiting factor if the resources to create that space are minimal or static. I should be able to say something like: I want to support 70 avatars, have 68,000 prim equivalents for region objects, 70,000 prim equivalents for attachments, permit 12,000 scripts to run, permit up to 500 HTTP connections at a rate no more than 40 requests per second each, etc. You see, all that I mentioned *does* consume resources. Right now, all those numbers are internally set and together they add up to things like how many processors are assigned to a region, how much RAM is assigned, and how much network bandwidth is permitted. Instead of charging tier by each of those factors, it is all standardized into a mix called a 'region'.

Now about land space, it turns out that in the current architecture of the OpenSim codebase (and in InWorldz too), there are issues in which having a wider palate of land space does require resources. The wind, cloud, terrain data is broken up into 16m squares, you need more of those squares to simulate the land space (and it burns memory to do that). Objects and their spatial relationship has to been coded - more land space, more memory to do that. PhysX too has a huge oct-tree (a way to describe the spatial relationship of objects) which grows with the size of the simulated land space. It's not free, not nearly so. When those folks offer those huge land spaces it burns resources, which is why you are not seeing them much. I will point out that there are other ways to simulate  scene. Blue Mars (now dead) used a more modern approach which partitions things by resources instead of simulated space. It is the way to go but it takes a deep start from scratch approach to make it happen - years of time.

And finally, the problem of sim crossings will remain even with 4x sized regions. A good air fight, a good mega ORK/Elf battle can easily span 4 region equivalents. What is being worked on right now for InWorldz is ripping out the cruddy OpenSim region crossing code and the underlying region communications code that was Band-Aid patched over and over since last year. That *was* a mistake. A costly one. The new crossings/coms code is a clean re-architecture. It will fix crossings, will fix TPs, and is a requirement to fix the nagging presence problems too. In  previous post here in this forum I gave links to videos where I showed how well crossings were working. I was dismayed to see it all fall apart, but at least now the severity of the problems were understood and Tranq took it upon himself to truly fix the mess.

Comment by Wayfinder Wishbringer on June 19, 2014 at 4:38pm

That is great news Balpien... and from what I've seen and what Tranq has said on the forums lately, what your post is spot-on.  He's tackling that issue like the ball carrier is about to cross the goal line. 

You know the back-end a whole lot better than me (especially since I know nothing about the inside of VR).  So let me ask you a conceptual question, something Tranq mentioned in 'future alternative land packages'.

Right now so far as I understand it, it "kinda" takes one core to run a sim (or is it 1/4 core?  Or a "virtual machine"?  I lost track long ago).  So, let's say we take those exact same resources and instead divide it between four 256msq sims... but with a total of 45,000 prims (11,250 per sim, but available to all four sims in whatever configuration, ie, one sim can have 5000 prims so that leaves 6,250 extra for another sim to use).

So we still have the 45,000 prim limit, we're using no more resources... and there's the conceptual question:  could that be done so that it uses no more resources than are being used now?

The reason I ask is because while it may be a big boon to a customer to have more land available... if it doesn't cost Inworldz any more to run it, 4 sims is the same as 1 sim to the company-- and would likely encourage the purchase of sims among people who have held off to this point.  End game:  huge sales point... more land for your money.

What's your thoughts on the technical end of that concept?  As far as I can tell, that's the logical alternative to "larger sims".

Comment by Balpien Hammerer on June 19, 2014 at 5:43pm

It is more complex than that. There are fixed resources for each region, no matter how large or small, so it does take more resources overall to split up the prims across four different regions. This is one reason why a 5000 prim scenic costs $20/mo compared to a 45,000 prim full region at $75/mo. You mentioned being able to shuffle those prims around.  Prims in a region (and one must include attachments) translate to memory, but regions are firewalled and compartmentalized memory to prevent the activities of one region to affect another region. Regions are not all in the same server either. You are asking for dynamic memory shuffling between regions, doable but requiring a lot of work to implement. Regions are not necessarily in the same server, so reshuffling their prims means literally sending their representation to another server and hoping there is enough RAM for them there. And finally, prims and their representation are implemented "in the matrix" as database entries scattered throughout a rather complex cloud in which they are recorded "backed up". Shuffling prims changes today's efficient simple "persist my prims in this region" into a complicated "persist the prim, move it to some other region, redo the database entries to track them in the other region, etc." process. So what seems to be a simple ask turns out to have some deep and massive design changes in which some of those changes makes the moment to moment activities much less efficient, taking up even more resources to do the same thing. That translates to higher costs.

I never appreciated just what it takes to create the verisimilitude of a virtual existence until I saw the architectural diagram that Tranqility posted a few years ago. The region simulators are in the lower right hand corner and the rest of the diagram is where the data magic happens. Those big boxes are very expensive. This is why Tranq said it is a tad more than changing some variables in the code.

Comment by Wayfinder Wishbringer on June 19, 2014 at 6:04pm

Okay fair 'nuff.  So let's say we don't shuffle prims.  Instead we allow each sim 11,500 prims.  Could four sims be run on the same "server" for similar price as a single-sim system? (ie, is that a conceivable do?)

Comment by Wayfinder Wishbringer on June 19, 2014 at 6:07pm

Actually, nm.  I already have a viable answer to that one, just thinking about it myself.  : )


You need to be a member of Elf Clan Social Network to add comments!

Join Elf Clan Social Network

© 2017   Created by Wayfinder Wishbringer.   Powered by

Report an Issue  |  Terms of Service