December 14th 2016
Granite SDK 4.0 is released
We have a major announcement: Granite SDK 4.0 is ready for release! It’s a major release in every way. We focused on two things:
- Ensure that Granite can be used by teams of any size, from small indies to AAA studios.
- Ensure that Granite can stream and optimize any texture content.
Unreal users can also immediately benefit from our changes by downloading the latest SDK 4.0 tools here. The generated Tile Sets are backwards compatible with older runtime versions. Let’s jump right in and take a look at the new features.
Version control is essential for any kind of project but it’s even more critical once a project grows larger in size. It also serves as a way to distribute the files internally. We’ve made improvements to our tools in order for them to work well with Git and Perforce version tools. We’ve also created a new intermediate file type. This allows you to switch from checking in large files that are modified frequently to checking in smaller files that are modified much less frequently.
In Granite, we bundle all the texture channels of an asset into what we call a “Stacked Texture”. The source images are tiled and compressed by the tools and then stored per Stacked Texture in a .GTEX file. These files can be checked into version control and distributed internally. The Granite tools now use these .GTEX files to quickly generate the final streaming files (our Tile Sets) that are needed by the Granite runtime. Generating Tile Sets from .GTEX files takes roughly 90 seconds for 2GB of compressed texture content. The process is mainly disk IO so fast drives will help to speed up the process.
You now have two options to distribute the Granite assets internally in your studio:
- A team member gets the .GTEX files and generates the Tile Sets locally on his machine.
- A team gets the Tile Set that is generated on a build system or by another team member.
The main advantage of the second approach is that you can immediately start using the Tile Sets. You don’t need to wait until they are generated. The main downside is that you’ll need to get an entire Tile Set each time you need the latest content.
Accelerate Tile Set Generation
The new import pipeline has another advantage next to more flexibility for file versioning: you can now use multiple machines to accelerate the generation of Tile Sets. Typically, team members will generate .GTEX files on their machine when modifying Stacked Textures and commit these to a file sharing system to distribute to other members. Similarly, you can now use multiple build machines to generate.GTEX files from the source assets. You can then aggregate these files on one machine and run our command line tool to assemble the final Tile Set. This can save a lot of time when experimenting with compression settings for a large set of Stacked Textures for example. Or when you want to convert an existing project to using Granite. But it mainly allows for more flexibility when integrating the Granite import workflow into your engine and production workflow.
Any Texture Content
We added a mipmap streaming system that manages a conventional texture pool. Granite still breaks down every texture into tiles so you can benefit from the same optimized IO and cache management. You now have two different types of streaming in one system: a “conventional” streaming system that loads entire mipmaps in texture resources on the GPU. And tile based streaming system that uses virtual texturing by managing a tile cache on the GPU. Unique character textures, large 8K+ material masks, high resolution lightmaps,… These are all perfect candidates to use with virtual texturing. Textures for particle systems, low resolution textures (<1K), noise textures that are sampled many times,… are all better streamed into conventional texture resources.
Granite is now a complete streaming solution that allows you to choose how to manage the content optimally.
We’ve added support for DirectX 12 to the SDK. The current implementation is still in beta so we don’t advise going into full production with it yet. Let us know if you are aiming to use DX12. We’ll add more optimization over the next year. A virtual texturing system relies strongly on specific graphics API functionality to upload texture tiles, to update the translation table and to feed back the needed tile ids to the CPU to load them from disk.The key here is to use the APIs efficiently and ensure that the render pipeline never stalls. DirectX 11 is still our default API for Windows PC. We’ve also been working on our OpenGL ES 3 implementation with support for Android in mind (check our blog post about Granite SDK working for mobile VR for your reference).