[Opensim-dev] Negative z values

[Melanie]

They don't yet, but can be made to. I think SL eschewed that option
only because a UI to edit this in -world would be a nightmare..

- Melanie

On 25/04/2014 02:30, Mic Bowman wrote:
> do the viewers support that granularity of water height? that would be very
> useful if it could be made to work.
> 
> --mic
> 
> 
> 
> On Thu, Apr 24, 2014 at 5:23 PM, Melanie <melanie at t-data.com> wrote:
> 
>> There are potential issues with code/tools written with the notion
>> that the metaverse indeed ends at 0, but I believe they can be overcome.
>> In this vein, there is another "feature" we may want to push for:
>>
>> Raw files allow specifying a water height for each 4x4 m square, but
>> currently regions only have a notion of water level for the entire
>> region, taken from the 0,0 coordinate of the water level layer in
>> the raw file.
>>
>> I believe full support for a water height map (including Z < 0
>> depths) would be an advantage of opensim over SL, as SL currently
>> struggles with basements, subway tunnels and mountain lakes.
>>
>> - Melanie
>>
>> On 25/04/2014 02:16, Jim Williams 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
>> >>
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev