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 <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev
<http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
