Water render volumes
tracked
Rinn Grumpypants
The ability to assign an object as a volume to either be a mass of water, or remove water, this could work in the same manner as reflection volumes, but would allow builds to be able to be in a body of water without rendering water inside, or using the underwater shader, an inverse would also allow expanded creation of areas with sim matching water in builds that are above the sim water level
Log In
SL Feedback
Merged in a post:
Water Exclusion Volumes Also Include Sounds and Scripts
AlettaMondragon Resident
This is related to:
And I'm happy to see that Geenz has already introduced the concept here: https://github.com/secondlife/viewer/issues/3458
One thing that I haven't seen in any of these three entries is audio, but this should be addressed at the same time.
Currently when you are underneath a prim with "hide water" enabled, since that only hides the water surface, it is not only the previously mentioned water fog/density that remains, but sounds are also muffled underwater.
If Water Exclusion Volumes will be implemented, similarly to how reflection probes do with lighting and reflections, beyond the visual effects
the water exclusion prims should also undo the underwater sound muffling inside their volume
.Another aspect, following Brigantia Mole's comment that "scripts should not detect the avatar as being underwater" when the avatar is inside the water exclusion prim, this would be just as important as undoing the sound muffling.
Currently we need to check for the water level and the object or avatar position constantly with a script and compare them to make sure it will float on water or be recognized being underwater.
This would be the right time to introduce an IS_IN_WATER boolean flag for objects and avatars, paired with an INTERACT_WITH_WATER boolean flag which could be applied to objects individually without a script (preferably on Edit > Objects, under Physical). If the INTERACT_WITH_WATER flag is TRUE on an object (and always enabled by default on avatars, like PHYSICAL), upon reaching the water level, the IS_IN_WATER flag would be triggered and remain TRUE as long as the avatar or object center is below the water level. After this, simply this IS_IN_WATER state could be checked by scripts and the script wouldn't have to compare avatar position to the water level anymore as this would be done implicitly by the simulator.
This would be extremely useful for the Water Exclusion Volumes as well, as being inside the volume of such a prim should set IS_IN_WATER back to FALSE, making the detection of these spaces and applying the appropriate conditions easier. Of course this could be implemented without these suggested flags as well, but scripts would still need a new flag to detect being inside a water exclusion volume.
I know the water interaction part with the two new flags would require much more work and extra load on the simulator, but this would be very relevant for this project and it would simplify things for all kinds of water activities greatly. In theory it could be also the first step towards built-in interactive physical water in SL.
Feel free to add this to Water Exclusion Volumes #3458 on GitHub if you like the idea.
Jack Skallagrimson
came here to post this
B
Brigantia Mole
Also, when in these under water environments, scripts should not detect the avatar as being underwater and should not initiate drowning on meters - the simulator would need to detect if you're inside the bounding box to the exclusion prim
SarahKB7 Koskinen
Boat lifts, canals and canal locks would become reality with this addition, if water physics were added to it too. A boat using these new water features could then navigate the high water lakes, mountains and dams of Sansara and other such continents with unusually high and varied heights of water.
Mirror Mondegreen
Whoops! I just made a very similar post to this because the new release has broken underwater lighting - I think this would be both a good fix for that issue and a great feature in its own right
Cube Republic
Cofferdams!
Spidey Linden
updated the status to
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Vincent Nacon
I'm all for it, but... I gotta wonder how it could work with a function like llWater(vector Pos). Since that function ask for vector... maybe it can be updated with conditional that if there's a water prim nearby or at least closer than the actual water to that vector position, should return the height position of that water prim? At least only on the topside of that prim.
Kadah Coba
Given all the legacy stuff out there, maybe some new functions with better functionality that supports water volumes.
Thornotter Resident
Kadah Coba Agreed. The definition of llWater could be changed to "Returns a float that is the sea level height below the prim's position + offset". In other words, have it return sea level rather than any water level.
Vincent Nacon
Thornotter Resident We really don't need more functions that does the same, only splitting the small difference between the old and the new. Pretty sure it won't break the old contents, only to support it. Otherwise, tell me what could break it.
Thornotter Resident
Vincent Nacon it’s often used to calculate elevation in sims, something that is fundamentally different than water volumes.
Vincent Nacon
Thornotter Resident ...And? I fail to see how it could break anything when you have a water-prim above the sim's sea level. Remember, you're still providing the vector of interest. If the vector is closer to sea level, it's not a problem. If it's closer to the water-prim... then it could only means you're nowhere near the sea level.
Jelly Doll
Volumetric prims would be awesome in general.
Place prims, define them to be water (for pools) or sky (for the inside of boats). Allow them to have their own EEP.
Suddenly we get interior lighting that can vary from the exterior lighting without need to mess with mini parcels and builds aligned to the 4m grid.
Allow volumetric prims to override other parcel properties, like the audio stream, or privacy. Music that only plays in one room. Chatter that doesn't carry though the walls.
Sky is the limit.
ST33LDI9ITAL Resident
Jelly Doll This. This is exactly how I imagine things too. We need more "probe" like volumetric options. Options for culling sound/particles/light, etc. Being able to collide with animations and stop clipping through objects.