Archive for April, 2017

Apr 25 2017

Terrain: solved; Platform: Unity;

Published by under SL In General

Following a catch-up read last night of Metaverse Ink from 2011 with many thanks to Prof. Crista Lopes of UCI Informatics for writing it.

Why not?  Unity appears to have a San Francisco SOMA presence, FWIW.  A few hours later, a “Duh” moment.  Why wait so long to go this way?  Why be so intent on synchronous state sharing among distributed clients?  No more questions, just an image to show Unity 5.6.0f3 in action.

Terrain is full-res 1-meter digital surface model, although it has been compressed to unsigned short (u16) integer decimeters with a 10-meter bias to cover creek bathymetry.  Believe me, the effect of negative signed integers on an unsigned int terrain is not pleasant, and the creeks looked like they’d been turned into vertical columns of stratospheric steam.  The swath shown below is 1024 m X 6144 m, has terrain values every square meter, and spans terrain elevations from about 1 m up close to 784 m up high.  At first glance this might look like a green cousin of the obelisk from the movie 2001: A Space Odyssey but in fact it is the fully detailed oblique view of a strip of rendered terrain shown without any atmospheric effects, which makes for some disorienting foreshortening.

I’m still patching terrain 1K-meter squares together manually for a demo.  But this is really looking professional-grade!  Strategically, although this slice of terrain is in Marin county, California, the terrain blocks have been positioned at San Francisco coordinate system of 2013 (WKID/EPSG 7131) so I’m actually using Unity 3D to edit in a GIS grid system.  That opens up the possibility of pouring Vast Tracts of Data into the model from sources like MarinMap.

Unity terrain

Unity 5.6.0f3 Marin dsm1m and MarinMap rgb20cm of 2014

No responses yet

Apr 21 2017

Terrain, yes, and flat orthos

Published by under SL In General

Next reach goal: draping the orthos as terrain textures.

To run better on a 1 vCPU, 1 GB machine with 3GB swap on an EBS SSD drive, the extent was pared back from 8K square to 6K square.  Orthophotos were resampled at 20cm and placed on flat 1km square prims.  Everything aligns with San Francisco county grid (EPSG/WKID 7131.)  This shot is Twin Peaks, view easterly, at sunset.  Look close in the pass and you can see Test User Ruth to verify the scale.  The orthophotos have been placed on both top and bottom of the image prim.

OpenSim 6K model of San Francisco with 20cm orthophotos

Open Simulator 0.9.0-rc2, running on CentOS 7, Amazon t2.micro

No responses yet

Apr 16 2017

Darb Returns to OpenSim at 0.9

Published by under SL In General

The reasons for a return are several, but not that important. The thread that led to this started with a frustration over certain household members’ copious use of the Roblox environment—from a consumer side. The next step was to think “My, but Roblox is little more than a hybrid of Lego/Minecraft figures with a bit more of a Second Life creative side.” After that it was a reactivation of the dormant Darb Dabney account on Second Life itself. Spending some accumulated Linden$ led to a parcel on Jessie, and some of the old muscle memory for builds was reconnected.


Next, now that the site can be found again, I realized that there was some new content, a few new faces among the product developers, and a willingness to trade off compatibility with the Linden viewer for an incorporation of larger areas and other useful features—a conscious fork from the Linden path.

So when I finished a load testing project and found myself with 48 more weeks of free-tier Amazon EC2 server, I took a pure CentOS 7 image and went after OpenSim once again. This Easter weekend offered a bit of time to figure out how the tools have all changed, for the better!

I stood back from ArcGIS Pro to avoid distractions and used ArcGIS 10.5 for Desktop to simply design an edit and perform a clip on the stock San Francisco Enterprise GIS Program’s (SFGIS) 50 cm terrain grid, then resampled it to 1 m gridding. The City and County of San Francisco’s new grid system (WKID or EPSG 7131) is ideal as a foundation for OpenSim grids: it’s metric, astronomically aligned,and reasonably small numbers for X and Y coordinates.

I started out getting a 2 km square region going, which was enough to learn what OpenSim needs for local IP ( and Public IP, where I assigned an Amazon Elastic IP address, then set up DNS to give the server its subdomain here on ``. I found that the Linden Second Life Viewer 5.0.3 appears incompatible, but I was able to connect with Singularity Viewer 1.8.7 and see what I needed regarding terrain loads.

Although there are plenty of formats now accepted for terrain maps, many of them are integer-valued and the SFGIS grid is all single precision floating-point so there seems little reason to clobber that precision just to load a grid. Through a variety of tests, I settled on using ArcMap to clip the raster to a square 8192×8192 meter or 6144×6144 meter sample, and saved that in ERDAS .img format. That clip was exported to a GeoTIFF that Adobe Photoshop CC 2017 can read. Mercifully, HDR photography and video has now brought floating-point grayscale into the realm of photographers so I didn’t need to use ERDAS Imagine application. Photoshop made the necessary vertical flip so that OpenSim can read the raster from bottom to top (how backwards!) Then, I opened the flipped no-longer-a-GeoTIFF in a fresh ArcMap document, ignored its lack of georeference, and applied ArcTools > Conversion Tools > From Raster > Raster to Float to produce what Esri calls an .flt file, which is effectively a raw IEEE floating-point array—no header or other information. It is exactly 4xGrid Cells in size. This was renamed to a .r32 for use by OpenSim, and uploaded to the EC2 server using WinSCP.

On the server, I used a binary distribution of opensim- and dropped the .r32 in its ./bin directory. The CentOS 7 server was configured to have MySQL (14.14 Distrib 5.7.18 x86_64) and Mono (4.8.0) in order to run the dot net CIL OpenSim.exe and make the server fly.

It was necessary to configure OpenSim to use MySQL rather than the default SQLite, because the extended regions create huge increases in detail and thoroughly exceed limits of SQLite. The 6144×6144 produces an array of 24×24 or 576 Linden regions’ extent. The 8192×8192 upper limit to OpenSim 0.9 forms an array of 32×32 or 1024 Linden regions’ extent.

MySQL defaults had to be expanded at `/etc/my.cnf` and allow big globs of BLOB data, so I added this line to that file, and ran `systemctl stop mysqld; systemctl start mysqld`

To survive the really large regions, the EC2 server needed to be configured for swap, and to make that a bit safer, I added a 2 GB EBS volume housed on SSD, which is the fastest arrangement allowed on this size server.

Notable for this weekend’s efforts was that real San Francisco terrain, with no vertical exaggeration, and 1:1 real-world scale were all used—a first for me, at least with > 500 regions. Here’s a reflection from Twin Peaks, at 1:1 scale, in OpenSim 0.9 running on an Amazon EC2 server at t2.micro (free-tier elegible, 1 vCPU, 1 GB memory, 8 GB disk, 2 GB swap.)


No responses yet