Establish HiFi "Sea Level" and Animated Water Object


Has anyone already discussed the idea of an agreed average “sea level” for HiFi Builds. It would be useful if this was the same everywhere. So builds could “join up” at some stage.

Ideally negative would be undersea and positive above the average sea level. But,
the 0m base seems hard wired in HiFi at present and is I assume a modelling base where -x metres is not allowed? Is that so?

Second Life chose to have sea level at 20m by default, though that can be amended on a region by region basis. Hence the “sea bed” is at 0m in SL. OpenSim supports negative Z (Z is up and down) with the default physics engine (Bullet) defining a “physics bottom” of -500m - just to stop avatar falling into the centre of the Earth forever. Unity lets you fall forever I think unless you implement a “catch2 net” physical lane.

Also, does anyone have a suitable and or mesh/textures script to generate an animated water layer to put into models?


I personally don’t see the advantage of having negative values for underwater. There’s no scripting need for it. Once a value is defined, then that’s the level. Any scripting can simply test Y for that value or less to determine if one is underwater or not. Valid ranges for a domain appear to be <0,0,0> - <16384,16384,16384>. Don’t see that value changing, that was probably determined day 1. You’re correct that once you step outside those bounds, you cannot rez voxels or 3D models.

I’m no expert in animated water, but I went into SL and edited the water preset and selected a builder’s grid for the water normal map.

What appears to be going on for water is that there are three flat planes, each one is blue in color, and contains a normal map to calculate the areas that are shaded vs the areas that are not.

The normal maps are just repeated and then slowly translated across the plane to give the waves motion. The planes are semi transparent, shiny, and have no texture, just a normal map.

If you google “water normal map” gobs of them will appear…

So, to make water in High Fidelity, you’ll need 3 semi transparent, blue planes with the normal map being translated across the X/Z plane on all three, slowly, at slightly different rates. That’s what appears to be going on in SL.

I really never knew any of this until I read this thread, and got curious, so I went into SL and changed the normal map to a builder’s grid, set the environment to dusk because day was way too bright, and got this:

Sample normal map…


I did do this with mesh though a few years back, and it worked pretty well, I took some planes and made them bumpy, like small rolling hills, made two of them, then rotated them in opposite directions at different rates, and had a white water texture on both.

For some reason I can’t post 2 youtube videos in one post, it keeps repeating the first video regardless of the URL I posted… So I put it in another message.

Edit… still not working, So I removed the HTTPS, if you click the above link it’ll take you to the proper video.


Thanks John. Even if we have a fixed 0m to 16383m vertical range, it would be useful for community purposes to establish a common base for the sea level for builds and regions.

Looking forward to the day that there are billions of users, and trillions of shared objects, builds and regions… it will be bad if there is no “norm” for sea level.

By the way it does seem as if you can move in the horizontal plane into negative territory… even though the diagnostics do not show the “-”. here I am at -250,+75,-250 for example… and note the /location stats show a positive number. That ought to be fixed. You cannot though create voxel there - with the in viewer build tools anyway.


You’re not moving the plane (in the case of SL water). You’re offsetting the texture across the plane. The plane(s) itself will be static. You would need a script that can change the texture offset. In SL it appears to be moving in the direction of both X and Y so the texture moves at an angle compared to facing cardinal points.


About the water level heigth, minecraft as example have bedrock at 0 meters. Water is at 62 meters. But if you say we do water at 100 meters with minimum level at 0 meters you get a problem with people that want to get deeper because some sea projects.

I think its best to have water at 0 meters. and everything below ater level is negative.
at script side that can make things maby more easy. everything negavive is below sea level so you know the object is diveing. with that 0 meter setup and negative value’s you also dont get the limitation how low people can go. offfcorse i would limit it soemwhere around 32768 meters. Its alos nice to know that sea level is at 0 meters. handy with things like planes and subs.


That is how I would design it too @Richardus

0m is mean (default) sea level (configurable on a per domain or region basis for special reasons) and I would allow positive to very high levels orbital items, and negative for undersea builds.

Sky boxes and undersea habitats and education areas frequently use -100m to +5000m in OpenSim.

See one of our undersea negative vertical builds at


Like I said, there’s no reason to use negative numbers to denote water. If sea level is fixed at a given point in Y than a script could know it’s underwater by testing for Y and if it’s below a certain value, then it’s underwater. Better yet, objects can be given a water property, therefore, water can exist anywhere at any height, and could be detected via a property such as

if (Model.water)
// we're underwater
// we're not underwater

That way, we could have water anywhere. Say I have a skybox with a pool. Second Life users have to use “fake” water for such things where. If we had a water property to models it could take on other properties such as slower movement, bubble particles, etc. Whatever Y value is assigned for sea level is unnecessary.


@John_Laury The movement of the wave patterns I think relates to a number of active weather systems in Second Life and OpenSim and the movement probably mostly is driven by the sim wind direction and speed, which varies.

I do agree with you that water at any height using water/ponds/lajes as in Unity3d could be smart… see my next gen virtual world wish list at

BUT I still think a community shared common sea level vertical height can help in sharing and using community areas.


Yeah, the thing about even the Linden water on SL, as apposed to the “prim water” in pools on land or in skyboxes, is that it is effectively a thin plane, rather than an actual “fluid” that your av or boat might be floating in, and the viewers then know to “make it murky down there” so it looks like you’re actually in the water. With “prim-water,” they simulate this same effect by making a paper-thin prim with water textures on it, usually moving ones, or in some cases stack 2 or 3 paper-then prims in some way, also having moving water textures on them.

Since we’re making a whole new virtual world system, I’d say it would make more sense of the water in world actually WAS some sort of fluid, with as @John_Laury said, a “water property” flag set to it, and/or with some means of telling the system “this object is tagged as an enclosed space, like a basement or a submarine, keep the water out of it but let it flow around the outside of it.” We could then make the HF physics cause the av to behave as if it’s in water, without needing 'swimmer hud" AOs that fake it like we do now on SL. I remember years back seeing an experimental offshoot of opensim (I think it was) that used OGRE that did something like this.


I think we need to think bigger then the box. basic water level is at 0 meters.
But i dont see why it would not be possible to have water levels at other heights to. for mountain lakes as example. depends hwo water is going to be created in hifi.


Right, there’s also voxels… if you’ve seen mincraft water, something like that, but with smaller voxels. I think that would be the bet route to go for a “true” physical, flowing water.


I think what we might end up with is a domain specific water setting.
What is suitable for one domain might not work for another, example the global water height in SL causes all kinds of limitations, we dont want that, if I want a network of deep caves on my domain then maybe I dont want any water, so ultimately I dont believe water height should be set at all, it should be modable per domain, perhaps the level set on Alpha domain might become a sort of unofficial water level that people might adapt to generally (whatever water might be).


Lets approch it different, in developer way. do we want.

16bit unsigned = 65536 blocks
16bit signed = between -32768 and 32767
32bit = 4294967296 blocks

I thinked a bit about it, i think its more easy to drop the negative part and say the sea bottom start at 0 meters. above that we have somewhere water. then we only have the remaining question about how high do we want to go ? I think 32bit, because then you dont get stuck in future idea’s as example a space mission that start on earth.

Now we only still have one problem. where do we put reference water ?
block level 1000 ? 10000 ? Keep in mind that maby someday we can seamless go from one domain into another domain, nice to not end in waterfall :slight_smile:


All I was asking for was that there is a community convention on these matters, especially a common mean sea level, so that the default is established.

I would expect a per domain (or per region of any kind) setting could then change that for special uses.

I definitely would like to see “water” available at any “level” whether that is the sea level or other levels for ponds, lakes, etc. As in Unity3D.


I think at this point Ai, nothing is really carved in stone. HF let’s us in here to bat around ideas, make suggestions, explain our reasoning, and in the end, help them make the decision that will best fit the community as a whole. So nothing is gospel at this point. I was browsing imagines in the images folder at and saw a water normal map there…