Triton Oceans and 3D Water for Unity Pro / Windows [DEPRECATED]

Has anyone got the DepthMask shader from the wiki page to work?
Thanks

 

I have heard from one or two customers who say it has worked for them, for what it's worth.

 

Hi folks, a couple of things:

We've just released an update to Triton for Unity. New features:

• Compatibility with the new Unity 5.1.1 release
• Works with Unity’s new built-in support for VR headsets such as Oculus Rift
• Smoother ship wake effects on ships that have a RigidBody and physics-based motion
• Better compatibility with custom world unit sizes
• More realistic dissipation of ship propeller backwash over time
• Various visual and performance improvements

You can get an updated free trial version here, and we've submitted it for approval to the Unity Asset Store. The update from the asset store should be available within a few days. Note we have updated Triton to use NVidia's CUDA 6.5 release, which means it now has a minimum driver version requirement of 340.29 on NVidia systems.

I also wanted to share a project one of our customers has produced with Triton on Unity: The Golden Age VR. It looks amazing! We have a short write-up on the project on our blog.

 

yay!

 

hey atti,

I'm wondering if you can help me out real quick with this depth mask. For some reason it doesn't want to cooperate.
Here is my setup:
-Triton
-Boat Prefab
----Plane (with the depthMask applied)
----Boat Mesh

I haven't used the SetRenderQueue script as I read somewhere that it can work without it.
This setup does not work and I cant figure out why
Would you be willing to help me out (and others who are experiencing similar problems) and let us know what setup you used that worked?

Thanks in advanced for the help.

 

veddycent - you should probably PM atti if you haven't already; he may not get notifications on this thread. Offhand, it is important that the polygon over your boat hull is drawn after the boat mesh itself, but before Triton is drawn. Render queues could be important for enforcing that in some situations. Also, if you have a multi-camera setup going on, perhaps that's resulting in the wrong draw order.

In other news - I just got notification that the new update for Triton just went live in the asset store! We now have compatibility with Unity 5.1 and its new VR headset support, along with the other changes mentioned earlier.

 

Thanks for the info. I wasn't sure whether to ask here just in case others found it useful. Once I get this working ill post it here for others benefit.

Regards

 

Hey Atti,

Feel free to share any sample projects that include Triton - as long as the user name and license key fields in the Triton prefab are deleted first!

 

I'm currently on Unity 5.1.1f1 and I updated to the latest Triton but I'm getting 32 errors of the same kind:

What's the reason for Unity complaining about the same named dlls in the vc10 and vc12 directories?

(I already ran the "Update Plugin Import Settings" tool)

 

As documented and also as noted in the pop-up dialog when you first run Triton, these errors are safe to ignore. They are native DLL's used by Triton's own native DLL. Unity simply cannot make sense of them, because they aren't associated with Unity itself.

Triton maintains different builds of DLL's to accelerate FFT transforms for the waves, depending on the architecture in use. Unity doesn't like assets with the same file name, but these files are maintained by Triton, not by Unity, so it's OK.

Triton for Unity will function fine in spite of these error messages. It's unfortunate that they can clutter up your console output, but it's not something that would affect the end user.

 

I don't think we're talking about the same errors because currently I'm not even allowed to make a build. This is what I get when trying to build:

 

Sorry, you're right - there apparently was a problem with the final packaging.

Delete the vc12 directory from the Assets/Triton/TritonResources folder, and you should be able to build. We'll issue an update pronto as well.

 

The promised update to the trial version is up now, and we've also submitted the fix to the asset store. Thanks for alerting us to the problem, Andreas.

 

Any idea what could be up with this?

 

Not entirely sure what I'm looking at there. My guess is that you have coastal effects on, the terrain is above your sea level, and you're seeing the edges of the height map which prevents the water from appearing over terrain. Try turning off coastal effects, or increasing the height map size.

 

Indeedo. I had some improper culling flags on the height map camera. Thank you, sir.

 

The latest trial installer identifies itself as version 3.11. The version I've been using to date from the April 2015 time frame identifies itself as version 3.14. Was this intentional? Perhaps you don't configuration manage the versions of the trials by this identifier. In the end I just want to ensure I have the latest and I didn't access an old download etc.

Did you ever come across the bug report with Unity relative to the native DLL errors with Unity 5? Are we sure one was even entered?

 

It looks like the developer who put together the release in April forgot to check in the installer setup file, where the version number is stored. So when a new developer put together this latest release, it still had an old version number in it. Anyhow, what's important is that you do in fact have the latest trial package; it says version 3.11.

I think perhaps Unity actually did do something about those error messages in 5.1.1. I just tested importing the latest Triton trial version into a clean project, and ran it, with no errors reported in the console.

 

Hi,
I'm trying to use particle weather effects with Triton.
Namely I'm using Storm Effects asset from Unity Store.
So when I put any prefab from this asset in my scene (rain, snow, etc.) everything works fine, but when I have also Triton prefab activated everything starts to lag. I get 3 frame per second whenever particle system is on screen.
Can I somehow make it work?

 

I can't imagine how Triton could have any sort of direct interaction with this other asset. My guess would be that the combination of the two has pushed your system over some sort of threshold, probably resulting in swapping of memory.

 

This has made my day; I see the same.


I upgraded to Unity 5.1.1f1 (64-bit) and the 3.11 Triton Demo and I'm not seeing any prop wash effects in either my project or the demo project. This was working previously for me. Maybe I missed a configuration change somewhere?

I know we've discussed world scaling adjustments in the past, but it seems the minimum velocity to produce a wake has been increased in this release. As an example, an object moving at 2.63 meters/second (~5 knots) would produce a continuous small wake in the previous release. In this current release, the wake keeps forming and disappearing at this speed since it seems to be right on the verge of the minimum speed. This results in an undesirable flickering as the wake can't decide whether it should be there or not. My world units are in meters as my speeds above imply and I have a "1" as the corresponding "world units" in the Triton ocean prefab. Are there other adjustments I'm missing somewhere? I understand that I can artificially scale up the velocity being passed to "wakeGenerator.Update" but I was hoping to avoid adjustments like this. Shouldn't a ship traveling at 5 knots produce a wake? Perhaps I missed something. In my case, I really need a wake to be there for most speeds as the sudden disappearance of the entire wake is a bit of a graphical problem while my ships are adjusting speeds.

 

I'm having a bit of trouble trying a create an AssetBundle in a project that contains Triton.

When trying to export an AssetBundle (with the CreateAssetBundles script), I'm running into these exceptions:

...and it fails to build the AssetBundle.

Note that:

• I'm running this in a fresh project which only contains the Triton package and the CreateAssetBundles script
• The scene which I'm exporting in the asset bundle does not contain a reference to Triton (in fact it's an empty scene)
• I'm using the latest Triton version.

 

I'm not familiar with the "CreateAssetBundles" script. Have you tried using the build options under the Triton Editor Tools menu that Triton installs? That's the preferred way to build standalones that include Triton, and it should work fine if you have the latest Triton version that was issued on July 3.

That said, I think a workaround would be to just delete the Assets/Triton/TritonResources/vc10/win32/ if you are creating 64-bit builds, or Assets/Triton/TritonResources/vc10/x64 if you are building 32-bit builds.

 

Hrm. I most definitely see prop wash in the demo project. Did you import into a clean project? Sometimes things go awry when installing a new version of Triton over an older one.

That said - there has been changes in how prop wash works to make them dissipate more realistically over time, and in rough seas. These are described here: http://sundog-soft.com/sds/2015/05/propeller-backwash-turbulent-wake-enhancements/ ...and I think I see the issue that's affecting you. There is a new prop-wave-height-fade setting in Assets/Triton/TritonResources/Triton.config that defines the wave heights at which prop wash gets scattered - but this is not adjusted for customized world units. If you simply modify that setting to be in your own unit system, I think you'll get your prop wash back.

That value will be automatically adjusted in our next release.

 

No, I'm not trying to do a build. Doing a build works fine.

I'm trying to export a Unity AssetBundle (which has nothing to do with Triton), but Unity fails to create the AssetBundle because of conflicting dlls.

These are the files and directories that I had to delete to get it working:

• Triton/TritonResources/vc10/win32
  
• Triton/dll64
  
• Plugins/x86_64/TritonDLL.dll

When I deleted those three, the conflicts were resolved.

It is a bit problematic though since at the moment you cannot use this inbuilt Unity AssetBundle feature with an out-of-the-box Triton.

 

I see; I haven't run across asset bundles before.

I think you may have a problem however because you've deleted a mixture of 32 and 64 bit resources. If Triton can't find the native resources it needs, it will run in a reduced performance mode, which you don't want.

Instead, I'd re-install a complete Triton, and delete only the resources you won't be using based on the architecture you're building for. So, if you're building a 32-bit application, you'd remove:

• Triton/TritonResources/vc10/x64
• Triton/dll64
• Plugins/x86_64/TritonDLL.dll

Similarly, if you're building a 64-bit application, you could safely delete:

• Triton/TritonResources/vc10/win32
• Triton/dll
• Plugins/x86/TritonDLL.dll

 

I'll give this a try later today, at least for the demo to see if anything changes. I also noted as I stopped working yesterday that the demo GUI controls seemed out of place and nonfunctional, so maybe something did go wrong with the new import.

Unless the default of this parameter is too low (I'm not in front of the project to check right now), my tests were all in very calm seas (<2 meters/second wind speeds). I'm also in meters as the base unit now, which is an adjustment I made from our previous discussions to keep moving on the older Triton releases. I'm still in meters now, and may just remain there.


Any thoughts on the velocities related to wakes I mentioned in my last post? Was this intentionally changed or do I have a config problem?

 

Bah, you're right! I mistakenly deleted intermixed 32bit/64bit stuff.

Also, I now realized that by actually specifying the BuildTarget in an overload when building the Asset Bundles, no conflicts show up and the AssetBundle works just fine.

Something like this:

Code (CSharp):

1. BuildPipeline.BuildAssetBundles(
2.     @"C:\AssetBundles\",
3.     BuildAssetBundleOptions.None,
4.     BuildTarget.StandaloneWindows); // <-- Specifying the platform here
5.  

So yea, you pretty much need to specify the platform when building a Unity Asset Bundle otherwise Unity has trouble with name conflicting dlls.

 

I just modified the test object in our sample project to move at 5 m/s, and it produced a stable wake for me. I'm inclined to think you do have some sort of import problem.

One other change, other than fading the prop wash as a function of time and roughness, is that if a RigidBody is attached to your ship, it will take the velocity used to scale the wakes from it. I don't know if that might be relevant to your setup or not.

 

Well technically my example is moving at 2.63 m/s, which is 5 knots. That said, let me do a fresh import to rule that out. I imagine removing all Triton files from the project and reimporting would be sufficient correct? A whole new project brings up numerous complications of reimporting models etc.

Yes, I was already using the rigidbody velocity.

 

Yes - make sure you catch all of the plugins as well as Triton resources, and that should be sufficient.

 

Has anyone tried Triton on WIN 8.1 Store app? of course x86 not ARM target

 

I haven't tried it, but I'm 99% sure it wouldn't work. Triton includes a native "unmanaged" plugin that does all sorts of things that Microsoft doesn't allow in Windows Store apps.

 

Hey Sundog!

I was unable to find references about rendering Triton to RenderTextures. Could you please help me with that issue?

 

Can't say I've ever tried that myself. Triton just draws to whatever surface Unity has active at the end of the Camera drawing - that's how Unity handles native plugins that do their own drawing. Seems like something that either works with a render texture, or doesn't.

If you can put together a self-contained project illustrating what you're trying to do, we'll take a look at it.

 

Thanks for the quick response!
Long story short: I'm trying to render diversely positioned and rotated cameras to spaces on an UI, thus I need Triton to be rendered to a RenderTexture. The problem was that Triton's image on these RenderTextures were the same as on the last Triton-enabled camera rendered.
I'll try having an auxiliary camera rendering Triton which I'll place on the RenderTexture camera positions on pre render. It should do the trick.

I'll let you know when I have it done. Thanks for the support!

 

can't really get working WakeGenerator...

Just strange splahes

 

Are your world units in meters? If not, you need to set up Triton for your coordinate system.

Make sure the parameters reflect the dimensions of your ship. Is its beam width really only 3 meters? And the wake effects will depend greatly on the velocity of the ship - I see you have "auto update" off, so unless you are updating the WakeGenerator's velocity procedurally via a script, you'll want to turn that on so it gets the velocity from your RigidBody. There's probably no good reason to turn off "clamp to surface" either.

HTH.

 

Hello,
velocity is update by my script the ship is scaled 1/10 so yes is about 3 meters, is I set on clamp the ship goes under the water

 

I see. The spray particles look really large compared to the ship for that reason - you've scaled the ship by 1/10, but the spray particles are still in the default scale of one meter per unit. If that's how you need to run things, you'll probably need to adjust the spray scale setting to shrink the spray - and also edit the assets/triton/tritonresources/triton.config file to also make the spray cover a tighter area, perhaps. Have a look at the "ship wake settings" section of that file for settings that start with wake-spray if you want to fine tune those effects.

If your entire scene is 1/10 scale, then just compensate for that using the "World Units" parameter in the Triton prefab, and it'll make life easier - but you'll need to adjust the wake generator parameters to be in your native units.

The other wake effects like Kelvin wake waves and propeller wash will only work if the velocity of the WakeGenerator is updated continually with the ship's velocity in meters per second, and this velocity is consistent with the actual motion of the ship. In most cases "auto update" can do the job if the RigidBody's velocity is accurate, and you're using the latest version of Triton. I can assure you that ship wake effects do work, so I can't really say what's wrong without taking a closer look at your script that's updating the velocity and your project. If you can put together a self contained example of what you're doing and send that to us (support@sundog-soft.com), we can take a look for you.

 

test in demo scene ship real meter dim. same problem

 

It looks like you have made some modifications to our TritonWakeGenerator.cs script. I can't help you unless you send us a project that we can debug.

I copied your wake parameters into the sample Wake object in our demo scene, and it looked reasonable. So I think what's going on is a result of the velocity being passed into Triton for the wake being unrealistically high. That would result in huge spray velocities.

 

Ok but also no wakes/trail... in your scene

The project is big I own a licensed version from asset-store

 

The demo scene that comes with Triton has a wake that looks like this, if you turn down the wind speed:



If you're not seeing that, then something's wrong with your installation of Triton. It's not uncommon for stuff to get corrupt when importing it from the asset store. As a test, try re-importing Triton into a new, clean project and see if it behaves differently.

 

sending ship model by support e-mail

 

Triton package is the last one and works fine... the ocean and buoyancy

 

Sending me your ship model won't help me figure out what's going on. Triton has no direct interaction with your model at all.

Please follow my advice above. If you're not seeing what I'm seeing in our test scene, something is wrong with your installation and that is what needs to be dug into. It is entirely possible that something is wrong such that the waves work but wakes don't if certain files are corrupt or out of date.

It is also entirely possible that the changes you made to our TritonWakeGenerator.cs script are causing the problem, and I can't help you without seeing what you've done there.