[Opensim-dev] Negative z values

Fri Apr 25 02:59:02 UTC 2014

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.

On Thu, Apr 24, 2014 at 6:37 PM, Frank Nichols <j.frank.nichols at gmail.com>wrote:

> I don't see it as arbitrary at all.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> Frank
>
>
> On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams <sphere1952 at gmail.com>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
>>>
>>
>>
>>
>> --
>> No essence.  No permanence.  No perfection.  Only action.
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140424/7cfa0a46/attachment-0001.html>