Darb Dabney’s OpenSim Blog

This experience was on 3 June but I’m only writing about it now. Much the same as on Monday where the regions start up like gangbusters, terrain loads in a snap, and everything is navigable with no prims. When I get myself to the most interesting terrain, at UCB’s Greek Theater, I rez a cube and it sits on the ground. When I carelessly resize it to 10 meters in all dimensions, part of it sits below ground. After all, it is not physical yet. Then when I set it to be physical, either as a cube or after making it a sphere, the whole sim crashes. Looking at Mantis I had the sense that some aspects of this issue have been worked on very recently and resolved. So far for me, no joy.

I also have a challenge with getting region and asset storage working on MySQL rather than SQLite. People need persistence for any difficult build, and when things get large that’s not the time one wants to run up against the limits of the storage technology. But I’m flummoxed by the necessary OpenSim.ini config. I’ve seen this work on other sims at earlier revisions, so I know that I’m close. But I can’t get OpenSim to connect, although I have no problem getting to the catalog with MySQL-administrator and I do see some tables get created if I leave SQLite for region storage and MySQL for asset. But when I try to use MySQL with all storage, OpenSim complains that it can’t find a responsive instance of MySQL. Suspicions are pointing toward my mixed use of localhost loopback 127.0.0.1 and local network address 10.x.x.x among OpenSim and MySQL installs. Even though I run standalone, I need OpenSim to respond to the local network address to access OpenSim from other machines in the lab, and I thought that I had MySQL set up to do the same. Apparently some connections must use loopback and that may be creating inconsistencies that keep me from launching OpenSim in a non-SQLite setup

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]

Today I would like to share the inside production notes (it’s quite low tech for the most part) on making terrain sculpties. I have included a full region’s worth of working raw terrain, and a set of four megaprim sculpties that should help to clarify some of my mutterings in earlier posts. Stuff like precisely which values go into the sculptie gradient maps (shown in a spreadsheet), what it looks like when one takes textures that are 960×960 and add a 64-pixel-extent collar around them, and how to actually configure a region to load and display the 250-meter square at Military Grid Reference System / US National Grid 10SEG_6550_9200, with all the necessary bumpmap and texture files, and instructions for both OpenSim console-side and SL client-side actions.

obdam_40h_php This is how I have created the 40 regions using MGRS / US National Grid naming convention, particularly if the terrain has been scaled to 1.024:1 so that exactly 250×250 meters of RL terrain are loaded into each OpenSim region.

obdf_2_7_f32 This is a single region’s raw float terrain file. The original input digital elevation model had been gridded to have postings every 30cm in X and Y. The nominal scale for OpenSim terrain is 1 meter in X and Y. For large grids of real-world regions, there is reason to scale things up slightly so that there are exactly 16 regions per square kilometer. When one does this, as I have here, the samples are 977 mm and the real-world scale is 1.024:1 or a couple of percent larger than life.

sculpt_gradients_132 is the magic for the sculpties, all one needs to do is take the precise spreadsheet values and create three 8-bit grayscale images from them, using a raster program of your choice, to fit 132×132 size for use as a starting point. Then in the middle 130×130 area of the Z-value image (third or blue channel), insert your 8-bit rescaled values of terrain surface. After that, stack the X, Y, and Z grayscales together as Red, Green, and Blue channels to make a single RGB that will be your UV bumpmap.

Working Example single terrain megaprim bumpmap and texture
This is a single sculptie bumpmap+texture set intended to be placed on a megaprim named ‘nw’ that is sized with ‘edit-scale nw 132 132 164′ on the OpenSim console.

Full 1.024:1-scale region with f32 terrain and four megaprim terrain sculpties This is the real deal, one of the 40 regions in the Open Berkurodam sim and I think it’s an interesting part of its steeper area. The link is to a 10MB zip file that is named for the 250-meter square MGRS/US National Grid region that it represents: 10SEG_6550_9200, the grid point at its southwesterly corner. This archive contains a single-float terrain “obdf_2_7.f32″ raw file ready for loading into an OpenSim region; the file name results from a raster dicing script and this is the second region down and seventh region over from the northwesterly corner of the 40-region sim. The archive also contains four pairs of bumpmap+texture Targa files; their file name results from the same dicing script but the indices are higher because these are quarter-region areas.

10SEG_6550_9200_xml Region configuration file for the following example (I neglected to include it above)

To try out the full region set, take an available OpenSim region, and load in the terrain from the OpenSim console with the following sequence

change-region 10SEG_6550_9200
terrain load obdf_2_7.f32
terrain bake

Next, seed the region with four prims. I tend to fly into the middle of the region or teleport and turn left 90 degrees so I am facing northerly, drop four cubes a few meters apart, then name them by their quadrant: ‘nw’, ‘ne’, ’sw’, and ’se’, ensuring that the Prim’s new names have stuck by checking at least one. Then I fly to the outer edge of the region, or just over into the next southerly one. This is not strictly necessary, but it feels like the right thing to do, sort of like walking a safe distance away after having set four large underground charges. That’s because the next step involves super-sizing. In my lab, the OpenSim server is an Ubuntu Linux box running Mono 1.2.6, but my SL client is on Windows XP, and I switch between machines on a KVM switch going from the OpenSim console to SL client, and it is so much easier to see the megaprims if you aren’t inside them after they have been inflated. On the console:

edit-scale nw 132 132 164
edit-scale ne 132 132 164
edit-scale sw 132 132 164
edit-scale se 132 132 164

The Z value is the one I use in the steepest part of the sim, and this makes some really big cubes. I tend to pull them apart far enough to tell them apart.  Be careful here–I’ve hung a sim that was running fine for a week by planting the seed prims not close to the center and then dragging the centroid of the megaprim over into the next region. Sometimes when handling these megaprims it’s handy to ensure that you have the SL client’s draw distance maxed out to 512 meters, and also to zoom the view out from default one notch with “CTL-8″ to trade of field of view with distance from the prims you are handling. So when you’ve got one of the megaprims selected for editing in the SL client, move them into position by keying locations into the Object tab while being very careful not to touch the values in the Size category (thus saving yourself a visit back on the OpenSim console to reinflate the megaprim) When using but four terrain sculptie megaprims per region, their positions in X and Y are always the same, and the Z position will depend on how you’ve rescaled your floating-point terrain to fit into the 8-bit unsigned approximation. For the example megaprims that I have posted, use these:

Prim ‘nw’ XYZ = 64, 192, 188
Prim ‘ne’ XYZ = 192, 192, 188
Prim ’sw’ XYZ = 64, 64, 189.5 (tweaked for amphitheater vs. region terrain)
Prim ’se’ XYZ = 192, 64, 188

Once I can see that the prims have snapped to fully cover the region and are all nearly the same height, I change their Building Block type to Sculpted and see four really large apples that may be somewhat subterranean. If I hadn’t already done so, I use File > Bulk Upload to get all the bumpmap and texture Targa files into inventory. When you have four megaprim sculpties, you should choose the following for Object/Sculpt Texture and Texture/Texture:

Prim ‘nw’ Sculpt = ‘ob40_03_13_z3.tga’ ; Texture = ‘ob40e_03_13.tga’
Prim ‘ne’ Sculpt = ‘ob40_03_14_z3.tga’ ; Texture = ‘ob40e_03_14.tga’
Prim ’sw’ Sculpt = ‘ob40_04_13_z3.tga’ ; Texture = ‘ob40e_04_13.tga’
Prim ’se’ Sculpt = ‘ob40_04_14_z3.tga’ ; Texture = ‘ob403_04_14.tga’

For the sort of appearance that looks best at first, I have kept the background color in the texture to all 255’s and set the Full Bright to checked. That setting does not do well when it’s night in the sim, but it overcomes some sort of fade that is visible in the texture around the edges of the sculptie when Full Bright is not set. More improvements for the future!

Deep thanks to Adam Zaius for pointing out that I hadn’t really made clear these details in the blog. Enjoy!

I’ve gotten into a groove with planting the terrain megaprims, and covered the eastern part of the UC Campus. I’ve also grabbed a video with FRAPS but it’s taking a while to upload to YouTube.

Things I learned tonight: it’s possible to crash OpenSim by dragging megaprims across region boundaries. The warning sign is that the prim appears to lose its name, then all prims in the region lose their names, then a check of the console will show no more OpenSim running!

After a couple of technical issues, I am pleased to offer some machinima views

This is a shot starting at the Greek Theater on the UC Berkeley campus (20080430)
http://www.youtube.com/watch?v=86IVMafq3ik

This is simply how the Open Berkurodam sim looks in its overview map with 40 Regions.
I haven’t refreshed the appearence of the map since loading in the real-world terrain (20080430)
http://www.youtube.com/watch?v=hvGLmtTY0uI

This is a flight eastward over some bare ground, but real-life terrain regions. Flight is in the vicinity of BANCROFT AVE between SHATTUCK AVE and TELEGRAPH AVE (20080430)
http://www.youtube.com/watch?v=56PfQp9viqE

This is a flight into the land of Terrain Megaprim Sculpties.  Of the three scales, this shows the medium and large steepness areas in easterly campus.  At the time this was shot, there were fifteen regions with 60 megaprim sculpties in a contiguous area (20080430)
http://www.youtube.com/watch?v=Q9cElvejrxo

This is a flight from the high point of the sim starting at Lawrence Berkeley National Laboratory, over the Greek Theater, and ending near Wurster Hall at UC Berkeley (20080501)
http://www.youtube.com/watch?v=uBlbB72cpUQ

This is a flight starting near the old Pacific Film Archive building, through an excavation at Underhill Field that was open on 1 July 2006, then up PIEDMONT AVE to GAYLEY AVE past California Memorial Stadium and up to the far NEly corner of the sim in LBNL (20080501)
http://www.youtube.com/watch?v=cealA1QL59s

Enough Videos already!  While you’re at YouTube, check out “OpenSim” as a search term, if you haven’t already!

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.

I’ve been intrigued by the press release brought to my attention about IBM Virtual Data Centers
There’s plenty to check out with a new 0.5 version of opensim, although when I built it on the Core2 machine here I did not experience a difference from 0.4 that stood out immediately. (That’s fine by me!)

I’ve got new terrain to try out: a 30cm grid posting based on a LiDAR survey from Alameda County Public Works, plus a research-grade LiDAR survey for USGS GeoEarth Scope on the Hayward Fault. Might be time to consider a 2X or 3X model just hollywood pokerpoker sexi gratisholdem poker downloadgioco streep pokergiocare a poker on linegioca pokerpoker in lineapoker no onlinetornei poker on lineplay poker,play poker online,play wize pokercasino tropez bonus codemigliori bonus casinovideo poker on line,giochi on line video poker,video poker on line gratisgiochi keno inlinearegole della roulettegiochi black jackvideo poker online gratisjack black in lineasoftware roulettecasino tropezforum casino on linecasino venezia on linegiocare alla roulettevendita video pokerinternet gamblingroulette online gratisslots machine gratistrucchi video pokercasino gioca,casino game,casino gamingquestionario casino on netsistemi per rouletteprofessional video pokergioco della roulettekeno gratiscasino poker gratiscasino italia gratiseuro casinoil gioco della roulettevideo poker online gratis,video poker gratis,giochi gratis video pokerslots casinoadvanced video poker,giochi video poker,video pokergioco di roulettecasino online certificatikeno inlineavideo slotsweb casinolive poker game,poker game,play poker gamelive poker gamepoker tipholdem poker to see how well one might display crown of road, gutters, catchmens, and storm drains. Hey, with a physics engine, they might catch marbles and model drainage.