20-11-2019, 12:36 PM
With the release of 5.0, we've designed things in a way that allows us to completely decouple simulation data (blueprints) from the simulation engine (solver+updater). This also resulted in better backwards compatibility for future versions, as changes in the way data is processed or laid out in memory at runtime will not necessarily affect the way data is stored in serialized form. The resulting workflows are also much simpler, imho.
This is not an arbitrary decision. Our plan moving forwards is to introduce interchangeable simulation engines: One of them will be the current native library, but we have another two in mind:
- A high-performance C# implementation based on Jobs + Burst. Expect not much difference in performance with the current engine, as we already use multithreading and SIMD internally. However, this will allow to support all platforms, and to include the full engine source code with the asset.
- A compute-shader based engine. Expect a huge increase in performance, but also quite some limitations in functionality.
This won't happen overnight, but we have already paved the way. Personally I'm very excited with the road ahead
.
Let me know your thoughts on this!
This is not an arbitrary decision. Our plan moving forwards is to introduce interchangeable simulation engines: One of them will be the current native library, but we have another two in mind:
- A high-performance C# implementation based on Jobs + Burst. Expect not much difference in performance with the current engine, as we already use multithreading and SIMD internally. However, this will allow to support all platforms, and to include the full engine source code with the asset.
- A compute-shader based engine. Expect a huge increase in performance, but also quite some limitations in functionality.
This won't happen overnight, but we have already paved the way. Personally I'm very excited with the road ahead
. Let me know your thoughts on this!