Yes sorry, I meant 50 - I get confused since the lower number is more compression.
I would like to revert my in-memory short -> int change and double the compression instead. However, this would mean a terrain height resolution of 2cm. Even though the weakest terrain tool changes in my testing are orders of magnitude greater than this resolution, I'm still concerned about the effect on existing terrains where objects may have been positioned very accurately or where physics may be a factor.
At this point, >327m heights will now work again on 256x256 regions because of their legacy approach of storing terrain data in doubles. However, varregions will still not work with >327m heights because they use Int16 for storage and I haven't changed that.
As varregions are new in this release and have never previously worked with >327m heights, I propose to leave that as the case for now. I do think this is less than ideal, as it means different limits on 256 and varregions (not that we actually police limits), but changing the storage format is not something that I want to do at this release stage and I know quite a few of your concerns centred around this.
It also struck me that if one is using ints then it would make more sense just to use floats. However, I'm trying to do the minimal code changes necessary right now and I was concerned about introducing bugs on double -> float conversions (e.g. [1]).
Also, I want to apologise if you're unhappy that I went and introduced this change without talking with you further. Ordinarily, I would have done this but I was under the impression that you would be away for a while and not picking up e-mail. I was anxious to get the remaining major issues squashed to make the first release candidate possible so just took the plunge. Possibly this was the wrong decision.
[1] http://stackoverflow.com/questions/6640742/convert-double-to-float-without-infinity Regards, Justin On 29/04/14 23:53, Mister Blue wrote:
if the variables are going to stay ints, then 200 would just mean more detail. Actually, if you are going to use ints, might as well go to floats and use a compression factor of one. That would give the range people want and use the same memory as ints. -- mb On Tue, Apr 29, 2014 at 12:39 PM, Justin Clark-Casey <[email protected] <mailto:[email protected]>> wrote: Sounds good. On another topic, any further thoughts about using a compression factor of 200 on terrain for this release? On 29/04/14 03:29, Mister Blue wrote: I checked in changes to BulletSim which default the ground plane to -500 instead of zero. There is a new BulletSim parameter of "[BulletSim]TerrainGroundPlane = -500" which allows that to change. I haven't yet finished looking through the terrain loading and storing code so there could still be problems with loading and restoring negative terrain heights, but it looks like the code will work once you get the terrain negative. Please test. If found in my testing that there are checks for zero scattered around OpenSimulator. For instance, LowerSphere.cs (the terrain brush used for lowering terrain) will not lower terrain below zero. -- mb On Mon, Apr 28, 2014 at 3:05 PM, Justin Clark-Casey <[email protected] <mailto:[email protected]> <mailto:jjustincc@googlemail.__com <mailto:[email protected]>>> wrote: I don't think there should be too many places. I know there are a few on teleport and MakeRootAgent (as Austin pointed out) but it looks like it should be fairly simple to check real terrain height, which might already be done anyway and be masked by the zero check. It does work in general as it has been possible with ODE. On 27/04/14 18:13, Mister Blue 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@phoenixviewer.____com <mailto:cinder.roxley@__phoenixviewer.com <mailto:[email protected]>> <mailto:cinder.roxley@ <mailto:cinder.roxley@>__phoeni__xviewer.com <http://phoenixviewer.com> <mailto:cinder.roxley@__phoenixviewer.com <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]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[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]> <mailto:[email protected] <mailto:[email protected]>__> <mailto:[email protected] <mailto:[email protected]> <mailto:[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]> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>> <mailto:Opensim-dev@ <mailto:Opensim-dev@>__opensimu__lator.org <http://opensimulator.org> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>>> http://opensimulator.org/cgi-______bin/mailman/listinfo/__opensim-____dev <http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev> <http://opensimulator.org/cgi-____bin/mailman/listinfo/__opensim-__dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev>> <http://opensimulator.org/cgi-____bin/mailman/listinfo/__opensim-__dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev> <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]> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>> <mailto:Opensim-dev@ <mailto:Opensim-dev@>__opensimu__lator.org <http://opensimulator.org> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>>> http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev> <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]> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>> <mailto:Opensim-dev@ <mailto:Opensim-dev@>__opensimu__lator.org <http://opensimulator.org> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>>> http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev> <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]> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>> http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev> <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev <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] <mailto:[email protected]> <mailto:Opensim-dev@__opensimulator.org <mailto:[email protected]>> http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev <http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev> <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 <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] <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] 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
