Darb Dabney’s OpenSim Blog

With many thanks to the globe-spanning OpenSim community, I have seen the error of my sourcing ways and replaced a version of Open Dynamics Engine that I had compiled on my Ubuntu x86_64 system, on 20080220, leaving the product of that effort, libode.so, up at /usr/local/lib which seemed well and good at the time. As things have evolved, ODE was brought into opensim-libs svn at some point after the last change log entry at 20080328. I was happy to find that ODE was included in the OpenSim svn, and turned on the physics engine in my OpenSim.ini configuration file.

Where I went wrong was not clearing out the library I’d compiled back in February, because that directory was getting sourced before my latest version in each of the nine OpenSim svn builds I’ve made since April. Last night, Dahlia helped me get focused on fixing the problem that I was having and she demonstrably was not. Teravus cleared up that my issue was squarely that of ODE and nothing but ODE, and Nebadon pointed me to exactly the updated documentation that I needed to build my own new ODE for the first time since I’d migrated the test server to Ubuntu 8.04 from 7.10.

In the process, I’ve learned to expect more efficient memory usage than I’d been understaning. I had written to Nebadon that my 40 regions were using 1.4 GB of memory, but once I had to start killing processes after every sphere I’d rez, I saw that the processes that I was killing were all less than 900 MB memory. And now, with ODE, MySQL region and asset storage, and 40 regions, I get OpenSim console statistics showing 194 MB “Allocated to OpenSim”.

Here is a video of what the old ODE (20080220) did with a really big cube (25-meter sides dropped from 500 meters)

After compiling ODE from the OpenSim-libs/unmanaged trunk, and adding a few build tools to my server, I got a fresh libode.so that was 3.7 MB rather than the 3.1 MB that was distributed with svn 5234. I did not tweak any compile flags as this was from OpenSim folks’ favored setup. After ODE was working, I slept well and awoke very optimistic about my prospects for getting a demonstration public-facing by end of July. I also have enjoyed testing the performance of ODE, particularly after Dahlia shared some time on her Dev server at OSGrid.org.

With ODE running, certain physical prim movements can consume plenty of CPU cycles, and even with two avs and some complex mesh interactions, there can be striking lag. So with my own regions working once again, I wanted to see how that looked, and I was inspired by the 1967 TV series The Prisoner to create an oblate spheroid (5 m by 5 m by 4 m) as a physical prim to roll after Ruth. The first of my efforts was shot here, and as you can see, I used Rover’s Dutch cousin, as orange was much easier to see than the original Welsh white Rover.

Finally, to impart a sense of drama, I textured Rover with a menacing City of Berkeley sewer manhole cover, and finished the celebration of ODE with a long take including several region crossings and a pleasant sunset hue from Windlight. As I hope is clear with this video, OpenSim has really come a long way in the past couple of months!

I’ve been trying to be patient and catch a good wave in OpenSim’s evolution, so that I can configure a demo of terrain prims for late July. Much good seems to be afoot, and yet I am trying to find the right point amidst all this progress to grab an SVN and build on it for a few weeks. Tonight I had some luck with getting my OpenSim.ini configuration together better than before.

For all OpenSim back end storage now I’ve gotten MySQL 5.0.51a-3ubuntu5.1 working fine. I had a glitch in my configurations where I worked with a configuration setting that referred to Catalog / schema (what MS SQL folks might know only as a “database”) but interpreted as schema certain tables within that one schema known as users, userfriends, terrain, prims, land and such. For a few nights I seemed sleepily unaware that I had confused the table ‘opensim’ with the catalog ‘opensim’—my bad for naming them all the same without being sure enough what I was doing. The symptom was simply that
../cli OpenSim.exe
refused to load storage, which is to say that the sim wouldn’t start up, and refused to go more than the first few lines into a startup sequence that for my 40 regions is typically many hundreds of status lines. Anyhow, that’s all happy now and every storage invocation in my OpenSim.ini config is using the local MySQL instance through loopback. Bottom line for me was this—the OpenSim.ini and mysql_connection.ini config files are connecting to a catalog, even through in places they contain references to certain tables.

On the physics side, I’ve got ODE turned on for all 40 regions, and the startup is still very fast at less than 30 seconds with no prims. The 1-meter gridded terrain loads into 40 regions in about 15 seconds [hardware: 2x Core2 Duo E6550 overclocked to 3.4 GHz with 3.9 GB RAM]. Everything seems to be going my way until…

I try to create prims right now. Tonight at svn 5195, I can create cube prims, have them be physical and drop to the ground. When either I turn them into spheres, or create them as spheres, in regions near (where I first rez) or far (at the northeast end of my 40 region sim), the whole sim hangs brutally. I’ve never had the sim hang this way before, where it’s a ‘kill -9′ to get its attention and make it go away.

With the persistence of MySQL running, if I quickly restart the sim without taking time to command the previous “../cli OpenSim.exe” into oblivion, then I can’t log in because the second sim still thinks that I’m already logged in, from the first hung sim’s session. I flailed around a bit this evening learning this and creating new users along the way. At one point, I was so discombobulated between hung mono and typing anything *.exe on a command line that I restarted Ubuntu to wash my hands of the matter. Now wasn’t that silly? I certainly think that it was. No amount of C# code under mono is going to turn Ubuntu into the sort of bounce first, ask questions later mode favored by some Windows server administrators, including myself in impatient moments.

But whatever happens tonight at svn 5195, it appears to have an evil effect on mono when meshing a single spherical prim, or a box that’s become a sphere. This is using SL Windows client 1.19.1.4 or SL Linux client 1.19.1.4 on x86_64 Ubuntu 8.04 Hardy Heron.

Thanks to Nebadon who helped me get a pulse on my memory usage. Interesting experience tonight was that now that I’ve started using MySQL and making sure to kill off zombie ../cli processes, my memory use is down toward 780 MB, rather than the 1.4 GB I’d mentioned on IRC. At that size, there does not seem to be too much memory use penalty under Linux+mono versus native Windows servers running OpenSim. Selfishly, I’m glad of that because I’ve already switched my opensim test servers off of Windows and onto Ubuntu, and I’d prefer not to come across too many reasons to want to go back!

After mucking around a bit, I was able to use free tools to browse the contents of the classified LiDAR, then used ArcGIS 9.2 tools from 3D Analyst and ERDAS Imagine to get where I wanted to go with this surface. First, I needed to know how many returns there were, and what each of the classes meant. The LAStools info function helped there. Then I used ArcGIS 9.2 3D Analyst “LAS to multipoint” conversion tool, but selected only the first return. Multipoint was an annoying format because it did not seem to fit anywhere in the cool new ESRI “terrain” feature data type. In the end, I gave up on ESRI terrain and went straight to the classic TIN. For maximum overlap, I did not filter out any specific angle from nadir, taking whatever was sent along from the contractor to Alameda County.

Of course, I had to negotiate the treacherous 3D Analyst menu items that were necessary. Getting multipoint into a TIN required creation of a TIN (obvious, but with blank result) and then the non-obvious choice of “Edit TIN” which effectively accepted the multipoint data that were imported from LAS and allowed me to specify the delunay method of choice. Once canned as a TIN, it was a familiar step to specify a raster gridding. I haven’t found a way to reproject the TIN, so I was still in NAD83 California coordinate US Survey feet, and an assumed NAVD88-Geoid 2003 CONTUS-feet vertical while I tried several grid resolutions. In the end, I was happy with 1 foot gridding.

Then, raster on disk, I was able to reproject to WGS84 UTM zone 10 north meters, and chose bilinear resampling on a 25 cm grid posting interval. Once in my favored projection, I rescaled the Z values to NAVD88-Geoid 2003 CONTUS-meters, and began to examine the need for a bit of grayscale morphological processing. I’ve been a great fan of mathematical morphology for over 20 years, so it was a pleasure to craft a kernel or 3 to compensate for some artifacts. Because the TIN-to-grid was so highly oversampled, I was able to use a combination of a tall, narrow 7×3 kernel for morphological CLOSE, followed by a 3×3 DILATE, and a diamond-shaped 5×5 ERODE to finish off the task. In case this morphological stuff sounds like odd stuff to do, these operators are variations on focal max and focal min convolutions. The results are rather important for my application, as shown in the following images.

First is the reflective DEM surface, and the same with the Open Berkurodam 40-region overlay.

Next are more detailed images, near the Greek Theater, showing why I ran the morphological filtering and also how I was able to mostly conserve building footprint areas while inflating trees. The main artifact attenuated was interlace-type effects at the end of overlapping LiDAR scans. The long axis of the morphologcial CLOSE kernel was perpendicular to these artifacts.

Here is the morpho-filtered reflective DEM, with the 10 cm natural color imagery overlaid.

Next up, I’ll need to figure out how to best use this 25 cm surface. It really seems a shame to use it in the way that I have thus far with terrain megaprims–where using four megaprims per region I have effectively downsampled the terrain to 4.26-meter grid postings. That wasn’t so bad for the bare earth model. Here I’ve got something over 290 times denser with 0.25-meter grid surface samples.

But to use many more than 160 megaprims for the entire 40-region model, I really must automate the placement of the (auto-generated) sculpties. For that, I’ll need to ask around the OpenSim community for advice!

For the Linux SL client on my HP keyboard, (Alt- + Windows- = Alt- ) as the SL client works in Windows.

Yesterday evening I added a YouTube embed to a post, and it showed up today with a toxic URL in it. That edit was made from Windows, so tonight I’m running Ad-Aware full scan, which takes awhile. So to keep at it, I took the test server (E6550-3.4 GHz/4GB) and ran it with 40 regions standalone, real UC Berkeley terrain, and ODE; then to be testing I installed the latest now-Beta SL client 1_19_1_4 and went for it!

Things are getting ever smoother with the Second Life client for Linux. I first fired it up and went to Agni, and saw that the 1:25 scale Berkurodam model rezzed much more slowly than it did when I last tried the Windows client a couple of nights ago. I say that because I saw the ellipsoids of the sculpties, as ellipsoids, for many seconds.

Then I quit and launched with “./secondlife -loginuri host:9000″ and saw the terrain rezzing like never before. One of the wild things about OpenSim is that if you try something that you’ve done before eons ago, like three weeks, things can be different in some really good and unexpected ways. Like the speed with with terrain rezzed once I set my draw distance out to 512 meters and flew to a NEly corner of a sim. Wow, I’ve never seen so many regions filling in at once, and nary a delay for the little texture patches that follow along. It made me think that network speed limits some of the experience, even when its a local 100-Mb wire.

Anyway, I was able to saunter in flight all about the 40 regions and be fairly impressed. Then I stopped by the Greek theater site, rezzed a 10-meter cube and threw it up 1 kilometer into the air. It landed with much less bounce than I saw on the default sinc-shaped islands last night, but still looked as slippery as an ice cube while it wiggled its way into the very lowest spot of the stage area. I tried to make a machinima of the experience using the SL client feature, but I did not take time to lower my resolution from 1600×1200 for the video, and I never could find the AVI file that I expected to have made. Still, although at this point I was getting the CPUs up toward 70% at times, as soon as I cooled off and stared at the Ubuntu System Monitor, things got quiet fast, like 5% on each core.

Everything still seemed to be just ducky, until I found one more cool thing. You see, I’d been grasping about for the proper keyboard shortcuts to gain camera control on the SL Linux client. Like in Photoshop or the Windows SL client, I tend to use the keys around the space bar, Alt-, Ctl- and the arrows quite a bit. So I’ve been frustrated with the Linux client because the same Ctl-Alt combination that I want to use to spin the camera around usually does something nasty to the Gnome window when dragging the mouse. But no more. I stumbled on (what surely must be documented somewhere) the solution–the dreaded Windoze key on my HP keyboard works with the SL Linux client just the way that I expect the Ctl- key to work.

For the Linux SL client on my HP keyboard, (Alt- + Windows- = Alt- ) as the SL client works in Windows.

Once I got that grokked, I was doing some very mobile camera work for a couple of minutes, and then I tried to rez a physical sphere to see how it dropped. But it didn’t. Although my SL client was quite happy—I’d managed to hang OpenSim with this stacktrace, and now although I restart OpenSim, I can’t log in.

Native stacktrace:

../cli [0x51bb67]
../cli [0x43dacd]
/lib/libpthread.so.0 [0x7f13d3fcd7d0]
/usr/local/lib/libode.so(_Z27gim_trimesh_update_verticesP11GIM_TRIMESH+0×205) [0x7f13d06b2c75]
/usr/local/lib/libode.so(_Z18gim_trimesh_updateP11GIM_TRIMESH+0×18) [0x7f13d06b2d58]
/usr/local/lib/libode.so(_ZN9dxTriMesh11computeAABBEv+0xcc) [0x7f13d06a2a1c]
/usr/local/lib/libode.so(_ZN11dxHashSpace10cleanGeomsEv+0×34) [0x7f13d0670714]
/usr/local/lib/libode.so(_ZN11dxHashSpace10cleanGeomsEv+0×5f) [0x7f13d067073f]
/usr/local/lib/libode.so(_ZN11dxHashSpace8collide2EPvP6dxGeomPFvS0_S2_S2_E+0×39) [0x7f13d0670639]
[0x4173f5ed]

After learning how the terrain sculpties could be handled by Meshmerizer if running a physics engine like Open Dynamics Engine (ODE), I have taken a couple of weeks to proceed slowly, cautiously as I bulk up the demands on the hardware. After all, my original notion of doing large swaths of real-life terrain on a single standalone sim was based on loading that terrain into the regions then using only Basic Physics to reduce the load.

But in the months since I first started loading real terrain (starting with Mt. Tamalpais in 200710), truly phenomenal, awesome progress has been made in how efficiently OpenSim runs for me on Ubuntu/Mono. Sure, at new year 2008 my OpenSim test environment upgraded from a P3-800/1.5 GB Coppermine system to an E6550-3.4 GHz/4 GB system. But what was limiting last Fall was the chatter among the various regions, so that I could add more: 49, 81, 100 regions–but then the CPU load with no client logged in would hum up toward 70%, and running a physics engine would be a challenge with many fewer regions.

These days, that seems like a stone-age experience. The rate at which regions now load on startup is incomparably faster (even on the old Coppermine), and the chatter is almost nil–no clients logged in looks truly quiescent at 1% to 2% CPU. All this has emboldened my interest in trying ODE again. And that experience likewise is so much better. Time was, there was reason to visit the ODE site and build one’s own, and even then stuff could get strange. I was inspired by the videos that Nebadon posted showing many hundreds of blocks falling. But I experienced things like tripping over what felt like a singularity that shot my unfortunate avatar hundreds of meters into the air, bouncing like some tire that fell off of a jet after takeoff. That was then.

Now I see Ruth’s legs bend a little bit under the effects of gravity, but I do have 40 regions humming along in standalone with quiet-state CPU load of 2% to 5%. So I have plenty of reason to expect that I’ll be able to do this with the 40-region model, using terrain sculpties that are physical as long as they don’t tilt over against the terrain surface like they do in the SL Agni grid.

Video demo of Ruth narrowly avoiding getting squished by a 10-meter cube
If you’ve got the embed blocked, the link should be http://www.youtube.com/v/Jz9234jYbkw

My next goal for Open Berkurodam is to generate a new surface. I may have a good copy of what is called categorized or classified LiDAR data, where individual points in a cloud are tagged with an estimate of whether they are from bare earth, tree crown, rooftop, and such. This sort of LiDAR data should support the sort of grid that is not just bare-earth terrain, but actually has the proper size, shape, and height bump for every tree and building. This would be ideal for draping with the orthophotography, because within the limits of parallax that have been corrected in the orthoimagery, every building should sort of take shape on its own.

I don’t hold any fantasy that things will look properly immersive right on the classified LiDAR grid, but I have a sense that there will be enough detail to guide a reasonably accurate build with just a bit of training on the part of the builder to recognize their way past registration artifacts–where the bump from the LiDAR surface doesn’t align with the roof part of the orthoimage.

To bring this to a presentable stage, I hope to somehow have a live version of the 40-region UC Berkeley and vicinity 1.024:1 model with classified LiDAR surface on physical sculptie megaprims, on a public server by mid-July.

There has been a bit of head scratching as other distractions apparently clouded an obvious scale issue. The first terrain megaprim sculptie project done last month, had available imagery at 30cm.  For that, it only made sense to oversample to 25cm to make 512×512 textures.  That decision led to my adding a collar around the original 512’s until they clicked into the proper size without rescaling on a quarter-region megaprim. With Berkeley, the source imagery is almost 10cm (103mm pixels) and the challenge has been to size the resample so as to make best use of the 1024×1024 texture size limit per prim.

Where I took a wrong turn was trying to proportion the collar that was added to the 512’s, rather than going back to basic principles with sculpties. Bottom line: my efforts of the past week went astray as I allowed confusion to set in, casting about for the proper maximum texture dimensions working down from 1024. (and I’ve got the awkward attempts at 1008, 994, and 978 pixels to prove it).

In fact, the answer is very simple in reference to basic sculptie principles, as the maximum dimensions of the sculptie bumpmap are 32×32, and due to the need to wrap it around to an apex underneath, this can only represent a 30×30 terrain patch. Thus, the maximum imageable area is simply (30/32)*1024, or 960 pixels square, collared out to 1024 square to make each orthophoto tile. This means that an OpenSim 1.024:1 model can accomodate 130mm orthophoto imagery, and I now have 160 tiles ready to go with the bumpmaps.

So far I’ve configured twelve regions with their megaprims, and only one seems to have issues with the height of the sculptie to stay 30cm afloat the terrain surface. Nine of these reigons use the flattest setting, one uses the intermediate, and two use the steepest. Here’s some shots for update’s sake. The full set of orthophoto textures have been uploaded (450 MB of Targa files) and seem to show up reasonably well in inventory. I am using a local MySQL instance on the OpenSim machine for prim storage.

After spending plenty of time getting all the terrain megaprims stamped out, and starting some refinements of how to squeeze the imageable part of the ortho into a portion of the 1024 square texture, I found myself rather unhappy with how lumpy the megaprims were in the flat part of the model. Berkeley has this sort of dual terrain personality (no comment on the residents) that has certain types of details in the distal fan and floodplain parts of town to the westerly, and very different types of details in the hilly and steep areas.

When one loads the natural terrain into OpenSim, the values are 64K of single-precision floating points per region. When loading terrain into a megaprim, there are a mere 900 usable values that must be mashed into an 8-bit integer of Z values. So when the whole sim ranges from 45–267 meters (and it could go up to 581 meters if a sim ran all the way up to Vollmer Peak) , one gets dynamic range issues if all the terrain megaprims are scaled to fit over the entire sim. So to mitigate this, I divided the sim into distal (the “flats”), proximal (the “foots”) , and hills proper (easterly of the Hayward Fault).

The upside of this extra work is better fidelity in the different parts of the model when the floating point values are approximated by 8-bit integers. When I used the entire elevation range for the whole UC Berkeley sim, each integer Z value was 87 cm, or close to three feet. With the sim broken into three regions of megaprim Z-scaling, I have each integer worth 11 cm in the distal, 31 cm in the proximal, and 63 cm in the hills, so everything is a little better everywhere. I’ll fess up to not having the prim placement fully automated, otherwise it would be practical, and perhaps desirable, to use the full dynamic range over just those elevation values in the region (or even in the quadrant of the region that the terrain megaprim covers). But by that point, I’d consider even denser grids of terrain megaprims, and it would then be a different process for representing the terrain.

After all, the whole point of this exercise is to devise a work-around for not being able to load the ortho imagery directly into the region as a draped terrain texture!

Enough blabbing - please enjoy the graphics.

Here is how the terrain maps out versus the buildings

Not intended as digital Cubism, this odd-looking approach makes better terrain megaprims. Really, it does!

In case one knows particular buildings on the UC Berkeley campus or environs, this is how the zoning worked out. There is a certain logic to it, geomorphically.

I’ve been in a bit of a rut the past couple of days, feeling doubt about which way to proceed with configuring the OpenSim side of the UC Berkeley campus 1.024:1 sim. For the first time since I started setting up OpenSim test servers back in October 2007, I was uncertain of my ability to make it work with this project. I rolled back to 0.4, 0.5.0, 0.5.1, and the trunk that worked a couple of days ago would run only 32 regions well, and even at that would stop working, without any use, by morning. All my effort was going into testing out various ways of retreating from the leading edge. In an activity like OpenSim, that’s not a fun place to toil!  Now, after the sim sits quietly through the night, I can teleport from my landing zone in the far SWly region to the far NEly region, and get there pronto.  Plus the 40 Regions are barely consuming 1% of the CPUs.

Realizing that a good 48 hours had passed, one of the things I tried tonight was a fresh grab of the trunk, and that really turned things around for me. With OpenSim 0.5.4_4272 I have the same rocket-fast launch, zippy association of terrain with regions, and I can actually teleport into regions that haven’t resolved their terrain without finding my av hung up. That was all good. Then, I started moving around the ERDAS Imagine data that will be stamped into terrain megaprims, and I was reminded that I’d gone to all the trouble of resampling both terrain and orthoimage for 40 regions, and my diced file naming conventions were already dependent on that entire set of 5 x 8 regions. So rather than fire up the process for making sculptie bump-maps, I went back to the 0.5.4_4272 build, shut it down and went after my region configuration–willing to give it another try at 40 regions. While I was at it I generalized my PHP region XML configurator.

Just for the sake of enjoyment, here are a few views, including nice Windlight night shots. Compared to two days ago, one can notice more of the hill at LBNL, with the fairly intricate grading for service roads and laboratory buildings quite evident in the scene.

Enjoy!

Enough carefree hours in the main SL Agni grid, already! Back to matters of creation.

Next big thing should be a terrain prototype for civic application. No special business process in mind here, just a demo of the draped imagery on real-life terrain in a way that could scale up city-wide. For starters, there must be a better correspondence between the US National Grid and the dimensions of the simulated region. Sure Neal Stephenson may have suggested binary 2^n dimensionality, and there may be plenty of reasons in the simulator code to make use of the full range of 256 meters. But after more than a handful of regions, the starting corners get downright ugly.

So I won’t do it that way. By scaling up, larger even than real-life, the regions can be built sixteen-to-a square kilometer. In a worldwide sense, except for the matter of 62 or 64 matchlines, the US National Grid (a.k.a. Military Grid Reference System or MGRS) has the whole world in its hands, so harmonizing region design with that grid plan covers a whole lot of ground. To minimize my effort at constructing regions, while planning for worldwide sim grid extensibility, I have chosen to configure the overall sim to represent 250-meter square patches of real earth using each of its 256-meter square regions.

This scales the real-world up a shade in the sim, to (1.024 : 1) but allows every fourth region in X and in Y to start on an exact grid kilometer. That scale produces 16.0000 regions per square kilometer, rather than 15.2588 regions/square km. From the geography side of things, this harmony is attractive since every fourth region will snap to a grid kilometer instead of every 1000th region. Even at that, the grid kilometer that 1000 of those 256 meter regions snap to is 256 kilometers, which is much clumsier to locate by name.

Thus the “well-tempered” moniker for this scale is well deserved, as any real-world USNG/MGRS grid coordinate could then be used to search for the relevant simulator region from a moderately simple bit of string manipulation. For Berkeley, and the western part of California, the zone is “10S” and the 100-kilometer grid within that is “EG” for San Francisco and Berkeley area. Put together, the US National Grid designator for the 100-km square is sometimes called “10SEG”, depending on where folks do or don’t put spaces.

If we always have exactly sixteen (16) regions per square kilometer, then we can use the shorthand version of the USNG grid names that only detail down to 10-meter increments. In this way, a region with its southwesterly corner at WGS84 UTM zone 10 north, 564000 meters Easting, 4191250 meters Northing, can have the US National Grid 10-meter designation of “10SEG 6400 9125″, which could be mashed together without spaces, or used to name a simulator region such as “10SEG_6400_9125″ in a slightly more readable form. For those of us who no longer have youthful eyes, the tiny little display on the Second Life client for the region name motivates the use of spaces.

So here’s a graphic of the plan: a 40-region prototype (5 x 8 regions), which will be configured with only Basic Physics, but real-life LiDAR-based terrain, and four megaprim sculpties per region to drape imagery (10 x 16 terrain sculpties) such as 10cm natural color orthophotography. Here’s where I hope to take this:

The past four days have been a tremendous blur of internalizing NURBS into my mind, at least the SL sculptie variant of them. Now I’ve been aware for several months of how NASA used sculpted prims to represent detailed Mars craters (as published by Ireton), and I’ve certainly followed the beautiful work for David Rumsey done both by Telemorphic in 2003 (3D plots of historic Lake Tahoe area) and more recent historic Yosemite by Nathan Babcock). But there was something confusing and ultimately mysterious about using sculpties for terrain.

Not so much any more. Through several helpful blog and forum posts, and a score of hours spent in experimentation, I feel that I’ve brought the sculptie to heel for my terrain rendering purposes. Mostly, especially for OpenSim, it’s simply to display draped orthoimagery over an already precisely customized region terrain.

What I’ve learned is that for 1:1 mapping, where regional terrain is not available at more detail than the 10-meter postings from seamless.usgs.gov, then one can configure precise sculpted megaprims, only four to a region, and drape imagery quite effectively. The result is real-life imagery draped in the style of Google Earth, but coming out of a free OpenSim server into a free Second Life client, for a dozen or more regions on one server core. When using the technique that I’ve worked out, having only four scuplties to seamlessly cover the region means that the terrain sculpties will rez fully sixteen times (16X) faster than will either the David Rumsey or NASA educational islands.

There’s no special magic here: the region terrain is far superior as a way to represent real life terrain, as it can hold 64K of single-precision floating point values. A sculptie, by comparision, holds a mere 900 usable values that must be compressed to an 8-bit signed integer, for any one of the 900 points’ X, Y, or Z values that are practical to use to guide facets in a terrain “diamond”. This “diamond” is a way of describing what the terrain sculptie looks like after defining the outermost ring of UV values to wrap around to a single point safely below terrain surface, so as not to interfere with the 30×30 values useful to describe terrain in a way that cleanly tiles to cover multiple regions. The vertical scale of the terrain described this way is adjusted with the Z-dimension of the sculptie spheroid, which must be tuned using back-end OpenSim command “edit-scale” if one is manipulating a megaprim.

Anyway, when I get a chance to demo this for some Berkeley terrain, I’ll be sure to post a dramatic screen shot. As it is, the 12-region sim looks so realistic right now that almost any shot would be immediately recognizable by someone familiar with the site, so the good ones will wait for project time. Meanwhile, this one is intended to prove validity of sculpted terrain megaprims for draping orthoimagery.

The tools that I used were: ArcGIS to reproject the seamless terrain and orthoimagery into a rotated local grid variation of WGS84-UTM; ERDAS Imagine to perform mosaicking, dicing, image stretch/rescaling, and layer stacking to build precise UV maps from real life terrain; and OpenOffice.org spreadsheet to calculate precise gradient values for the X and Y components of the UV maps. On the back end was OpenSim 0.5 using region definitions in the 0.4 style, and the terrain build was performed using the standard Second Life 1.19.0.(5) client running on Windows XP with a Radeon X1300 Pro.

A couple of days later, I revisited the sim and made a couple of updates to sculpties with the new 1.19.1.(4) Second Life client, and the orthoimage colors look different depending on sun angle–thanks to Windlight.  It’s not a bad thing, and gives one a reason to look up and appreciate the beautiful sky!   Back on Agni (standard Second Life Grid) by comparison, all the prims seem far more intensely colored and somehow more detailed with the new client.