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.
-- going to 32bit heightmap values is going to create database blobs that
are 100s of megabytes for varregions;
-- 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
-- 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.Anyway, I think the change it ints is a bad idea. -- ra On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue <[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]> 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]>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]>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] >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [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 >> >> >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
