Triton
Visual simulation library for ocean rendering.
|
Since Triton draws its waves using a fine-grained screen-aligned grid, it's vulnerable to aliasing artifacts if your driver's quality settings are set too low. Make sure you've got anti-aliasing enabled in your application and your drivers have good texture filtering options enabled.
Ensure you have all of the latest service packs for Visual Studio installed on your system. Also, check for preprocessor defines in your application that affect STL linkage, such as _SECURE_SCL or _HAS_ITERATOR_DEBUGGING. If problems persist, contact suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com; we can provide you with obfuscated source code to allow you to build the Triton libraries with whatever development environment and compile time flags you need. If you are building your project with a statically linked runtime library (ie, "Multithreaded" vs. "Multithreaded DLL"), you'll probably need to add MSVCRT to the list of runtime libraries to ignore in your linker settings. Make sure the Triton library you are linking against matches the runtime you are using. For example, "Multithreaded Debug DLL" should use Triton-MTD-DLL.lib.
Make sure you're calling Ocean::SetAmbientLight() and Ocean::SetDirectionalLight() prior to calling Ocean::Draw().
Double check the direction being passed in to Triton::Environment::SetDirectionalLight(). If you're inadvertently passing in the direction from the light source instead of the direction to the light source, the color of the water can be undefined. Try negating what you're passing in there.
Make sure you're checking for errors returned from Triton::Environment::Initialize(). If this method fails, you'll get an informative error code back - which will most likely tell you that the path to Triton's resources directory specified in the constructor of Triton::ResourceLoader was invalid.
Also ensure you're getting back a valid Triton::Ocean object from Triton::Ocean::Create(). This method may return NULL, which likely indicates a driver compatibility issue we haven't encountered before. The first thing to try is updating your graphics drivers to the latest release, but if that fails, we provide a way to get more information about what's going on with Triton under the hood.
Open up the file resources/Triton.config in a text editor, and change the setting enable-debug-messages to "yes". Now, when you run your application in Debug mode, you'll get information in the Output window of Visual Studio prefaced with "TRITON:" that tells you more about how it selected its underlying FFT method, and error information.
If these messages implicate a specific FFT implementation as running into problems, the simplest thing is to disable the culprit. The settings disable-cuda, disable-ipp, disable-opencl, and disable-compute-shader will let you force Triton to not use a FFT method that's potentially problematic on your system. You may want to try enabling fft-force-cpu to force Triton to use its built-in CPU-based FFT transform, which has no special system dependencies or DLL dependencies at all.
If you receive the message "Failed to initialize projected grid" after calling Triton::Ocean::Create() with no other messages before it, you may be creating the Ocean from a different thread than you used to create the GL context. Make sure all of your Triton calls are done in the same thread as the one your context was created within.
Another likely culprit is the matrices passed into Triton via Triton::Environment::SetCameraMatrix() and Triton::Environment::SetProjectionMatrix(). Double check that these matrices contain what you expect, and try transposing them in case your engine's conventions differ from ours. If you just can't get the transforms right, try creating these matrices "from scratch" from your camera properties, as illustrated in the sample code provided with the SDK.
There are some known issues with Intel integrated graphics and how writes to floating point textures are handled, which can lead to missing or garbled wave heights. Try updating your drivers.
Some older ATI drivers have problems with mipmap generation in OpenGL. If you see black squares in the ocean that get worse with distance, the mipmaps on our textures are likely failing. Updating your drivers should clear this up.
If Triton crashes inside Ocean::Draw(), ensure that the Draw() call is happening from the same thread and GL context that the Ocean and Environment were created in. Common causes of this issue are initializing Triton before the graphics context is initialized, or multiple window setups where you'll need to maintain individual Environment and Ocean instances per window (unless you have enabled context list sharing between these multiple graphics contexts.)
If your application was built with the preprocessor flags _SECURE_SCL=0 or _HAS_ITERATOR_DEBUGGING=0, this can also lead to trouble since our libraries are not built with those flags. Try removing those flags, or contact suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com to get a special library build for your needs.
If you're still running into trouble, or you believe you've encountered a system compatibility issue we should know about, please send us a note at suppo.nosp@m.rt@s.nosp@m.undog.nosp@m.-sof.nosp@m.t.com. We're happy to provide limited pre-sales support to you, and we're always very interested in identifying and fixing any new bugs we haven't come across before.