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

Wow, that's a lot to go through.

Let's start with coordinate conversion. Most of Triton's coordinate conversion happens within its native code, so you shouldn't expect to see that within the C# scripts. The positions and velocities you pass into wakeGenerator.update should be in your own units, feet in your case. In general, once you've set the world unit scale in the Triton prefab, everything else should be in your own units and Triton will adjust all of its internal physics accordingly. I don't know if you did something to try and change Triton's gravity setting, but you shouldn't have to.

The position of your wake should represent the center of your ship (in your own world units). The offsets are relative to that point, in your own units (feet.) The rest of your assumptions sound correct. In inspecting the code, I did find a couple of spots where coordinates should have been converted where they weren't, and that'll be fixed in our next release - but the effect of those errors should be minor.

You should probably study the Wake Example object included with the SDK to get a feel as to what to expect. Most of our customers value performance above all else, and so we intentionally keep our vertex and particle counts low. Kelvin wakes are computed per-vertex, which is why it seems blocky when viewed from above. You can make your own trade-offs, however, if you crack open the file TritonResources/Triton.config in a text editor. Look for this section toward the end:

# The resolution of the mesh per side. This may be multiplied if the ocean
# quality setting is better than GOOD.
mesh-grid-resolution = 513
mesh-grid-resolution-mac = 257

Increasing those values will increase the resolution of the water mesh, which will result in more detailed wake waves.

You might also want to experiment with increasing the values of wake-spray-transparency and wake-spray-particles if you want denser spray effects. In the same vicinity of the config file, you'll see controls for the random variation in the size, position, and direction of those particles, which will let you tighten them up if desired. Some of the "random" spray you're seeing may also be coming from the hull spray effects, so you might want to set Hull Sprays to 0 in the inspector while you're tuning bow spray.

Prop wash will remain behind the ship after it stops, but the other wake effects should go away. In real life, it takes a long time for the foam from prop wash to dissipate. We already have time-based prop wash dissipation working here for the next release, though.

Our wave simulation only goes as far as Beaufort scale 9. That's defined as around 50 MPH winds which produce waves around 30 feet. (See http://www.spc.noaa.gov/faq/tornado/beaufort.html). You wouldn't want to be in those conditions! If you ship is having trouble staying afloat, you probably need to tune the parameters on its buoyancy model to be more springy (reduce the density or mass), or increase the voxel limit or slices per axis to give it more data to work with. I'd expect 30 foot waves to wash over the bow of even large ships, however, in real life.

I hope this helps - if not, it's probably a good idea to send us a self-contained project illustrating your setup so we can provide more specific advice.

 

Sorry, I was speaking of the overall Unity physics settings.

Is this in the Unity assets, or are you speaking about your general on-Unity-specific SDK?

I've taken your helpful post and created a brand new Unity 5 project to avoid any conflicts with my current project. I imported Triton and created a primitive capsule (which at least sort of looks like a submarine). I scaled it and assigned a rigidbody. Primitive capsule collider comes automatically with the shape (and needed for buoyancy script). I dragged in the buoyancy script and the Triton wake generator script. I set up the offsets (which make sense now, thanks), and run the scene with all defaults. I then apply from the inspector a constant force just to exercise the physics and move the object. This is what I see with

Code (CSharp):

1. mesh-grid-resolution = 1513

Is this expected? The entire 'V' of the wake statically moves with the object and grows or shrinks based on velocity. This growing and shrinking I believe is what was causing the jittering as the 'V' reshapes itself since a real ship with real physics tends to vary in its velocity in my main project. There also don't appear to be any wake waves as this 'V' looks to be flat textures (is this normal?). Perhaps this looks a bit off because there's zero wind? I imagine these textures look a bit better when under waves from the ocean. Even so, I was planning on having very flat days with no wind in my project. This entire 'V' also flickers every few frames, perhaps related or unrelated to the fact that I see the velocity calculated by your script go to zero occasionally.

I would have sworn when I fired this up weeks ago that it looked very different. I have this stripped down Unity project available if this isn't normal. It's over a GB with the TritonAssets, however. Not sure how to share it with you.

 

Well yes, it will look a lot better with a non-zero wind value.

Make sure that the velocity of your ship is changing smoothly; the size and height of the wakes depend mostly on the ship velocity. Usually discontinuities arise from discontinuities in the velocity. For example, if your framerate is not consistent, and you're computing velocity as distance travelled per frame, then you'll get inconsistent velocity values. You may need to smooth this value out somehow, or use a velocity computed some other way.

The V-shaped wake is a displacement map applied to the water surface. The angle does not change; this is how the real physics work. But its size will change with velocity. What you're seeing is what I would expect on a mirror-flat water surface with a ship travelling at a low velocity - add a little wind and it will help.

 

I've addressed the ship movement by pulling velocity and direction directly from the rigidbody and vectors. For some reason the stock scripts with Triton were having issues with velocity(dist/time) and direction which caused a terrible jitter of the whole 'V' every few frames for me. I also increased the spray factors which makes the bow spray look great (and be present in the first place) at smaller speeds. I'm still struggling with the bow wake parameters. On certain settings you can even see an entire box drawn around the ship including the 'V'. This is alleviated by setting bow wave max, but I still feel like I'm not using this correctly.

Quick reality check that just hit me, which could be a really dumb question. Your documentation mentions displacement and you're talking about size and height of waves in your last post. Are the wake waves supposed to be 3D or just a 2D shader on the surface to look like 3D waves? I certainly have 3D waves from the Triton prefab, but those wake screenshots I'm posting have no depth, and I don't see any when placing the camera at water level. They just look like a shader on the surface of the existing ocean.

If this is normal, what are the height and size adjustments you're speaking of? Do they change the shader to give the appearance of larger waves?

Thanks for hanging in there. I really want to see this work for my upcoming project.

 

The wake waves are 3D. It's possible that the feet / meters stuff is throwing off the scale of them somehow though.

You can artificially give those wake waves a boost, though. In the Triton.config file, look for the setting wake-kelvin-wave-scale. See if increasing that helps, and make sure you don't have a max wave height set up in the prefab.

 

There's definitely a problem somewhere then. I take it the white reflective part of what I've perceived to be a 2D shader is actually the crest of the bow wake waves and the darker part is inside the cresting waves. I'm sure this looks great, only all my waves are totally flat. I adjusted the wake-kelvin-wave-scale values by orders of magnitude with no visible changes.

A few posts ago I outlined what I did to create a brand new project with all defaults. The foot/meter issue shouldn't apply in that case, nor should any other customizations. I still see no 3D bow waves on either project. I'm on Unity 5.0.1f1 (64-bit) with Triton Unity Trial version 3.14. Any ideas? I'd say it's my system somehow, but the ocean prefab looks and works great.

 

Well, color me confused. Here's what I see when looking at the Wake Example object in our package - you can see it is displacing the waves in 3D:

Perhaps it is system specific. Can you let me know if you're on Mac or Windows, and if Windows, if you're on DX9 or DX11? If there's a bug, that might be relevant.

Couldn't hurt to re-download the latest Triton asset in case something got out of sync or corrupt - which I am starting to suspect.

 

For reference, I'm on Windows 7 64-bit DX11. It's not a system problem though (see the very bottom) since I believe I have this narrowed to the way the wake test sphere is moving vs. my models. The wake example is moving by manual transform manipulation whereas my models are moving entirely physics based.

While it's not exactly the same problem (I believe the world unit scaling makes things a bit worse on top of the problem at hand), you can hopefully reproduce the problems I'm seeing by doing the following in the stock Wake Example that you're distributing.

1. Open <TritonDemo.unity>.
2. On the Wake Example sphere game object, uncheck "Test Motion" in the inspector for the "Triton Wake Generator (Script)" component.
3. Play the scene.
4. (Optional) Reduce Wind Speed of the scene to 0 (just makes the issue easier to see).
   
5. Add a "constant force component" to the Wake Example sphere game object. This will automatically add a Rigidbody component as well.
6. (Optional) Increase the Rigidbody drag to 1 (helps the sphere from gaining a lot of speed quickly for the next few steps) on the Wake Example sphere game object.
   
7. Under this new "constant force" component on the Wake Example sphere game object, increase the "Relative Force" in Z to 10.
8. Observe that when the object is moved under the control of physics, there's some issues. The wake is no longer smooth or very 3D. That distinct white/green 'V' also becomes apparent, especially at the higher speeds.
   
9. (Optional) Increase the free camera movement speeds to be able to keep up with the object on the next step.
10. (Optional) Increase the "Relative Force" in Z to 50.

This is what I see at step 10, which looks a lot like my problem, though the waves at sea level do see to have some shape whereas I have none in my project. I believe this is due to the world unit scaling, however, and the velocity / size units. I realize the calculated velocity gets quiet high with this physics force relative to the default rigidbody in this example. But this graphics behavior is what I've been seeing in my project with realistic speeds in the context of feet as world units.



All the previous was on the stock example that comes with your package with unchanged scripts and scenes except as noted. Getting back to my own project, a couple additional notes:

1. I'm not using "constant force" per say, but I am using the physics system elusively for the movement of watercraft.
2. I use a slightly modified <TritonWakeGenerator.cs> file to be more compatible with physics. See an except of the relevant changes below. I don't believe this is the source of the problem since I can reproduce my issue essentially with the stock example.

Code (CSharp):

1.         if (triton == null)
2.         {
3.             triton = (TritonUnity)(GameObject.FindObjectOfType(typeof(TritonUnity)));
4.         }
5.         if (triton != null)
6.         {
7.             Ocean ocean = triton.GetOcean ();
8.             if (ocean != null)
9.             {
10.                 if (wakeGenerator == null)
11.                 {
12.                     Triton.WakeGeneratorParameters wakeParams = new Triton.WakeGeneratorParameters();
13.              
14.                     wakeParams.sprayEffects = sprayEffects;
15.                     wakeParams.bowSprayOffset = bowOffset;
16.                     wakeParams.bowWaveOffset = bowOffset;
17.                     wakeParams.length = length;
18.                     wakeParams.beamWidth = beamWidth;
19.                     wakeParams.propWash = propWash;
20.                     wakeParams.propWashOffset = propWashOffset;
21.                     wakeParams.draft = draft;
22.                     wakeParams.sprayVelocityScale = sprayVelocityScale;
23.                     wakeParams.bowWaveScale = bowWaveScale;
24.                     wakeParams.bowWaveMax = bowWaveMax;
25.                     wakeParams.bowSize = bowSize;
26.                     wakeParams.spraySizeScale = spraySizeScale;
27.                     wakeParams.numHullSprays = hullSprays;
28.              
29.                     wakeGenerator = new Triton.WakeGenerator(ocean, wakeParams);
30.                     wakeGenerator.SetLODDistance(lodDistance);
31.                 }
32.                 else
33.                 {
34.                     UnityEngine.Vector3 pos = gameObject.transform.position;
35.                     UnityEngine.Vector3 dir = -gameObject.transform.right;
36.                     velocity = UnityEngine.Vector3.Dot(rb.velocity, dir);
37.  
38.                     wakeGenerator.Update (new Triton.Vector3(pos.x, pos.y, pos.z), new Triton.Vector3(dir.x, dir.y, dir.z), velocity, Time.timeSinceLevelLoad);
39.                 }
40.             }
41.         }

These are the changes:

Code (CSharp):

1.                     UnityEngine.Vector3 dir = -gameObject.transform.right;
2.                     velocity = UnityEngine.Vector3.Dot(rb.velocity, dir);
3.  
4.                     wakeGenerator.Update (new Triton.Vector3(pos.x, pos.y, pos.z), new Triton.Vector3(dir.x, dir.y, dir.z), velocity, Time.timeSinceLevelLoad);

The way my models are set up, I can just pull "dir" directly from the orientation of the transform, though I'm noticing now you override the dir in Y to be 0, which I'm not doing. Velocity is pulled directly from rigidbody data.

As an unrelated side note, I attempted to put some of the copied code from above in the Start () to avoid these null checks at run-time. I take it that's a bad idea since you seem to have done this for a reason to avoid crashing. I'm guessing the order of the parameters being set is important? Is this a consequence of the plug-in architecture?

EDIT: Forgot to note that I am able to see the nice 3D wakes on an unchanged <TritonDemo.unity>. I missed the fact previously that this sphere object was supposed to have a wake. When I open the example in my project, the context is still feet since they shared the same Triton ocean prefab with the world units adjusted. The stock example must register the speed as too slow and doesn't show a wake. I also missed the fact that the wake script was attached to this object and the object is named "Wake Example."

 

Thanks for the repro steps. There are a couple of things going on here.

The first thing to understand is that the height of the wake waves depends entirely on the velocity value being passed into WakeGenerator::Update() each frame.

If your velocity is unrealistically high, then the wakes can start to look goofy, just like in the screenshots you've been sending. The solution is to cap the maximum wake height using the "Bow Wave Max" setting in the prefab. In the world of meters, a value of 1 or 2 works well.

With your physics setup, if you watch the velocity property of the WakeGenerator, you'll see its values are all over the place as it's running. This is because you have "auto update" on, which calculates the velocity each frame based on the distance the object has traveled since the previous frame. This seems to hit 0 frequently even though the object is in motion. I think this is probably because Unity is processing its physics updates at a slower rate than it is rendering at, so if physics haven't been updated since the previous frame, it will appear to have a velocity of zero at that instant, causing the wake to flatten out for that frame and appear to be flickering.

I get better results by querying the Rigidbody for its velocity vector directly. So, within WakeGenerator.cs, you can replace the if (autoUpdate) {...} block with the following:

Code (csharp):

1.  
2.         if (autoUpdate) {
3.  
4.             Rigidbody rb = (Rigidbody)(gameObject.GetComponent<Rigidbody>());
5.             if (rb != null) {
6.                 UnityEngine.Vector3 horizVel = rb.velocity;
7.                 horizVel.y = 0;
8.                 velocity = horizVel.magnitude;
9.                 dir = horizVel;
10.                 dir.Normalize ();
11.             } else {
12.                 if (lastTime != 0 && Time.frameCount > lastFrame) {
13.                     UnityEngine.Vector3 delta = curPos - lastPosition;
14.                     dir = delta;
15.                     dir.Normalize();
16.                     float dist = delta.magnitude;
17.                     float dt = Time.timeSinceLevelLoad - lastTime;
18.                     if (dt > 0) {
19.                         velocity = dist / dt;
20.                     }
21.                 }
22.             }
23.             lastPosition = curPos;
24.             lastFrame = Time.frameCount;
25.             lastTime = Time.timeSinceLevelLoad;
26.         }
27.  

Basically that will get the velocity and direction from the Rigidbody if one is available, instead of computing it on the motion each frame. I'll check this change in for our next release too as it seems like a generally good thing to do.

You will still see some aliasing at high velocities due to the effect being vertex-based. As mentioned earlier, increasing the vertex density of the water mesh can help, but in practice just having some waves present will cover up some of it.

As for why we need to do those null checks at runtime instead of at Start() - yes, it's a limitation of Unity's plugin architecture. There is no valid graphics device present when Start() is called, so we can't safely initialize Triton's native resources at that point.

Hope this helps.

 

Thanks for the continued replies. I've done some additional experimenting and have the following theories:

1. Changing the "world units" of the Triton prefab (for the main ocean) causes problems with the wakes. They don't form correctly at smaller speeds, and become goofy as you put it at higher speeds (but still realistic speeds within the world unit scaling).
   
2. The 'velocity' parameter to WakeGenerator::Update() appears to expect meters/second.

I finally have 3D looking wakes in my project by moving "world units" back to 1 (was 0.3048 to represent 'feet' as the "world unit") and multiplying my velocities by the same 0.3048 (to convert ft/s to m/s) before calling WakeGenerator::Update(). For now I'm just going to assume that most interactions with Triton are in meters since the conversions are easy enough. Only consequence I see is that the maximum ocean wave size won't line up too well with my models. A 200ft. model is now a 200m model in the context of the ocean, which results in smaller waves proportionally. Then again, I can't say the models were very stable at Beaufort scale 9 without using a more performance costly or complicated buoyancy model. This is something I can deal with later, unless of course you can confirm and address a world unit scaling problem on your end with WakeGenerator.

 

There are a few spots where coordinate conversion isn't handled properly in wakes; thanks for alerting me to it. I'm a little surprised they are causing issues of this magnitude for you, but they are fixed here and will go out with our next update.

What you're doing in the meantime does sound reasonable.

 

Hi, I know that computers that need to run the standalone apllication need aditional software installed to run Triton, but my developer computer, that has Unity3d and full Triton package installed also need to seperate install those packages,
or is it included in the package?

I deploy a lot of small simulators for specific use, and I want to minimize the package size, target platform is windows.
What files do I really need to run Triton, now the Triton adds well over 700mb of data when building the Application.
Maybe a parameter that let us choose target platform, and support, via the export meny would have been nice..?

br Kjell

 

The runtime dependencies are listed in the "Distributing your Application with Triton" section of the documentation (http://sundog-soft.com/sds/2014/07/triton-oceans-unity-pro-documentation/). In short, you need ensure the Visual Studio 2010 SP1 runtime libraries from Microsoft are installed (32 or 64 bit version as appropriate, depending on what architecture you built your project for,) as well as Microsoft's latest DirectX runtime libraries. Installers for both may be obtained from Microsoft's website.

If you are targeting Windows, you could safely remove the linux subdirectory in the assets/Triton/TritonResources folder of your final deployment (it actually contains MacOS resources.) If you are only building for 32-bit, then removing the dll64 subdirectory would also be an OK thing to do, as would removing the vc10/x64 directory.

I agree it would be nice if our deployment scripts automatically did this. I don't know if it's possible, but it's something we can look into for our next release.

Hope this helps.

 

Yes Thanks! Is it also safe to remove the 32bits dlls if I am building only for 64-bit? Just to verify the other way around also, ?

 

Yup, that should be the case.

 

Tried importing the Triton package downloaded from your site and each time I run into multiple compiling errors (Unity 5.0.0b4), starting with the OVR stuff, not using it but deleting it just runs into other issues that finally led me to delete the whole package since I cannot resolve the compiling errors.

 

Those errors are safe to ignore. It's been discussed in this thread, in the documentation, and there's a pop-up dialog that explains it when you run for the first time. Basically Unity cannot make sense of some of Triton's native DLL's, and there's nothing we can do to suppress these errors until Unity improves their native plugin support in Unity 5.

However, you can still run your project safely in spite of these error messages.

There are some other situations that can lead to genuine import errors - please refer to the troubleshooting section of our documentation (http://sundog-soft.com/sds/2014/07/triton-oceans-unity-pro-documentation/) for workarounds.

These are issues with Unity, not with our package.

 

Hi, got another question:
How to enable spot lights or any lights (not that default directional light in inspector) reflection on water surface? I need it for some night scene.

Thanks, Robert

 

The short answer is you can't, at least not with Unity.

Real water doesn't reflect lights the way you might think, however - most of it gets refracted into the depths.

 

Hi, I'm trying to build application using Triton Oceans.
My target platform is Windows x64.
I've read documentation and completed all the steps - put the TritonResources folder (Resource Path in the Triton prefab is "TritonResources\") and TritonDLL.dll (x64 version) in the folder where my executable is, installed DirectX and Visual C++ SP1, but I can't seem to make it work. The only thing I can see working in the executable is the underwater fog.
What am I doing wrong?

 

Did you install the x64 version of the Visual Studio 2010 SP1 runtimes?

Did you try using the build items under the Triton Editor Tools menu instead of managing the files by hand?

If so, I'll need to see the log file from your application to understand what's going on.

 

I've tried Triton Editor Tools and now it works. Thank you
Guess sometimes it's better to make something automatic rather than do it buy your hands.

 

I have a problem where the water shous up through bits of objects. THis image below shows the area in the editor:


Now the image below shows the issue in game:

For a better illustration of the problem I made a youtube video showing before applying the water and after applying the water:

Please help me find a solution to this problem.
Thanks.

 

I think what you want is "depth masking", in order to keep water out of the inside of your ship hulls.

See http://wiki.unity3d.com/index.php?title=DepthMask

The basic idea is to draw a transparent polygon, with depth writes on, over the top of your hull. Then, when Triton tries to draw in this area, the depth buffer will prevent it from doing so.

 

I've read that you can change your sea state on a scale from 1 to 9. Can you do this in Unity somehow?

 

The simplest thing is to map the desired sea state to its equivalent wind speed. See http://en.wikipedia.org/wiki/Beaufort_scale

Triton's API is exposed to the C# layer, so in principle methods like Triton.Environment.SimulateSeaState() or Triton.Environment.SetDouglasSeaScale() are available to you as well. You'd probably want to modify our scripts first to eliminate the calls to Triton.Environment.AddWindFetch() though, so the different methods of setting the sea conditions aren't fighting with each other.

 

Can you explain where I can call SimulateSeaState() or SetDouglasSeaScale() methods in the TritonUnity script? As for AddWindFetch() I presume I got to completely turn off SetWind() method. I'm not too much into programming.
Also what units is the Wind Speed in editor? Can I enter some value from Beaufort wiki (ex. 117km/h) and get Hurricane-like effect?

 

The wind speed is in meters per second. As documented, you can only go up to Beaufort scale 9 (strong gale). Beyond that point, the math breaks down.

It is probably a lot easier to just set the wind speed that matches the sea state you want than to muck about with the scripts under the hood. If you are proficient with C# scripting in Unity however, those methods can be called on the environment member variable in TritonUnity.cs as long as environment is not null. Generally that will be from a draw or update callback. If you're "not much into programming" though as you said, stick with the wind speed approach. It's possible to get things into a very bad state by messing up the underlying scripts.

 

I'm trying to use Time of Day asset with Triton. It has dynamic day/night cycle skydome.
When I place sky dome in the scene I get this rendering problem, most noticeably in the night.
Waves that's over specific line have planar reflection of default skybox, but those under this line are reflecting my skydome.
Guess it has something to do with the horizon line.
Can I get around this somehow?

 

I don't own the Time of Day asset, so I really can't say. (Use our SilverLining sky asset instead!)

If you can increase the size of the sky dome, that might help. My guess would be that you're only getting reflections underneath the physical area of the sky dome or something like that.

Hopefully others who do own Time of Day can chime in.

 

This wiki page has a render queue script which I could apply to the default unity prefab and the system works. However wherever I put the script on the triton prefabs the effect still doesnt work.

 

You want to apply depth masking to your ship, not to Triton. Due to the way Unity handles native plugins like Triton, Triton will always be the last thing drawn in your camera regardless of render queues.

 

I've tried SilverLining and I get the same result. I also tried to change the size of the sky dome. It helps with a thin line on the horizon (which is the part of the same problem I guess) but it's not changing anything with this problem.

 

Are you referring to the gap in the foreground? Try making the near clip distance on your camera a smaller value.

 

Tried that, not helping. Yes, that gap. I changed my background colour in my camera to green so it can be clearly seen.

 

Looks like z-fighting or something in the foreground with some other object; hard to say, but I do think your clip planes and/or sky dome size are part of the problem in the distance. Did you increase the scale on the SilverLiningSky, and ensure your far clip is at least 50km out?

If problems persist, I think you'll have to send us a self-contained project illustrating the issue so we can understand your setup better.

 

Yes, I've increased the scale of the _SilverLiningSky. Now it has 20000 on every scale axis. My far clip is 50000, near one is 0.01 (I tried every value between 0.01 and default 0.3, still nothing changes).
I don't really have anything in my scene and didn't change anything in render settings.
I have starting cube that's positioned over the water, I have my boat that's spawns right on top of the waves and starts floating (white thing on the screenshots), I have Triton prefab and SilverLining prefab and I have First Person Character Controller with Main Camera attached to it. My Controller uses RigidBody and has RigidBodyFPSWalker script attached. My boat also has RigidBody. I jump off the starting cube to my boat.
In render settings I turned off the fog and assigned "none" to skybox material.
And that's probably it.

 

Still not entirely sure what's going on for you. Here's what a scene with SilverLining + Triton looks like here:


I did set the skybox material to "none". I think the main difference is that my _SilverLiningSky has a scale of 50,000, not 20,000. When you have planar reflections on, you won't get any sky reflections on the water outside of the sky dome. So in your case, beyond 10km you would not have correct reflections. Try increasing that scale on _SilverLiningSky further.

My near and far clip planes are 1 and 100,000.

I think those white artifacts in the foreground of your shots are coming from your boat somehow. If you do put the camera at the same altitude as sea level, you will see a gap due to the near clip plane no matter what. It's best to just avoid putting the camera right on the water level, and keep your near clip distance small if you do need to get close to it.

 

Any idea what could be causing the ocean to render over solid objects (like the terrain in the attached screen shot)?

 

Triton relies on the depth buffer to prevent it from drawing over things it shouldn't. So if your sea level is higher than your terrain, it will draw over the terrain. Your reflections don't look right though, so I think there is something more complex going on in your scene.

Are you rendering Triton from a different camera than the rest of your scene? If so, make sure its near and far clip distances, position, and field of view are identical to that of your main scene. If they aren't, then the depth buffer values won't be comparable between the two cameras, and you could end up with weird stuff like this.

If I didn't guess correctly, feel free to send us a sample project illustrating the problem to look at (send a link to support@sundog-soft.com). It has something to do with your camera setup I think, but I can't say for sure what it is without looking at it.

 

I was actually just in the process of writing into support with more details! I didn't provide the project since it's kind of ginormous, but hopefully the additional screens/explanation make up for it.

 

For everyone else's benefit, Trent's issue above turned out to be caused by the "SESSAO" asset.

 

I'm having some issues rendering transparent objects correctly with Triton enabled.

I've gotten this to work like in the example as long as the rendering path of the transparent and opaque cameras are set to forward rendering.

When I set their cameras to deferred rendering it does not look like the final output looks correct. The ocean renders correctly as well as the transparent objects but the opaque objects are getting covered up by the transparent camera's final output's clear color.

Has anyone gotten this render technique to work with deferred rendering?

 

Your transparent camera should not be clearing anything at all - what clear flags do you have set on it?

 

Here is my setup:

Transparent camera:
clear flags: Don't Clear
Culling Mask: TransparentFX
Depth: 100
Rendering Path: Deferred

OpaqueCamera:
clear flags: Sky Box
Culling Mask: Everything but TransparentFX
Depth: 1
Rendering Path: Deferred

The ship in question is setup like this:

Ship - layer: Default
---- hull - layer: Default
---- railings - layer: TransparentFX


Again, this works fine when Rendering Path: Forward for both cameras.

 

Yes, you're right - I can reproduce the same behavior. It must have just started happening in a recent release of Unity - clearly the "Don't Clear" flag isn't being honored by Unity in this case.

Can you leave your main camera on deferred, but put your transparent camera on forward? That seems to work here. My understanding is that transparent objects get rendered in a forward pass no matter what anyhow.

 

I actually tried that combination already. When I have it set that way the transparent camera draws on top and seams to ignore depth. The transparent objects are drawn on the top of opaque objects that are closer to the camera.

I did have some luck with setting the transparent camera to "legacy deferred" but I don't think the lighting is handled as optimally in this mode as it would in simply "deferred" mode.

 

I would think "legacy deferred" would be fine on the transparent camera. Transparent things don't really get lit in the same way anyhow.

It does however seem like a bug in Unity that deferred with "don't clear" in fact clears the color buffer. If you have a chance, it's worth a bug report to them.

 

Hey,

I updated to the new version of unity last night 5.1.1f1 and also updated Triton. As a result (from a process of elimination) Triton causes my cameras (one main camera and other for transparent objects) to constantly keep falling as though it has gravity applied to it.
I've also tested in an empty scene with only Triton and a camera and it causes the camera to constantly transition to the right
Not sure if anyone else has experienced this but I thought I'd mention it.
Regards

 

Thanks for alerting me!

Believe it or not, Unity shipped version 5.1.1f1 with the DEBUG macro pre-defined (nice job, guys). This is causing some debugging code to be activated within Triton that moves the camera.

To work around it for now, edit the TritonUnity.cs script, and replace all instances of DEBUG with DEBUG_TRITON or something. There are only two of them.

We will issue an update as soon as possible with that change.