Sundog Software Makers of the SilverLining Sky & Weather SDK and the Triton Ocean SDK 2018-06-18T18:43:39Z http://sundog-soft.com/feed/atom/ WordPress Frank Kane http://www.sundog-soft.com/ <![CDATA[New guidance for multi-view support in Triton 4.05]]> http://sundog-soft.com/?p=4621 2018-06-06T19:08:07Z 2018-06-06T19:08:07Z We rolled out support for multi-threaded rendering in Triton 4.0; the idea was to only call Triton::UpdateSimulation() once per frame, while using the new Triton::DrawConcurrent() function to draw multiple views at once using that shared ocean state. However, we’ve since found some edge cases where ship wake effects don’t work properly with this strategy. This...

The post New guidance for multi-view support in Triton 4.05 appeared first on Sundog Software.

]]>
We rolled out support for multi-threaded rendering in Triton 4.0; the idea was to only call Triton::UpdateSimulation() once per frame, while using the new Triton::DrawConcurrent() function to draw multiple views at once using that shared ocean state.

However, we’ve since found some edge cases where ship wake effects don’t work properly with this strategy. This is because wakes need to be culled based on the current view, and so the set of visible wakes may differ between views.

So, we’ve modified our guidance on how to draw multiple views in Triton accordingly. The main change is that in addition to calling UpdateSimulation() for your “main” camera, you should also call it for your individual cameras prior to calling DrawConcurrent. In Triton 4.05, it’s smart enough to not recompute the expensive FFT calculations for the waves when you call UpdateSimulation() more than once for the same timestamp, but it will recalculate the set of visible wake effects, which is what we want.

We’ve also modified Triton’s documentation accordingly, to avoid any future confusion. Longer term, we hope to make those additional calls to UpdateSimulation() unnecessary – but for now, this should get things working properly for everyone again.

The post New guidance for multi-view support in Triton 4.05 appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[Behold the official TerraMaxx promo video!]]> http://sundog-soft.com/?p=4604 2018-03-25T10:59:30Z 2018-03-25T10:59:30Z Video producer “Redpiper1” has done it again, creating a great promo video for our latest product: TerraMaxx for the X-Plane flight simulator. TerraMaxx is an add-on for X-Plane that brings seasonal representations for fall, winter, “deep winter,” and summer to X-Plane’s simulated world, and also provides tree textures with 4X the original resolution. This video...

The post Behold the official TerraMaxx promo video! appeared first on Sundog Software.

]]>
Video producer “Redpiper1” has done it again, creating a great promo video for our latest product: TerraMaxx for the X-Plane flight simulator. TerraMaxx is an add-on for X-Plane that brings seasonal representations for fall, winter, “deep winter,” and summer to X-Plane’s simulated world, and also provides tree textures with 4X the original resolution.

This video also showcases our SkyMaxx Pro add-on, which replaces X-Plane’s default skies and 3D clouds with our own, powered by SilverLining.

TerraMaxx and SilverLining are both produced in partnership with Maxx-XP.

Check it out below!

The post Behold the official TerraMaxx promo video! appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[TerraMaxx 1.0 Released: Seasons for X-Plane]]> http://sundog-soft.com/?p=4599 2018-03-18T11:58:36Z 2018-03-18T11:58:36Z We’re happy to announce the release of TerraMaxx 1.0, an add-on for the X-Plane flight simulator that brings winter and autumn scenery to X-Plane’s world! Sundog Software developed TerraMaxx together with Maxx-XP. TerraMaxx’s features include: Automatic swapping of X-Plane’s default scenery with seasonal representations of summer, autumn, mild winter, and deep winter based on your...

The post TerraMaxx 1.0 Released: Seasons for X-Plane appeared first on Sundog Software.

]]>
We’re happy to announce the release of TerraMaxx 1.0, an add-on for the X-Plane flight simulator that brings winter and autumn scenery to X-Plane’s world! Sundog Software developed TerraMaxx together with Maxx-XP.

TerraMaxx’s features include:

  • Automatic swapping of X-Plane’s default scenery with seasonal representations of summer, autumn, mild winter, and deep winter based on your simulated location, date, and temperature
  • Replacement tree textures with 4X the resolution of default and seasonal variations
  • Optional post-processing effects to give autumn and winter scenes season-appropriate hues
  • If you indicated that your GPU has more than 5GB of VRAM when installing, high-resolution normal maps for default scenery will be installed, to give the appearance of more depth to the terrain

The initial reaction from the X-Plane community seems really positive! Seasons is something that’s been missing from the X-Plane platform for a long time, and we’re thankful for Laminar Research’s support in making TerraMaxx possible.

TerraMaxx is available for $39.95 from X-Aviation.

The post TerraMaxx 1.0 Released: Seasons for X-Plane appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[Triton Ocean SDK 4.0 is Here!]]> http://sundog-soft.com/?p=4581 2018-02-27T00:36:54Z 2018-02-26T23:49:24Z It’s finally available! Version 4.0 of our Triton Ocean SDK is now available for download. Licensed users with an up-to-date support plan can get the latest release from our licensed user download portal, and everyone else can grab a free evaluation SDK to check it out. The big push for 4.0 was making Triton VR-friendly,...

The post Triton Ocean SDK 4.0 is Here! appeared first on Sundog Software.

]]>
It’s finally available! Version 4.0 of our Triton Ocean SDK is now available for download. Licensed users with an up-to-date support plan can get the latest release from our licensed user download portal, and everyone else can grab a free evaluation SDK to check it out.

The big push for 4.0 was making Triton VR-friendly, by offering real support for multi-threaded rendering. There are many different techniques for multi-threaded rendering out there, and we’ve tried to support as many as we could. Read this article to learn more about using Triton in multi-threaded environments. You’ll find new sample apps in the SDK illustrating how to do this in OpenGL and in DirectX 11.

We’ve also finalized support for bindless graphics in OpenGL 4.5, including bindless textures, bindless UBO’s, and bindless VBO’s. This is sort of bleeding-edge stuff that requires OpenGL 4.5 or newer in addition to some NVidia-specific drivers, so it’s not enabled by default. Read up on the details of how to use it.

In short, we’ve done a ton of work to modernize Triton’s approach to rendering in order to take full advantage of today’s hardware. All of this re-architecture gives Triton much of the same performance benefits offered by Vulkan, but without requiring you to rewrite your entire application! We’ve carefully followed NVidia’s advice in “OpenGL Like Vulkan” to ensure Triton is aligned with where OpenGL, Vulkan, and DirectX 12 are headed in the future.

At Sundog Software, we typically do lots of incremental releases, and version 4.0 is no exception – the architectural changes behind it have actually been getting rolled out slowly throughout Triton’s 3.x run. Triton 4 remains backward compatible with Triton 3 API’s, so you can update now without changing your integration code, and consider taking advantage of its new capabilities later on if you wish.

There are a few other big recent changes worth noting:

  • Our sample applications are now 64-bit only. While Triton itself still offers 32-bit libraries and DLL’s, our sample apps now only support 64-bit targets on Windows.
  • We deprecated Visual Studio 2003, 2005, and 2008 in a previous release.
  • Triton now uses NVidia’s CUDA Toolkit 9.1 for 64-bit targets; if you are building Triton from source, you’ll need to read this article to understand the changes needed to your build environment.

As always, full release notes are available too.

If you run into any trouble, please let us know. And thanks for using Triton!

The post Triton Ocean SDK 4.0 is Here! appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[Using Triton 4.0’s Multi-Threaded Rendering]]> http://sundog-soft.com/?p=4568 2018-06-06T19:03:23Z 2018-02-26T23:44:26Z The big new feature in the Triton Ocean SDK 4.0 release is support for multi-threaded rendering in OpenGL and DirectX11. With virtual reality becoming more prevalent in training and simulation, we can no longer ignore the need to render two (or more) views at once as quickly as possible! While you may continue to use...

The post Using Triton 4.0’s Multi-Threaded Rendering appeared first on Sundog Software.

]]>
The big new feature in the Triton Ocean SDK 4.0 release is support for multi-threaded rendering in OpenGL and DirectX11. With virtual reality becoming more prevalent in training and simulation, we can no longer ignore the need to render two (or more) views at once as quickly as possible!

While you may continue to use Triton 4 in exactly the same way as you did in Triton 3, taking advantage of its ability to build up display command lists in separate concurrent threads for each view will require some changes to your code. You’ll find some new sample applications in the SDK illustrating multi-threaded rendering in DirectX and OpenGL using several different techniques. And, here’s the new section in our documentation that talks about the details:

Multi-threaded rendering with Triton

Prior to Triton 4.0, to support multi-threaded environments, the user had to specify the following flag in the config file, and do the drawing as usual:

thread-safe = yes

This is a very naive approach however, as it effectively has a top level mutex, forcing Triton to do its work for multiple views as well as the rendering in a serialized fashion.

Starting with Triton 4.0, Triton supports fully featured multi-threaded rendering for both DirectX 11 and OpenGL. But to leverage this the application must be carefully designed and the new APIs used correctly and in the correct order.

This is best explained using an example. Let’s say that you have a VR application with left and right views, where each camera is a slightly different frustum corresponding to the left and right eye.

The first order of business is for Triton to generate the wave geometry and wake effects for the ocean. This necessitates a call to Ocean::UpdateSimulation. This call needs to happen in the main thread, where the DirectX 11 device/immediate context or the OpenGL context are current.

The appearance of local waves may change if the wind conditions differ between views. But for VR, the views are close enough to be considered to be at the same location for our purposes – so you can get away with calling Ocean::UpdateSimulation to update the waves only once per frame. UpdateSimulation() requires a Camera parameter; you can just pass in either the left or right view’s Camera object here, or create a dummy Camera positioned between the two eyepoints.

Following this, you need to do a Ocean::UpdateSimulation() followed by Ocean::DrawConcurrent() for the left and the right cameras respectively. These subsequent calls to UpdateSimulation() won’t recompute the waves, but will recompute the wake effects specific to each view. These calls can happen in completely separate threads. And there is no limit on how many views you can render simultaneously (this example only has two.)

Following this, you need to call Ocean::PostDrawConcurrent(), in the main thread.

The sequence of calls therefore is:

Ocean::UpdateSimulation(time, main camera/viewing frustum) // in main thread

Ocean::UpdateSimulation(time, left camera)
Ocean::DrawConcurrent(left camera) // can happen in a completely different thread

Ocean::UpdateSimulation(time, right camera)
Ocean::DrawConcurrent(right camera) // can happen in a completely different thread

Ocean::PostDrawConcurrent() // in main thread, after both view threads are done calling DrawConcurrent()

If you have completely disparate views (e.g. separate windows with viewpoints that are many kilometers apart), and these viewpoints may have different wind conditions or different sets of nearby wakes, then the strategy of sharing a single Ocean geometry between your views no longer works well. You can still just call Ocean::DrawConcurrent()from separate threads using unique Camera objects to simulate and render the Ocean for each view concurrently, but you’ll want to use separate Ocean instances for each view in this case.

Besides the Camera, one needs to pass in an additional ‘context’ parameter. Depending on whether we are using an OpenGL or DirectX 11 renderer, this means different things, and we will describe this next.

DirectX 11 multi-threaded rendering:

A key observation of any rendering is that the actual work of generating commands for the GPU to execute and then actually executing them on the GPU can effectively be decoupled.

Therefore, the command list generation for each different view can proceed in completely different threads. After all command lists for each view are generated, they can be rapidly executed on the GPU on the main thread.

To this end, DirectX 11 leverages ‘deferred contexts’ and ‘command lists’:

https://msdn.microsoft.com/en-us/library/windows/desktop/ff476892(v=vs.85).aspx

In DirectX 11 , you would want to create a ‘deferred context/command list’ pair for each view/thread in question and pass them in to the call to Ocean::DrawConcurrent, along with the camera for the view/thread in question. When a Ocean::DrawConcurrent is specified using a valid DirectX 11 deferred context and camera, Triton will generate the correct set of commands and append it to the context/command list passed in, but not actually do the rendering. Following this you actually ‘execute’ the command list using the appropriate DirectX 11 API.

We have a fully featured sample DirectX11MultiThreadedSample that demonstrates this multi-threaded rendering for DirectX 11.

OpenGL multi-threaded rendering:

OpenGL rendering follows the same paradigm as DirectX 11. Unfortunately, at this time, the OpenGL specification does not include command lists. Vendor specific APIs/extension are available however, the most complete being Nvidia’s:

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_command_list.txt

We however did not want to tie ourselves to a specific vendor/extension, therefore we created our own abstract API along the lines of DirectX 11 context/command list API. In OpenGL a ‘context’ means a completely different thing however (meaning the actual context for the window/offscreen buffer), so we call our command list/contexts for each view/thread an ‘OpenGL Stream’.

Similar to DirectX 11, we create an OpenGL Stream for each view/thread in question using: Environment::CreateOpenGLStream. Once the stream is created (and prior to any drawing), you must call Ocean::Initialize with the stream and the camera in question as parameters, indicating your intent to render with this stream and camera. This call must happen where an OpenGL context is current. Following this, stream pointer and camera is what is going to be passed in as parameters to Ocean::DrawConcurrent. These calls can then proceed in completely different threads (an actual OpenGL context is not even required in each thread, since the Ocean::DrawConcurrent call is effectively just appending the commands to the OpenGL stream). Following this we execute each of the steams using Environment::ExecuteOpenGLStream. Again, execution must happen where there is a current OpenGL context.

We have a fully featured sample OpenGLMultiThreadedSample that demonstrates this multi-threaded rendering for OpenGL. There are various draw strategies that you can use. Please refer to SampleDeclares.h for additional information. Project files for Visual Studio 2013 and 2015/2017 are included; for Linux, refer to the README_LINUX file for build guidance.

One important thing to note is that you don’t want to actually render/execute the streams in multiple threads, each thread having their own OpenGL contexts, because internally the GPU is going to serialize the calls anyway, and there is no performance improvement. If at all, there is degradation because of OpenGL context switches, etc. Nonetheless, some rendering engines out there (e.g. OpenSceneGraph) do support multi-context, threaded rendering, and for completeness we have provided a code path/draw strategy that demonstrates how to do multi-threaded rendering when there are actual multiple OpenGL contexts. Please also note that we currently only support shared OpenGL contexts, that is to say the contexts are sharing resources (textures, vertex buffers, etc), which is what you want to ideally do any way.

Lastly, and quite importantly, this flag:

thread-safe = yes

is effectively ignored when Ocean::DrawConcurrent is used. Triton internally is completely thread safe as long as you create/pass in the correct DirectX 11 deferred contexts/OpenGL streams, and cameras for the thread(s) in question as demonstrated in the DirectX 11 and OpenGL samples. You would also want to remove any additional mutexes in your application code and adjust the calls to Triton accordingly.

The post Using Triton 4.0’s Multi-Threaded Rendering appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[Enabling Bindless Graphics in Triton 4]]> http://sundog-soft.com/?p=4574 2018-02-26T23:44:06Z 2018-02-26T23:44:06Z No, it’s not that kind of bondage we’re talking about. When using OpenGL 4.5 or newer, Triton has the ability to take advantage of “bindless graphics” that use native GPU addresses, instead of handles for resources that must be looked up and validated by the driver. This offers some performance benefit, and also gets us...

The post Enabling Bindless Graphics in Triton 4 appeared first on Sundog Software.

]]>
No, it’s not that kind of bondage we’re talking about. When using OpenGL 4.5 or newer, Triton has the ability to take advantage of “bindless graphics” that use native GPU addresses, instead of handles for resources that must be looked up and validated by the driver. This offers some performance benefit, and also gets us a closer to an architecture that’s ready for Vulkan.

This feature is disabled by default; the relevant settings in the Resources/Triton.config file are:

use-gl-bindless-textures
use-gl-bindless-uniform-buffer-objects
use-gl-bindless-vertex-buffers

If set to “yes”, these settings enable bindless textures, UBO’s, and VBO’s respectively. Their usage requires use of the OPENGL_4_5 or newer renderer type with Triton (specified in Environment::Initialize()), and bindless UBO’s and VBO’s rely on NVidia-specific extensions that may not be present on the systems you are targeting. That’s why they are disabled by default. If however you control the configuration of the systems you are deploying your software to and they are compatible with NVidia’s bindless extensions, you can test enabling these options in your deployments. Bindless textures rely on the availability of the GL_ARB_bindless_texture extension; bindless UBO’s rely on GL_ARB_uniform_buffer_object, GL_NV_vertex_buffer_unified_memory and GL_NV_shader_buffer_load; and bindless VBO’s rely on GL_NV_vertex_buffer_unified_memory and GL_NV_shader_buffer_load.

If you’re targeting systems that can be expected to have reasonably current video drivers, enabling bindless textures is probably a safe thing to do. Bindless uniform buffer objects and vertex buffers do involve NVidia-specific extensions, and should be tested carefully on the systems you intend to support. We’ve heard reports of some drivers incorrectly reporting that they support these extensions when they really don’t. This is still bleeding-edge stuff, but it’s the direction 3D graphics are headed – and Triton is ready for it.

The post Enabling Bindless Graphics in Triton 4 appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[We’re Deprecating DirectX 9 – Speak Now or Forever Hold Your Peace]]> http://sundog-soft.com/?p=4565 2018-02-20T00:16:12Z 2018-02-20T00:16:12Z The title says it all – DirectX 9’s day has come. Originally we supported DirectX 9 primarily for legacy Unity projects, but even Unity has deprecated DirectX 9 at this point. To our knowledge, no customer is actively using DirectX 9 with Triton or SilverLining. If you are, please drop a note to support@sundog-soft.com and...

The post We’re Deprecating DirectX 9 – Speak Now or Forever Hold Your Peace appeared first on Sundog Software.

]]>
The title says it all – DirectX 9’s day has come. Originally we supported DirectX 9 primarily for legacy Unity projects, but even Unity has deprecated DirectX 9 at this point.

To our knowledge, no customer is actively using DirectX 9 with Triton or SilverLining. If you are, please drop a note to support@sundog-soft.com and let us know.

We are busy modernizing Triton and SilverLining, and certain things just aren’t compatible with DirectX 9’s fixed-function design these days. Sometimes moving forward means leaving the past behind.

The post We’re Deprecating DirectX 9 – Speak Now or Forever Hold Your Peace appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[SilverLining’s HDR Mode- It’s Probably Not the Droid You’re Looking For]]> http://sundog-soft.com/?p=4561 2018-02-12T14:55:33Z 2018-02-12T14:55:33Z A frequent question we get is how to use SilverLining’s alluring Atmosphere::EnableHDR() function. Customers are often confused when they enable this, only to be met with a totally white sky. Although high dynamic range is a great thing, you need to understand what EnableHDR() does before trying to use it. It’s almost never what you...

The post SilverLining’s HDR Mode- It’s Probably Not the Droid You’re Looking For appeared first on Sundog Software.

]]>
A frequent question we get is how to use SilverLining’s alluring Atmosphere::EnableHDR() function. Customers are often confused when they enable this, only to be met with a totally white sky. Although high dynamic range is a great thing, you need to understand what EnableHDR() does before trying to use it. It’s almost never what you actually want to do!

SilverLining IS HDR by default!

First, it’s important to understand that even without calling EnableHDR(true), SilverLining is performing all of its simulation of the sky, sunlight, moonlight, and reflections of that light in the clouds in HDR space no matter what internally. Under the hood, we run a rigorous physical simulation of how sunlight and moonlight is affected by the atmosphere and scattered throughout the sky, and these computations are done in physical units of candelas per square meter. Once it’s time to display the sky to the screen and return sunlight and moonlight information to your application, we apply our own tone-mapping algorithm and gamma correction to get these physical results into a displayable range. That’s exactly how HDR works, and SilverLining does that by default, out of the box. Calling EnableHDR(true) does not switch on some more physically realistic model within SilverLining – you get that no matter what, with no extra work.

So what does EnableHDR() do?

All EnableHDR(true) does is remove all tone mapping and gamma correction from what SilverLining displays, and from the lighting values we return to you via methods such as Atmosphere::GetSunOrMoonColor(). This means it is now up to your application to handle tone mapping and gamma correcting what SilverLining renders, and what it returns for lighting values.

With HDR enabled, you must be rendering to an offscreen floating-point buffer or else the colors we write for the sky will be clamped to white. And you must have your own HDR system for remapping what’s in that buffer to displayable results before you transfer the scene to your final display buffer.

This is all much more complicated than it even sounds (which is already pretty complicated.) Chances are the rest of your scene is not rendered in the same lighting units as SilverLining, which means that obtaining consistent results will mean lots of fiddling with SilverLining’s configuration settings to adjust the overall brightness of the sky, clouds, moon, etc. For example, you’ll probably need to tweak sun-luminance-scale, moon-brightness-hdr, sun-transmission-scale-hdr, sun-scattered-scale-hdr, hosek-wilkie-radiance-scale, and probably more before the sky and clouds match the brightness of the rest of your tone-mapped scene. You might also need to scale the lighting values we return to light the rest of your scene the way you want. Getting all of this right can take weeks of tweaking – and in the end, you’ll just end up with a sky that looks exactly like it would have without EnableHDR(true) if you’ve done things properly.

Simpler alternatives to EnableHDR()

We really don’t recommend calling EnableHDR(true) unless you have a special situation that really warrants it, which is almost never. I bet you think the screenshot attached to this article is with HDR mode enabled – it isn’t, even though it’s being displayed within a graphics engine that does work in HDR space.

Remember SilverLining operates within HDR space itself, and is already tuned to do its own tone mapping and gamma correction in just the right way that’s appropriate for the sky. You probably want to composite SilverLining’s sky into your scene at the final stage of your rendering pipeline when you are working in displayable, non-HDR space, if you’re working within some HDR-based deferred rendering engine.

Sometimes, you just want to get our raw lighting values from Atmosphere::GetSunOrMoonColor (and its variants) without tone mapping and gamma correction applied to it. You can do this by surrounding your call to GetSunOrMoonColor() with EnableHDR(true) and EnableHDR(false) to just switch on HDR mode while you’re retrieving the lighting values, while leaving the actual rendering of the sky unaffected.

If your real goal is just to have finer control over how rich the colors are in SilverLining’s sky, Atmosphere::SetGamma() is probably what you really want to be working with.

In summary: don’t use Atmosphere::EnableHDR() unless you really need to (which usually isn’t the case, even in HDR scenes,) and you have several weeks to tweak it to fit into your engine. After those weeks, you’ll probably just be left with a sky that looks like it did without calling EnableHDR(true), since SilverLining is already HDR under the hood no matter what.

The post SilverLining’s HDR Mode- It’s Probably Not the Droid You’re Looking For appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[We’re deprecating support for Visual C++ 6 through Visual Studio 2008.]]> http://sundog-soft.com/?p=4556 2018-02-10T11:44:47Z 2018-02-10T11:44:47Z Consider this your fair warning – the current versions of the Triton Ocean SDK (3.91) and the SilverLining Sky, 3D Cloud, and Weather SDK (5.008) will be the last to offer project files, libraries, and support for Visual C++ 6.0, Visual Studio .NET 2003, Visual Studio 2005, and Visual Studio 2008. We will continue to...

The post We’re deprecating support for Visual C++ 6 through Visual Studio 2008. appeared first on Sundog Software.

]]>
Consider this your fair warning – the current versions of the Triton Ocean SDK (3.91) and the SilverLining Sky, 3D Cloud, and Weather SDK (5.008) will be the last to offer project files, libraries, and support for Visual C++ 6.0, Visual Studio .NET 2003, Visual Studio 2005, and Visual Studio 2008. We will continue to offer support for Visual Studio 2010, 2012, 2013, 2015, and 2017 however!

While I could preach about the dangers of using un-maintained compilers that are over ten years old, that’s not really why we’re doing this. It’s also not about the extra work involved in keeping our code compatible with these old compilers and keeping their project files up to date, although that’s definitely a thing. The real reason is that our old build machine that compiles our SDK releases is starting to show signs of hardware failure, so we’ve been busy building a new build machine. In the process of setting it up, we’ve discovered that Microsoft no longer even offers anything older than Visual Studio 2010 for download. Since our original installation media for these ancient compilers is long gone, that left us with no way to even install them if we wanted to. Well, at least not legally – but at Sundog Software we play by the rules.

I doubt anyone actively using our software is still using any of the affected compilers. But if this change does impact you, be sure to keep your current SDK installer someplace safe. And remember, Visual Studio 2017 Community Edition is totally free! Maybe now is the time to update.

The post We’re deprecating support for Visual C++ 6 through Visual Studio 2008. appeared first on Sundog Software.

]]>
Frank Kane http://www.sundog-soft.com/ <![CDATA[Triton is moving to CUDA 9.1 – What this means for you]]> http://sundog-soft.com/?p=4551 2018-02-08T14:31:21Z 2018-02-08T13:32:19Z With Triton’s 3.91 release expected in a few days, we’re finally taking the plunge and updating the version of CUDA used to accelerate Triton’s wave calculations on NVidia systems – on platforms that support it, at least. What does this mean for you as a customer of the Triton Ocean SDK? If you’re not building...

The post Triton is moving to CUDA 9.1 – What this means for you appeared first on Sundog Software.

]]>
With Triton’s 3.91 release expected in a few days, we’re finally taking the plunge and updating the version of CUDA used to accelerate Triton’s wave calculations on NVidia systems – on platforms that support it, at least. What does this mean for you as a customer of the Triton Ocean SDK?

If you’re not building Triton from source code on Windows – which is most of you – not much action is needed on your end. Simply note that:

  1. There are a couple of new DLL’s for CUDA in our Resources/dll64 directory. Be sure these are included in the distributions of your application after updating to Triton 3.91 or newer.
  2. If you are building for Windows / 64-bit architectures, note that Triton 3.91 will now depend on NVidia driver version 388.19 or newer for CUDA acceleration to work.

If you are building Triton from source code on Windows, things get a little more complicated. This is because CUDA no longer supports 32-bit Windows architectures, but that’s still a platform we want to support. So, our Visual Studio project files for the TritonCUDA project depend on both CUDA Toolkit 6.5 for 32-bit targets, and CUDA Toolkit 9.1 for 64-bit targets.

This means that on Windows, you’ll want to install CUDA Toolkit 6.5 if you haven’t already, and then install CUDA Toolkit 9.1 as well. The order is important, since you want CUDA 9.1 to install its Visual Studio integration features, not 6.5. Only then will you be able to build our TritonCUDA project for any target.

Of course, there is an exception. If you are still on Visual Studio 2008, you should instead only install CUDA Toolkit 6.0, as that was the last version that supported Visual Studio 2008 at all.

On Linux, you can still just install the latest CUDA Toolkit that your OS and architecture supports prior to building – nothing changes with your process.

Why are we updating CUDA? Well, there are a couple of reasons. Most importantly, we received a report that CUDA 6.5 actually crashes in VR setups on NVidia systems. Since many of our customers are starting to support VR, that’s not OK. Also, CUDA 9 promises performance improvements in its FFT library, which is the main thing we use CUDA for. So, you may see a boost in performance in Triton 3.91 as a result.

This move is also part of our incremental march toward a Triton 4.0 release. Our methodology is to release changes as they come, and so we don’t unleash a huge batch of changes and features all at once. We’ll move Triton to “4.0” once all of the features we’ve been slowly rolling out under 3.x are complete; the big thing remaining is finishing off our support of multi-threaded rendering with multiple contexts.

Also, remember newer is not always better – it’s possible that CUDA 9.1 will introduce issues into Triton that we haven’t discovered yet. To be safe, keep the Triton SDK version you’re currently using around just in case you need to roll back.

The post Triton is moving to CUDA 9.1 – What this means for you appeared first on Sundog Software.

]]>