[Opensim-dev] Negative z values

[Jim Williams]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140424/4f2c6387/attachment.html>