Water color affects the shade of the water.
Water transparency affects the amount of transparency you get from the water on highest quality level.
Both values also affect under-water fog - the idea is that if you’re underwater the transparency affects how far you can see, and the color is the color of fog.
Water wave size affects the size and length of the geometrical waves. Water wave speed affects the speed at which the geometrical waves “move”, as well as the speed at which the textured micro-waves move.
Currently both parameters only affect the visuals since we don’t have water flow simulation any more.
All properties above only work with smooth terrain.
In addition to the above, under-water fog is disabled when you edit terrain in Studio to make it easier to build underwater. We’ll also ship an update to editing tools next week that will make it even easier to build underwater!
If you find any issues feel free to post them here or create separate threads in Bugs forum!
These are awesome, I thought the WaterWaveSize being maxed out at 1 was going to be a serious limitation, but I actually think that’s not really a big problem now that I’m playing around with it.
“Y’argh maties, it be a rough day on the red sea.”
Personally, it is a limitation if you want a really rough appearance for some pirate game. I would personally prefer a limitation of 10 or even 5 myself, but I want it more for appearance than physics.
Is there any chance you’ll have transparency for all quality levels? This is the only remaining factor there is that keeps me from using the terrain water for my game, as I don’t want some people not having the ability to see objects through the water while others can.
I don’t even care about refraction/reflection, as long as transparency can be constant.
I noticed these properties in studio yesterday and was sad to see they didn’t seem to work.
Seeing this post filled me with joy! I can’t wait to play around with these settings when I get home.
Updated the post with a notice that replication does not work. I’m working on fixing this but it’s a bit too risky to do it and we’re close to a code freeze so I’m not sure if it gets shipped this year or not.
Someone on the regular forums suggested we be able to find the tip of the wave for boat bobbing and like, but currently the waves don’t affect the returned result of a raycast. Would it be possible to make it so raycasting would return the exact location it intersected the wave instead of just where it intersected the voxel?
I personally think raycasting results should be purely restricted to intersections with the actual collision boxes of objects, otherwise this will create inconsistencies with physics and raycasting against other types of objects. Of course if they are implementing that the physics of the water follows the rendered waves, then that wouldn’t be an issue anymore.
@zeuxcg Maybe we could get a different function that gives the current phase of the water so we can calculate the height ourselves (or as property of Terrain), if you are not implementing the physics for the rendered waves soon/ever? Then you would also be able to get rid of the cap of 1 on the wave size so we can use it at our own risk for situations where we either completely don’t care about proper water physics or where we are simulating the physics ourselves. (Custom physics for boats and swimming and whatnot)
Actually, what would be good is a option to make the rays check for the rendered triangles. Would be useful for meshes, CSG and terrain. I really want to make a bobbing ship.
