[Opensim-dev] Negative z values
Justin Clark-Casey
jjustincc at googlemail.com
Mon Apr 28 21:55:48 UTC 2014
Hi Robert,
On 27/04/14 18:24, Mister Blue wrote:
> While not on the same topic... Justin, I see that you changed the shorts into ints in the HeightMapTerrainData subclass
> of TerrainData. This is problematic for several reasons:
> -- you specified 'int' and not 'int32'. I'm not totally sure about the .NET definition but I'd expect some systems to
> choose 64 bit ints which would create GIGANTIC terrain arrays.
An int in the CLR is always System.Int32 [1]
> -- going to 32bit heightmap values is going to create database blobs that are 100s of megabytes for varregions;
In my calculations, and consistent with my actual memory measurements (though I didn't measure blob storage size), the
increase for an 8192 x 8192 variable region (equiv to 1024 'normal' regions, is 128mb which I thought was reasonable for
such a massive region, where even that memory use looks fairly small percentage of other uses (e.g. physics). But I
guess it may be blob size that you're more worried about. In fact, I neglected to change this at the database layer so
the change is not actually yet in effect there.
> -- if a more flexible internal terrain representation was needed, another sub-class of TerrainData should have been
> created ("LargeRangeHeightmapTerrainData"). That's why it is subclassable. That would also let it have a special
> database blob format that could be much smaller than simple integer arrays
but wouldn't that mean then having a range of possible storage choices with all the complexity of customization that
this entails? In this case, I really want to retain compatibility with LL bounds by default.
> -- If you just needed a large range for terrain (you talked about getting to +500 to be SL compatible), the compression
> factor could have been reduced from 100. Maybe a compression factor of 20 would give enough range for +-500 altitudes.
Yes, that's exactly what I was after, whilst preserving the ability to have -z (otherwise I would have considered
ushort). A compression factor of 20 would work for this.
>
> Anyway, I think the change it ints is a bad idea.
I didn't particularly like it but it didn't look to me like the memory requirements were unreasonable, and they were
still half of those in 0.7.6. I would have thought disk is less of an issue than this, unless you have concerns with
maximum database packet sizes (a var region with shorts already requires an increase from the defaults) or some other db
issue.
Apart from any of this, it looks like there's a lot of room for database storage improvement - one could gzip the
terrain bytes rather than writing them raw. In memory is a bit trickier whilst preserving quick access.
If you think changing the compression factor is okay then I'm happy to do this instead. It looks like the terrain blob
storage also stores/retrieves the compression factor? So in this case there would be no need to bump DBTerrainRevision
or anything similarly messy?
Dev Random also pointed out that terrain formats like terragen take a base height and a scale instead of storing a full
range [2]. That might also be an idea though it would be more difficult to fit into the LL system (can't be done via
viewer UI atm) and I want to avoid complex change this close to a release.
[1] http://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx
[2] http://www.planetside.co.uk/terragen/dev/tgterrain.html
>
> -- ra
>
>
> On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue <misterblue at misterblue.com <mailto:misterblue at misterblue.com>> wrote:
>
> When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only
> implementation reason I see for not allowing negative terrain altitudes would be finding all the random places where
> code makes sign assumptions.
>
> If negative altitudes are needed, it would not be too hard to make it happen. I can see the geographically oriented
> people wanting zero to be sea level and allowing land to be above and below that.
>
> -- mb
>
>
> On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley <cinder.roxley at phoenixviewer.com
> <mailto:cinder.roxley at phoenixviewer.com>> wrote:
>
> Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support variable depth. I'd
> certainly be willing to write a viewer patch if support cropped up.
>
>
> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders <abitar.com at gmail.com <mailto:abitar.com at gmail.com>> wrote:
>
> I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we can stack a
> deep ocean and a space sim to the normal sim :)
>
> But then again would the client handle all these changes? (partly do)
>
> So the solution is to make deep water simulators, But any test this? I never been asked to set up any sims
> with deep water so I not experience with "outside the box" water :)
>
> I was drawn to opensim with the idea of making "pure" space sims where you can float around in real space
> but I dug into it and I would have to rewrite so much code to do this and after that would the client
> handle it? So I stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago,
> back in the early days of opensim.
>
> Now times are changing, I think I might dig into doing it again since varasim allow you to make a
> 4096x4096x4096 regions :)
>
>
>
> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin <ai.ai.austin at gmail.com <mailto:ai.ai.austin at gmail.com>> wrote:
>
> At 04:09 26/04/2014, drWhiet wrote:
>
> even boat creators must keep an eye that the engine does not move below -0
>
>
> Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" terrain
> base of 0m.
>
> Maybe its global warming in the metaverse that raised the sea level :-)
>
>
>
>
> _________________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev
> <http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
More information about the Opensim-dev
mailing list