[Opensim-dev] Negative z values

[Justin Clark-Casey]

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?

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc