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