Discover more of the new features and improvements from the particles and systems teams in CRYENGINE 5.6

CRYENGINE 5.6 is available now with myriad improvements and new features across the engine. Today, we’re speaking to Rafael Fritsch, Junior Engine Programmer, Scott Peter, Technical Designer, and, Luca Vezzaro, System Programmer, about the push forward in particles and systems.

Thanks for joining us, guys. Let’s start with particles. Can you explain what the new blend mode features bring?

Scott: Previously, particles could only be rendered in transparent modes, such as Alpha Blended or Additive. The new Opaque blend mode enables truly solid sprite and ribbon particles, that sort correctly with per-pixel depth-buffering. An additional option allows them to cast shadows, like other opaque objects. Transparent particle rendering enables great-looking effects, but also has some drawbacks, mainly that alpha-blended particles cannot be correctly and efficiently sorted with current hardware. Some particles, falling leaves or debris, for example, are naturally opaque, and we wanted to render them with many of the advantages of other opaque objects, such as brushes and characters, with correct depth sorting, and the ability to cast shadows.

How do you see this making a difference in projects?

Scott: Proper solid sorting is especially helpful with ribbon particles. Let’s say you use ribbon particles to dynamically create something like worms or vines, either static or moving. Ribbons can overlap or intertwine, and without per-pixel sorting, they can pop back and forth as they or the player move. With opaque rendering and shadow casting, they look more solid, like mesh objects, but can be procedurally generated via the particle system.

Talking of ribbons, what improvements have you made there?

Scott: The Render Ribbons feature has a new option called Tessellated. This enables the graphics card’s tessellation stage to smooth the joints in ribbon particles by generating new polygons in a curved shape. It is also adaptive to distance, so, for instance, the closer the camera is, the more polygons are generated.

To create smooth ribbons without hardware tessellation, the effect designer must carefully choose how many particles per ribbon to generate. If there are too few, the ribbon looks jaggy. If there are too many, it wastes polygons, and can also create kinked joints if they’re too close together. This is complicated if the particle density is affected by things like velocity or wind movement. And the correct particle density is also distance dependent. With tessellation, the designer can choose a reasonably low particle density, and the hardware will add additional polygons as needed, dependent on viewer distance. This feature is great for many ribbon effects, including trails from flying options, and organic objects like worms or vines.

What is the new particle tree view?

Scott: This is an alternate view available in the Particle Editor that presents effect components in a textual tree layout, rather than the original graphical node layout. Currently, all effects consist of components in a pure tree hierarchy, in which parent particles generate child particles. The original node view editor presents components on a 2D grid, where they can be placed arbitrarily, with parents visually connected to children. This view can be visually pleasing for some designers, but it can also be cumbersome to use with many components, sometimes requiring a lot of scrolling, zooming, and node movement.

The new tree view simply lists components by name, in a hierarchical list representing the parent-child relationships. The designer can click on each component to view and edit its features in an adjacent pane, and then move components around in the tree. Many users may prefer this simplified presentation, and it will make effect editing quicker.

How has the Game Platform system advanced?

Luca: The entire Game Platform system has received a substantial overhaul. We had to find a way to be able to run multiple game platform plugins. Now CryGamePlatform delegates all the actual work to other "Services" which are plugins as well, adding flexibility and extendibility.

Of course, we also have Steam improvements, including supporting integer progress values and progression from Steam Stat setups for achievements. We’ve also worked on leaderboards. Previously, a game could only request the update of one leaderboard at a time. If the game requested the update of a different leaderboard before the first one had finished, it would either overwrite the previous one or just mess up the results. Since finishing a leaderboard is an async operation, it’s complicated for game code to manage this situation. Now the code can simply request updates for as many different leaderboards as required without a problem. This improved Steam plugin has been used extensively by Hunt: Showdown, so it’s been proven in production.

What work has gone into the Job System?

Rafael: We have improved the under-the-hood performance of the Job System across the board. For example, we have reduced the cost of syncing when operating on the job queue and added the functionality to utilize the core of a thread that is waiting for jobs to finish. The effect of these optimizations is greatest on platforms with four logical cores, such as an Intel i3 or i5. Furthermore, we have modernized the internal interface for adding jobs to better support lambda functions.

How have the profiling systems improved?

Rafael: We have reworked the profiling systems of CRYENGINE to make them easier to use and extend, and we’ve reduced their performance impact. The changes to the profiling system are mostly under the hood, for now. Previously, all profilers were combined into the same macros. While this can mean less overhead for the individual profilers as they are called directly, it also means that we always call all the profilers, thus increasing overhead if you're only interested in one of them. Moreover, making changes to or adding or removing a profiler would require a full engine rebuild, as all the call sites change.

Instead, now there is a generalized profiler interface. That means adding profiling code is independent of which profiler will be used in the end. You can decide at runtime which profiler backend should be used and even switch between them dynamically. We have already used this simplified workflow to add support for the 'PIX on Windows' profiler. You can now even choose an 'empty' profiler, which does not do any work, to minimize the overhead.

We have also reduced the variety of macros you have to use. Previously, there were macros for functions, sections, loading time sections, regions, and markers, which could be pushed and popped. What remains are CRY_PROFILE_FUNCTION, CRY_PROFILE_SECTION, and CRY_PROFILE_MARKER. This change is a good step forward on its own, but it is also is an important foundation for future improvements. For example, we plan to develop a new CRYENGINE profiler that works the same on all platforms and has a frontend directly integrated into Sandbox.

There has been some substantial work gone into asserts. What was the aim there?

Rafael: Checking every argument and handling every corner-case in your code is expensive. However, it is important for your code to run as fast as possible, especially when it comes to games. That means that your code must run on some assumptions. However, code grows complex quickly, and these assumptions can be overlooked. That's where asserts help you. CRY_ASSERT has been around for some time and is really useful as it doesn't just dump messages into a log but presents you a with a dialog to react to the assert immediately.

Previously, to provide custom messages with the assert, there was the macro CRY_ASSERT_MESSAGE, and its legacy version CRY_ASSERT_TRACE. Now you can also supply messages to the shorter CRY_ASSERT, and the other macros will be removed in the future.

Then there's the CRY_VERIFY macro. This can be used inside expressions making it easy to check the results of operations. But we've also extended CRY_VERIFY so it can accept messages. Previously, we had the limitation that our asserts could not detect errors during the early startup of the engine. This has been overcome, and asserts can now cover even the earliest phases, such as the initialization of global static variables.

Thanks, guys!

We hope you’re enjoying CRYENGINE 5.6. If you want to find out more about what’s gone into this major update, check out our in-depth preview articles focusing on specific areas in the engine, including physics, rendering, audio, Sandbox Editor and Launcher improvements. Keep your feedback coming on the dedicated CE 5.6 feedback thread, and if you find a bug in the engine, please report it directly on GitHub which helps us to process the issue quickly and efficiently. Get updates from the team by following us on Facebook and Twitter, and don’t forget to join the community and our CRYENGINE development team over on our official CRYENGINE Discord channel.

Are you looking for your next career move? At Crytek, we value diversity and actively encourage people from all kinds of backgrounds and experience levels to apply to our open positions, so join us over at LinkedIn and check out our careers page.