This it not about negative magnitudes for dimensions for weird mathematical constructs but simply about allow normal arbitrary positioning.
Like Justin said for example an avatar to be at <130, 50, -45>. That is perfectly normal and I think definitely should be allowed. Often it makes sense to have 0 at for example ground or water level and then have underground / underwater builds located at negative altitude coordinates. For example when modeling real world places it can be useful to have a straightforward mapping from geolocation coordinates to the scene coordinates. There the standard says that 0 is at sea level: “The altitude attribute denotes the height of the position, specified in meters above the [WGS84] ellipsoid." http://www.w3.org/TR/geolocation-API/ . It gets complex as the sea is not at same level everywhere but that's how GPS altitude works anyway, http://www.esri.com/news/arcuser/0703/geoid1of3.html . Is simple to decide that ok let's use sea level as 0 in this scene and just map geoloc altitidudes directly to the scene coords. If all locations would be forced to >0 altitudes you'd get into difficulties for example when have first decided for some scene that ok, let's put 0 at -100m underground, but then some deep mine would need to go below that. What would you do then, move the 0 to -1000m and move the whole scene 900m lower, adjust positions that scripts use for their logic etc? I would not want to do that, for no reason. Google Earth's absolute altitude mode does this too: "The absolute altitude mode measures altitude relative to sea level, regardless of the actual elevation of the terrain beneath the feature. In this way, features can be placed underground, and will not be visible. Portions of a feature can extend underground, as in the example below. Negative values are accepted, to place features below sea level. This altitude mode is useful in situations where the altitude value is known precisely. GPS tracks, for example, can use the absolute altitude mode to display paths created while flying or diving." The other modes are just to clamp to ground or calculate the position relative to sea bottom or ground -- that absolute mode is kind of the real position. https://developers.google.com/kml/documentation/altitudemode There's no technical reason with Bullet to not use also negative coordinates -- we have it integrated also in realXtend Tundra and everything works normally as you'd expect with floats. ~Toni BTW with miniplanets sometimes used in games it is typical to have 0,0,0 at the center of the planet and then use both neg and pos values on all axes. I made that too once in an old game demo, http://www.playsign.net/lunatica-2008/ . There are probably also other cases where negative values are useful also for all coordinates, not just altitude. But I understand that with the SL model with origo at the region corner it is different so that's a different discussion for another time :) On Fri, Apr 25, 2014 at 4:37 AM, Frank Nichols <[email protected]> wrote: > I don't see it as arbitrary at all. > > OS is a simulator and while it might be "fun" to play with negative > magnitudes for dimensions I expect most people (other than mathematicians) > would struggle visualizing the concept. > > If a grid wants to have extremely deep oceans, it is simple enough to > establish a grid wide water level at some "arbitrary" higher altitude. > > Also, I don't expect the dev's plan on implementing infinity as an > acceptable magnitude for a dimension either - so, there will in fact be some > arbitrary magnitude (usually limited by the size of an integer or floating > point accuracy). > > I expect other than in the code the current limits are not defined, so > designers using OS will need to be "careful" no matter what. > > Frank > > > On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams <[email protected]> wrote: >> >> Seems to me that 0 is a completely arbitrary number and that a cut-off for >> any reason other than hardware/mathematical limitations is unwarranted. I >> could see taking an "oh well" attitude about things that don't work with -z, >> but declaring the Metaverse to simply end at 0 seems very random. >> >> >> On Thu, Apr 24, 2014 at 6:46 PM, Melanie <[email protected]> wrote: >>> >>> I have never seen a Z < 0 build. I see lots of problems that may be >>> possible with this, but I think that quite beautiful and interesting >>> builds could make use of this and would support keeping it. The >>> change in the viewer is recent and likely trivial to undo. >>> >>> - Melanie >>> >>> On 25/04/2014 00:32, Justin Clark-Casey wrote: >>> > Hi folks. Historically, whether by accident or design, OpenSimulator >>> > has allowed negative Z values for terrain, objects >>> > and avatars (e.g. <130, 50, -45>. I have seen people use this facility >>> > to build fully underwater or partially >>> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >>> > conceptually far below the water line without having >>> > to set that water line at a level that may be way above that of >>> > surrounding regions. >>> > >>> > However, at least on Singularity 1.8.5 on Linux, fog effects do not >>> > work properly when z < 0, where all view distances >>> > have very high fog no matter what the fog settings. This may be a >>> > recent change - I remember fog working properly at >>> > negative z values in the past, though the fog issue still occurred past >>> > a certain -ve z. There may be other issues of >>> > which I'm not aware. Arguably, these are not bugs since the Linden >>> > Grid does not allow z < 0 (though one could make the >>> > same argument for var regions, etc.). >>> > >>> > With in-world testing of current development code, BulletSim appears to >>> > have a hard-coded check where I can't move my >>> > avatar below z == 2 whether terrain is z < 0 or not (this should >>> > probably at least be fixed so z = 0 is possible). ODE >>> > has allowed and still allows the avatar to descend to negative depths. >>> > >>> > One argument is that in the light of such bugs, it would be better to >>> > consistently enforce z >= 0 and require people >>> > with -z builds to either move them and the water level up using >>> > OpenSimulator commands (e.g. "translate scene") or never >>> > update their OpenSimulator installation. >>> > >>> > However, I think there is a real value in keeping the -ve z ability. >>> > It allows people to extend deep water builds >>> > without having to adjust any neighbouring sims for consistency (which >>> > they may not have control over). I'm sure it's >>> > possible to address the viewer-side issues. OpenSimulator could have >>> > an allow-negative-z flag which is false by default >>> > to make it explicit that using -ve z may have issues at this time. I >>> > accept this is a more complicated solution than >>> > enforcing z == 0, though enforcing z == 0 will also requires many >>> > changes to the current code where bounds are not checked. >>> > >>> > If my experience is unusual and -z builds are very rare then there's >>> > more of a case for enforcing z >= 0. >>> > >>> > Thoughts? >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> -- >> No essence. No permanence. No perfection. Only action. >> >> _______________________________________________ >> 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
