Darb Dabney’s OpenSim Blog

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!

The classified LiDAR data that I hope will provide some inflated structure and tree surfaces for draping the orthophoto have been reviewed. I find the data beautifully detailed, and fascinating to see with GeoCUE Point View LE. I’m working with the UC Berkeley Geospatial Imaging and Informatics Facility UCB GIIF, also known as the Maggi “Kelly Lab” when proximal to Mulford Hall.

Right now my goal is to interpolate the first return surface in a way that I can grid and filter most appropriately to inflate buildings and trees. In principle, I should be able to use the first return LiDAR point cloud to create a NURB surface that would be expressible as an OpenSim/SL sculptie. But I’m going to take a more cautious approach and try to get the whole thing gridded in a consistent way so that I can reasonably expect to cover the entire 40-region sim with good inflated surfaces rather than the bare earth that has been a fine demonstration, but a bit flat for draping the orthophoto.

I’m going to throw out a lot of images and let them speak somewhat for how the classified (into ground, structure, low veg, med. veg, tall veg) LiDAR point clouds look.

Here’s the plain elevation image and the classified view of same

this is how the classified image looks with intensity shading. It gives a first impression like a photo

Some perspective views also help to show what information will be available for gridding. For these I’ve displayed with vertical exaggeration of 1.5X

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]

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.

For ease of QA, there’s nothing quite like shrinking a big multi-region project to get through faster. And to share the joy a bit, this index map is in a public space, on Agni. at Amida 16/12/30

The parcel in Agni (standard Second Life public grid) now has a 1:25 model of Open Berkurodam loaded. There are 159 of the 160 terrain sculpties in place, all with full 1K x 1K ortho image textures. If you find yourself on Agni, stop by to check out the details and see the underside of the terrain sculptie diamonds.

The location is just across the water from original 1:3 scale Berkurodam BART Station. The index map can be found in Amida 16/12/30. Give it a chance to rez, because uncompressed there are 477 MB of Targa image textures represented on 159 terrain sculpties, each of which is specified with a 132×132 bumpmap. In the interest of full disclosure, I have exaggerated the Z dimension here by 50% relative to X and Y, so that the 1:25 scale is horizontal only, and vertical scale is 1:16.6 just to make the terrain more apparent. At this scale, a lot of the immersive experience seems lost and the perspective is quite a bit like Google Earth.

Striving for multiple media channels, I have also uploaded some suitably grainy videos to offer a taste to those who can’t or won’t visit the Agni grid. Believe me, it’s a much sweeter sight at 1600×1200 with the new Windlight viewer, but if one is interested in this sort of rendering, the videos might offer some motivation to explore with the SL client proper.

The longest is 3:39 and starts in Gualala, shows a bit of rezzing of the 1:25 map, does a fairly good job of showing off the texture detail on football fields, then finishes up with a flight over to the Berkurodam BART station 1:3 model, with a glimpse inside the two underground levels.
http://www.youtube.com/watch?v=EjXyBWjGHA8

The shortest video is 0:39 and can be viewed here
http://www.youtube.com/watch?v=IaYd7XD41NY

The next video shows some of both the 1:3 Berkurodam BART station model in Gualala, and the nearby 1:25 OpenBerkurodam index map in an adjacent part of Amida
http://www.youtube.com/watch?v=-AXcDFN6LbA

There is a third one that is still uploading as of this moment

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!

The manual process I’ve been using to place the terrain megaprims is crying out for automation, but for the moment, I’ve added it only incrementally. I have three OpenSim command scripts now for the three scales of terrain megaprims, and these use edit-scale to supersize the seed prims that I am still putting, four to a reigon, in starter positions by hand.

I’ve had some trouble with my SL client not always showing me all items in inventory. Also, I fixed the one problem terrain megaprim. Apparently it was a naming convention error from when I created the three sets of different-scale terrains as 8-bit, and the problem prim was where I first realized that ERDAS Imagine dicing was starting the tile names anew for each of the rescales, and this was confusing as all three had different upper-left origins.

Even so, I’m only up to having 19 reigons populated with surface terrain sculpties. It is rather satisfying when the megaprims get sized as cubes, positioned appropriately in 3-space, then converted to giant generic sculpties—and when the proper terrain UV is applied, they just snap to the terrain like a fairly decent coat of paint the instant that I select the next prim.

The imagery is tiling very well and that is also satisfying, when I turn on Full Bright and see good detail. It seems that the key to perfect tiling is to adjust the leftmost texture tiles to have a -0.064 horzontal shift to their 1.000 scale texture, and the topmost texture tiles have an 0.064 vertical shift. The upper-leftmost tile has both. I even found a farm in Berkeley–go figure. Looks like they were growing strawberries near Oxford and Hearst on 1 July 2006.

Not to be deterred by having everything going well, however slowly, I opted to test the new distribution of Ubuntu tonight. My “save-xml” scripts ran without warning, but following the OS upgrade, and verification of graphics and browser, my load-xml script only place about one good megaprrim per region. I’ll dup them and get back on track soon. The browser (Swiftweasel) had nary a hiccup, and still runs Flash just fine. My Nvidia display driver kept on working, and I did not need to re-install it as I had been warned when first installing the driver by Envy. The default desktop has a cool Heron on it, the System Monitor has transcended its previous Windows-like aesthetic and improved the dashboard. MySQL seems to be unaffected by the upgrade. Eclipse Europa launches in about 15 seconds. Things feel just a bit faster in many departments, including the rate at which OpenSim draws land.

What’s next:
1) I’d like to finish my way through building the 40-region model on the local OpenSim server here in the lab
2) I’d like to craft a 1:25 scale model of the entire 160-sculptie terrain on Agni in a parcel on Amida not far from to the Berkurodam BART Station 1:3 model.
3) if Hardy Heron holds together for the next few days of testing, I’d like to build a public-facing version of the OpenBerkurodam model, at least as a standalone sim

.

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.