Archive for April 23rd, 2008

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