So, I’m sitting here banging my head this morning over two issues. One, why the heck is terrain never deviating from zero height, and secondly why things werent looking quite right - as you could see in the previous posts it was clearly rendering prims but things were ‘missing’ or not quite right. Turns out the answer was both.

First, Terrain.

Yesterday I got the heightfield behaving properly, but couldnt understand why it was never being set when placed onto the live feed coming from the network stack. Answer turned out I was doing something stupid and had typo’d on a variable name for my indexer. Once that was fixed, we were rendering scenes like the one below.

It’s beggining to look a lot prettier, but as you may have noticed, the prims dont appear to line up in any recognisable pattern. While there is definetely a pattern there - something is very off.

Second, Objects - Part A.

Showing this one to Easy [Babcock] in the office, we quickly worked out that infact objects were never being rotated - every object had exactly the same identical zero rotation. After a few minutes debugging, this turns out to be related to the conversion from a Quaternion to a Euler rotation for WPF. Switching from Vector3 to Media.Quaternion internally solved the problem nicely.

Here’s a view of Abbotts aerodrome with the fix inplace.

Much better, although there’s still some clumps missing.

Second, Objects - Part B.

So, it’s looking like we’ve almost got this rendering correctly. At least object shape and rotation is being displayed correctly, although there’s still something lacking. It turns out that most of the bits missing corresponded nicely with camera view - so I’ve fixed this by telling libsl to ‘rove’ the camera position around the sim to download the entire thing. The above screenshot had this fix inplace.

This solved at least terrain loading completely and most objects.

Loading it up on OSGrid in Wright Plaza - everything seems to actually render properly now, at least so far as primitives go - we’re missing sculpties right now which form a large component of Wright Plaza’s design.

Second, Objects - Part C!? Huh?

Panning our Camera around a little, we notice something a little bit … odd. Namely that around 0,0,0 there’s a large congregation of primitives. I’ve been noticing this already and had discarded it as possibly being neighbouring sims in which case, I’ll just knock them out later.

But it turns out, there’s valuable prims being thrown there - it looks to me like maybe the child primitives in link sets having their “Position” being relative to the parent primitive rather than the sim (in OpenSim we have both .Position and .AbsolutePosition to seperate these).

So, I’m going to be working on that for the rest of this afternoon - after which I’m going to play with either texture rendering, or getting Meshmeriser to work so we can discard the dependency on the black-box GPL’d rendering library.

It’s a simple enough question - often when I see a company or group get involved in OpenSim, the first thing that springs to their mind is “Well, we must launch our own grid!”, with each grid having it’s own isolated set of users, inventory, assets and regions the question must be asked: “Why?”.

But in most cases, this often isn’t the best of ideas, and short of internal uses it’s often counterproductive duplicating effort others have undertaken already. Running a grid properly takes a lot of work - especially if you are doing frequent updates, if your intent is on making it a popular destination for random visitors, then you have extra work publicizing and convincing people to create an account and login.

All in all, it’s a lot of work for relatively little benefit.

Alternatives to starting your own grid

Attach your region[s] to an existing grid - I personally like recommending OSGrid.org - one of the downsides to this approach is that you are relying on the grid provider for your infrastructure - if they either neglect to update frequently you may run into problems, likewise if they have downtime or stability problems, you are tethered to them good and bad.

So, why do it then?

The short answer is to do it for your users, if you require users to register an account on your grid to come view your trinket, you have effectively annihilated any chance of instant gratification so to speak. The difference between opening a map on a popular grid, and logging out then relogging onto your grid is huge. It requires a good deal of effort to to so.

The longer answer lies in pooling resources - in this case users, users may log in to view your trinket, but after they are done with it, go visit someone elses trinket nearby, the key here is that people who come for other peoples shinies may end up visiting yours too - there’s no zero-sum game here, and offering a multitude of attractions is more powerful a drawcard than yours alone.

When you should make your own grid?

There’s plenty of reasons to run your own grid however - the biggest one is privacy and wanting to run something entirely behind a single corporate firewall. Protecting intellectual property and trade secrets requires making reasonable protections when possible, and public grids are not well suited for this.

Another reason is when you want to run something solely independently - such as say a specific concert or event, where you know that your demands require customisations on the grid software itself. In these cases unless you are able to make an arrangement with the grid operator you may run into problems and hosting oneself is a good idea.

So which grids allow outside regions to connect?

OSGrid.org is the best for this since the entire grid is hosted externally - making sure this works smoothly is a goal of the osgrid admins. Connecting a region is free and there are no real terms of service at the moment to speak of, other than “don’t break the law.”

DeepGrid has allowed regions to connect since the beggining - although the grid server software is updated less frequently than the OSGrid ones. A common terms of service do apply for this and region spaces need to be reserved via the website first before connecting (rather than first-come-first-served, price is still free).

CentralGrid offer region connections too however connecting a region invokes a large fee that isnt charged anywhere else, for as far as I can see no advantage. I’m not impressed, but you may be.