Jun 13 2008

Classified LiDAR data have been viewed

Published by under SL In General

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

elevation view of classified LiDAR Classified LiDAR of UC Berkelye vicinity
this is how the classified image looks with intensity shading. It gives a first impression like a photo
classified LiDAR near UC Berkeley more detailed view of UC Berkeley area

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
Northeasterly perspective view of LiDAR Easterly view of UCB campus in classified LiDAR

No responses yet

May 06 2008

Berkurodam 1:25 map on Agni – 1:3 BART Station still online

Published by under SL In General

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.

1:25 scale Index map in Second Life 1:25 scale index map in standard Second Life grid

1:25 scale index map in Second Life standard grid 1;25 scale index map in Second Life standard grid

1:25 scale index map in Second Life standard grid

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.

The shortest video is 0:39 and can be viewed here

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

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

No responses yet

Apr 23 2008

Terrain megaprim refinements

Published by under OpenSim,Scale Issues,SL In General

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.

Three zone design for terrain Here is how the terrain maps out versus the buildings

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

Overlay of ortho with 3-zone terrain 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.

No responses yet

Apr 18 2008

OpenSim svn 0.5.4_4272 Supporting 40 regions

Published by under OpenSim,SL In General

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.

40-region UC Berkeley OpenSim 40-region OpenSim at UC Berkeley 40-region OpenSim of UC Berkeley at 1.024 : 1


No responses yet