<div dir="ltr">The water shaders in the LL viewer are quite outdated. If there was an effort to improve water, I'd personally like to see some more modern improvements such as displacement maps (for surf effects) and better reflection effects. Water could even be a heightfield. One problem with reducing the granularity of the area size affected by water height is that lighting for other objects changes when the pixels are underwater and there may be limitations in how many water heights can be passed to current shaders when rendering a frame which views underneath multiple water heights. I'm not really familiar with the rendering pipeline in the current viewers but I suspect any efforts to reducing water patch size might run into enough difficulties where designing a more modern water rendering system might actually be an easier task to accomplish. Anyway, this is probably a topic which is better discussed with those who are intimately familiar with the viewer pipeline.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 6:37 PM, Frank Nichols <span dir="ltr"><<a href="mailto:j.frank.nichols@gmail.com" target="_blank">j.frank.nichols@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">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.<span class="HOEnZb"><font color="#888888"><div><br></div><div>
Frank</div></font></span></div></div><div class="HOEnZb"><div class="h5"><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><font color="#888888"><br>
</font></span></blockquote></div><span><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" 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><br>
<br></blockquote></div><br></div>
</div></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>