SUIMONO Water System - 2.0 BETA Announcement

Of course it's realistic!

 

Sorry wrong thread!

 

thank you twobob and chingwa,

Chingwa,The transparent cutout idea shows the plant fine, but it loses the ability to "move" against the wind.

twobob, I've downloaded the shader, but it still does not render correctly. I'm afraid I'm pretty new with shaders, so making it work without lightmaps is a bit foreign to me, would you be kind enough to email me and give me some pointers? I'm currently looking online to find a way to make it work, but can't seem to find anything. 0_o. If you can't, I understand. I hit up the unity question forums as well, but haven't gotten any replies. but hopefully I will figure it out.

Thank you both for the feedback though. I greatly appreciate it.

 

Is the project very large?
Just zip it up and Ill have a look. PM a dropbox link. or email me directly. I'll PM you.

EDIT EDIT: Okay so in the absence of your project I am just setting up quick "test" project that should test, Global Fog, Suimono Fog, World Fog and the Madfinger shader. See how it fairs

As for what chingwa was talking about

http://docs.unity3d.com/356/Documentation/Components/SL-SubshaderTags.html

which means - maybe - (these are probably not the right settings, they just show which bit he was discussing)

Code (csharp):

1.  
2. SubShader {
3. Tags {"Queue"="Transparent+1024" "RenderType"="TreeTransparentCutout" "LightMode"="ForwardBase"}
4. LOD 100
5.  
6. Blend SrcAlpha OneMinusSrcAlpha
7. Cull Off ZWrite Off
8. ZTest On
9.  

For the top of the madfinger shader to actually /get it to show/ over the suimono fog.

(pictured)

basically, it is being written in the wrong order for that use-case.

As you can see here though, the chingwa stuff requires a somewhat specific layer placement to get everything "drawing to just the right place" and with the madfinger shader I haven't quite found it as his aberration draws incorrectly (well, correctly, but out of sequence for our bodge job) and the z depth issue isn't quite fixed yet


EDIT: with the amended settings above it is /pretty/ close, doesn't account for refraction yet for some reason





To be fair: I, use my own flavor of fog so didn't even notice, but the madfinger thing /works/ with the above layer settings. (caveat, transparency doesn't work exactly right with those settings and the other issues I noted. play with the layers.) I also do my own depth based blurs, chromatics, sun-shafts, water surface flow effects and caustics (the latter pair via RTP shaders) so I apologise that I didn't notice before.

The relevant bit that chingwa was talking about is here is the SoftLeaf thing

Code (csharp):

1.  
2. SubShader {
3. Tags { "QUEUE"="Transparent-99" "IGNOREPROJECTOR"="true" "RenderType"="TreeTransparentCutout" }
4. Pass {
5.   Tags { "QUEUE"="Transparent-99" "IGNOREPROJECTOR"="true" "RenderType"="TreeTransparentCutout" }
6.   Lighting On
7.   Cull Off
8.   ColorMask RGB
9.  

I am not sure that is actually "editable" directly, but can possibly be programmatically influenced. I have never tried since it takes about 8 draw calls or something per leaf - which is too expensive for me.

Hope it helps.

(Hint - you can tell it is Transparent - 99 since the editor show 2901 for the layer number)
Transparency layer "magic" number = 3000 - 99 = 2901



Background is 1000, Geometry is 2000, AlphaTest is 2450, Transparent is 3000 and Overlay is 4000.

 

Moved bug report to:
http://forum.unity3d.com/threads/suimono-2-0-interactive-water-system.289311/page-2#post-1950619
and
http://tanukidigital.com/forum/index.php?topic=493.0

Spoiler

Possible bug:

The bubbles that escape the players lips are only visible whilst overlaying the players head in a direct line to the camera.

Once the bubbles are outside that bounds they are overdrawn by the fog and not rendered correctly.

it was a bit of a nightmare to get a screenie for proof but here one is.
As you can see 50% of the bubble is rendered - the other portion isn't.



So that needs looking at.

cheers


"Request for Buoyancy Manager" (or something)
As a mild aside the current buoyancy calculation times are killing me.

I would happily take less costful - more granular readings - as an option.
The demo is dragged down to 40ish FPS based on these calcs OOTB.
Setting the buoyancy on something as distant as a boat - that is WELL out of camera range seems a total waste. Perhaps an option to use a distance based disabling system would make more sense.

In the below screenshot I am a bazzilion miles from the boat (okay, quite far), underwater (so best case scenario currently for your gpu woes), just looking at 4 plants (on a very cheap shader) but the boat calculations cripple the performance anyway.



There are 50 ms over two frames of buoyancy calculations and then this bottoms out for 4 frames to a useful value and the cycle repeats.

Which makes me think that the boats buoyancy objects - and perhaps some of the others - are all doing their work on the same frame - is this the case? I thought, probably errantly, that you were going to auto-smear them based on a quick "list all the buoyancy objects and make sure they start on staggered frames" principle.

"Buoyancy Manager"
Also centralising the "Update Period" for all buoyancy objects into a "Buoyancy Manager"
would ensure no overlaps in cycles (since they would all be updated at the same rate), would simplify the "list all the buoyancy objects and make sure they start on staggered frames" issue considerably, and would provide a central place to implement the "Disable by /n/ distance from main camera" tweak that would be a real performance boon.

Additionally, currently when disabling an object the buoyancy calculations are still performed (since your engine does not know to "tell" the queued buoyancy calculation Invoke to stop calculating) this could be handled either by "just returning" if the parent object is disabled - or - more properly these buoyancy objects' statuses would be updated in the manager as "disabled" and some other, lower cost, status check could be started until the object was made live again. Seems like disabling buoyancy "on the fly" is something that should certainly be doable, and moreover, disabling buoyant items should not have a performance cost beyond checking for reactivation. Finally items removed from the scene should never leave InvokeRepeating junk floating around. That's just asking for pain.

Thanks.


Anyways, this nasty "Spikey Cycle" looks a classic for better load balancing FWIW.

 

There's a lot going on "behind the scenes" with Unity's Render Queue and RenderType shader commands. The most important thing to understand is that any shader set to a queue of Transparent" or above (3000+) is not going to write into ZDepth, regardless of the rendertype you set or even if you explicitly tell it to with "ZWrite On".

This is annoying, and can throw the uninitiated for some frustrating mind loops. In just the same way the RenderType shader functions have a bunch of hidden properties that overwrite or nullify other explictly set properties. None of this is documented anywhere (as far as I could tell) and I've only discovered this stuff through a ton of trial and error. I'm not actually familiar with how the TreeTransparentCutout RenderType is affecting other settings, but it certainly seems to be. Along the same lines the "Fallback" functions at the end of some shaders also contribute to some funky behavior... what's with all the hidden S*** Unity???

If you compare the shader headers of the softOcclusionLeaves, with the standard AlphaTest_Diffuse shader you can see the settings that make a difference. You'd need to copy the softOcclusionLeaves shader, make your own edits to the header, and then save it in a "Shaders" folder somewhere in your project, along with the "SH_Vertex" CG file it references.

Here's the default SoftOcclusionLeaves Shader header....

Code (CSharp):

1.     Tags {
2.         "Queue" = "Transparent-99"
3.          "IgnoreProjector"="True"
4.          "RenderType" = "TreeTransparentCutout"
5.     }
6.     Cull Off
7.     ColorMask RGB

And here's the default AlphaTest_Diffuse shader header...

Code (CSharp):

1.     Tags {
2.         "Queue"="AlphaTest"
3.         "IgnoreProjector"="True"
4.         "RenderType"="TransparentCutout"
5.     }
6.     LOD 200
7.    

So, you can edit the leaf shader with the same header info as the diffuse shader, and in theory it should give you the same depth benefits. Oh, and you might as well stick a "ZWrite On" function in there, and get rid of the ColorMask just in case...

Code (CSharp):

1.     Tags {
2.         "Queue" = "AlphaTest"
3.          "IgnoreProjector"="True"
4.          "RenderType" = "TransparentCutout"
5.     }
6.     Cull Off
7.     ZWrite On

 

Hello,

I apologize for the long delay.

Things have been hectic this week.
I tried the madfinger suggestion from twobob but it didn't work right.
I just finished trying chingwa's idea, and it somewhat works, but there seems to be a new error going on.
everything is rendered somewhat blue. at first I thought it was the edge detection script messing with it, but once I turned them and any other camera script off, it still did it. So I'm not quite sure what is causing it.
Thank you both for your help on this though. I really do appreciate it!

 

hello,

I got it fixed I think. I had to change a few things around.

Code (CSharp):

1. SubShader {
2. Tags { "QUEUE"="Transparent+1024" "IGNOREPROJECTOR"="true" "RenderType"="TransparentCutout" }
3. Pass {
4.   Tags { "QUEUE"="AlphaTest" "IGNOREPROJECTOR"="false" "RenderType"="TransparentCutout" }
5.   Cull Off
6.   ZWrite On

so for the first tag, it needs to be Transparent+1024 instead of AlphaTest.

But I ran it a few times, but it seems to be working pretty good now.
Any possible problems from it doing this way?

Thank you again twobob and chingwa! You two have been EXTREMELY helpful!!

 

Hi Therian13, glad it's working for you now! I don't see any issue with your code. Unless you have a second pass further down in the code, I would think the "Pass" settings should be overriding the "Tags" setting. But hey... if it works it works

 

Do you think there is a chance you will add in water displacement later? for submerging ships and such?
Just curious...

 

Water displacement... meaning... like water over-flowing over a bathub? or....?

 

I meant like a submarine submerging underwater. since it is a plane, the water currently goes through the ship. or even lower decks of ships would have water in them, since they are clipping through the plane.

 

Oh I see. The water itself can't be removed where it intersects. You'll need to use a depthmask shader in order to get the visuals you're looking for. The boat object in the included demo scene shows an example of using a depthmask shader on a plane directly over the boat in order to "mask out" the water.

Or you could perhaps write a script to access and turn off the water renderer when you're inside the submarine, but I would try the depthmask idea first.

 

Honestly I would put the interior somewhere else and use a separate camera for it if you are doing the interior view of a sub.

 

Hey guys,

Is this working with the latest release of Unity 5.0 ?

 

This is the old beta thread... Here is the new release thread.. I'm pretty sure it is 5.0 compatible based on posts there but I have yet to install it in 5 myself

 

Yes It's working in the latest 5.0.0f4 release. There are still a few issues with fog and some image fx (due to some changes in the past couple weeks with Unity 5) but these will be fixed and updated soon.

 

As @Shawn67 mentioned, this was the work-in-progress thread for the Suimono 2.0 beta version. Now that the final relase of 2.0 has been out for a while you should direct all questions to the main product thread here...

Official SUIMONO 2.0 Product Thread...
http://forum.unity3d.com/threads/suimono-2-0-interactive-water-system.289311/

I'll ask an admin to lock this thread now.