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
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
