<div dir="ltr">I don't see it as arbitrary at all. <div><br></div><div>OS is a simulator and while it might be "fun" to play with negative magnitudes for dimensions I expect most people (other than mathematicians) would struggle visualizing the concept. </div>
<div><br></div><div>If a grid wants to have extremely deep oceans, it is simple enough to establish a grid wide water level at some "arbitrary" higher altitude. </div><div><br></div><div>Also, I don't expect the dev's plan on implementing infinity as an acceptable magnitude for a dimension either - so, there will in fact be some arbitrary magnitude (usually limited by the size of an integer or floating point accuracy). </div>
<div><br></div><div>I expect other than in the code the current limits are not defined, so designers using OS will need to be "careful" no matter what.<div><br></div><div>Frank</div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams <span dir="ltr"><<a href="mailto:sphere1952@gmail.com" target="_blank">sphere1952@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 6:46 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">
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 has allowed negative Z values for terrain, objects<br>
> and avatars (e.g. <130, 50, -45>. I have seen people use this facility to build fully underwater or partially<br>
> underwater structures (e.g. oil rigs, sunken ships, etc.) which are conceptually far below the water line without having<br>
> to set that water line at a level that may be way above that of surrounding regions.<br>
><br>
> However, at least on Singularity 1.8.5 on Linux, fog effects do not work properly when z < 0, where all view distances<br>
> have very high fog no matter what the fog settings. This may be a recent change - I remember fog working properly at<br>
> negative z values in the past, though the fog issue still occurred past 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 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 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 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 consistently enforce z >= 0 and require people<br>
> with -z builds to either move them and the water level up using 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 allows people to extend deep water builds<br>
> without having to adjust any neighbouring sims for consistency (which they may not have control over). I'm sure it's<br>
> possible to address the viewer-side issues. OpenSimulator could have an 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 accept this is a more complicated solution than<br>
> enforcing z == 0, though enforcing z == 0 will also requires many 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 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" target="_blank">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><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>No essence. No permanence. No perfection. Only action.
</font></span></div>
<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></blockquote></div><br></div>