[Opensim-dev] Negative z values

Fri Apr 25 06:13:44 UTC 2014

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
<j.frank.nichols at gmail.com> 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 <sphere1952 at gmail.com> 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 <melanie at t-data.com> 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
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> --
>> No essence.  No permanence.  No perfection.  Only action.
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> 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
>