Our efforts to constantly improve and evolve Lumberyard continue today with the release of Lumberyard Beta 1.16. With over 250 new features, fixes, and improvements, this release introduces a significant architectural update to the memory management system, dozens of improvements to our animation and cinematics systems, and more. Let’s dive in.

Previous versions of Lumberyard contained multiple memory management subsystems, which made it difficult to track overall system memory usage. With Lumberyard 1.16, we’ve taken a big architectural step forward and consolidated our memory management into a single module, enabling you to accurately identify and track your memory allocation patterns. This is especially important for mobile and console applications, where memory resources are usually more constrained than PC game environments. We’ve had feedback from pre-release customers that by using the new system, they’ve been able to reduce memory fragmentation and footprint by up to 40%.

To handle a variety of use cases, the new memory manager includes a set of pre-defined memory allocation schemas. (You can also create your own if the need arises.) The pre-defined schemas are:

• AZ::HphaSchema – The HPHA (High-Performance Heap Allocator) schema combines a small block allocator (for small allocations) with a red-black tree (for large allocations), and provides good general-purpose performance. If you’re not sure which schema to use, use this one.
• AZ::HeapSchema – This schema works well for code that will execute across multiple threads, because the underlying thread caches accelerate the re-use of memory.
• AZ::BestFitExternalSchema – This schema stores bookkeeping information outside of the memory being managed. This is most useful for GPU resource management (textures, constant buffers, compute buffers).
• AZ::ChildAllocatorSchema – Use this when you want to create an allocator purely for tracking purposes, but want to base it on an existing allocator.
• AZ::PoolSchema – This schema implements a small block allocator, used to manage small, high-throughput allocations.
• AZ::ThreadPoolSchema – This schema implements a small block allocator per thread, using thread-local storage.

In addition to the memory manager refactor, we’ve also implemented over 50 improvements to Track View and our animation system. One specific request we’ve received from customers announcing games on Lumberyard was the ability to drive animations directly from Track View, and we’re excited to include that with 1.16.

If you’re building cinematic sequences, this means you can now run your entire animation pipeline using our animation solution, EMotion FX – providing a seamless experience without the need for animation graphs. To get started, simply add the Simple Motion component and the Actor component to an entity. Then add the entity to a Track View sequence and specify the motions that you want your character to animate. When you add a motion track to a track view sequence, the Track View editor drives animation on the Simple Motion component and its properties. To demonstrate this, the scripted sequences in Starter Game were rewritten using the new Track View animation features, and is now entirely based on Lumberyard’s component entity system.

There’s much more in Lumberyard 1.16, so check out our release notes for a full run-down. Many of these features and improvements come from work on Amazon Game Studios’ The Grand Tour Game and New World, and we’re excited to make them available to you, so you can continue to build ambitious games of massive scale.

As always, let us know what you think at [email protected]