<div dir="ltr">do the viewers support that granularity of water height? that would be very useful if it could be made to work. <div><br></div><div>--mic</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Apr 24, 2014 at 5:23 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are potential issues with code/tools written with the notion<br>
that the metaverse indeed ends at 0, but I believe they can be overcome.<br>
In this vein, there is another "feature" we may want to push for:<br>
<br>
Raw files allow specifying a water height for each 4x4 m square, but<br>
currently regions only have a notion of water level for the entire<br>
region, taken from the 0,0 coordinate of the water level layer in<br>
the raw file.<br>
<br>
I believe full support for a water height map (including Z < 0<br>
depths) would be an advantage of opensim over SL, as SL currently<br>
struggles with basements, subway tunnels and mountain lakes.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 25/04/2014 02:16, Jim Williams wrote:<br>
> Seems to me that 0 is a completely arbitrary number and that a cut-off for<br>
> any reason other than hardware/mathematical limitations is unwarranted. Â I<br>
> could see taking an "oh well" attitude about things that don't work with<br>
> -z, but declaring the Metaverse to simply end at 0 seems very random.<br>
><br>
><br>
> On Thu, Apr 24, 2014 at 6:46 PM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
><br>
>> I have never seen a Z < 0 build. I see lots of problems that may be<br>
>> possible with this, but I think that quite beautiful and interesting<br>
>> builds could make use of this and would support keeping it. The<br>
>> change in the viewer is recent and likely trivial to undo.<br>
>><br>
>> - Melanie<br>
>><br>
>> On 25/04/2014 00:32, Justin Clark-Casey wrote:<br>
>> > Hi folks. Â Historically, whether by accident or design, OpenSimulator<br>
>> has allowed negative Z values for terrain, objects<br>
>> > and avatars (e.g. <130, 50, -45>. Â I have seen people use this facility<br>
>> to build fully underwater or partially<br>
>> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are<br>
>> conceptually far below the water line without having<br>
>> > to set that water line at a level that may be way above that of<br>
>> surrounding regions.<br>
>> ><br>
>> > However, at least on Singularity 1.8.5 on Linux, fog effects do not work<br>
>> properly when z < 0, where all view distances<br>
>> > have very high fog no matter what the fog settings. Â This may be a<br>
>> recent change - I remember fog working properly at<br>
>> > negative z values in the past, though the fog issue still occurred past<br>
>> a certain -ve z. Â There may be other issues of<br>
>> > which I'm not aware. Â Arguably, these are not bugs since the Linden Grid<br>
>> does not allow z < 0 (though one could make the<br>
>> > same argument for var regions, etc.).<br>
>> ><br>
>> > With in-world testing of current development code, BulletSim appears to<br>
>> have a hard-coded check where I can't move my<br>
>> > avatar below z == 2 whether terrain is z < 0 or not (this should<br>
>> probably at least be fixed so z = 0 is possible). Â ODE<br>
>> > has allowed and still allows the avatar to descend to negative depths.<br>
>> ><br>
>> > One argument is that in the light of such bugs, it would be better to<br>
>> consistently enforce z >= 0 and require people<br>
>> > with -z builds to either move them and the water level up using<br>
>> OpenSimulator commands (e.g. "translate scene") or never<br>
>> > update their OpenSimulator installation.<br>
>> ><br>
>> > However, I think there is a real value in keeping the -ve z ability. Â It<br>
>> allows people to extend deep water builds<br>
>> > without having to adjust any neighbouring sims for consistency (which<br>
>> they may not have control over). Â I'm sure it's<br>
>> > possible to address the viewer-side issues. Â OpenSimulator could have an<br>
>> allow-negative-z flag which is false by default<br>
>> > to make it explicit that using -ve z may have issues at this time. Â I<br>
>> accept this is a more complicated solution than<br>
>> > enforcing z == 0, though enforcing z == 0 will also requires many<br>
>> changes to the current code where bounds are not checked.<br>
>> ><br>
>> > If my experience is unusual and -z builds are very rare then there's<br>
>> more of a case for enforcing z >= 0.<br>
>> ><br>
>> > Thoughts?<br>
>> ><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>