The Our Machinery blog has a new post discussing Creation Graphs , the idea of taking reusable building blocks and assembling in a data-driven way within a game engine's editor with the goal for Technical Artists and non-programmers to be able to tweak and roll their own features.
The post shares the thought process and exploration of this idea at Our Machinery, discussing Data Pipelines and including a deeper dive into Image Processing:
QuoteThere are lots of operations involved in building a data pipeline for image processing, e.g format conversions, mipmap generation, compression, range validation, categorization, etc.
When using a Creation Graph for expressing a data pipeline for image processing you typically end up with one node importing a source image from somewhere, then piping that image through a bunch of nodes conducting the various operations of interest until you output the final result as a new image.
Exactly what you do in the graph, and how you do it, depends a lot on its execution context, e.g: It is fine for a Creation Graph responsible for processing traditional game textures authored by an artist in a DCC-tool to take a significant amount of time as they typically only need to run very infrequently (i.e., when the artist imports or updates her texture). On the other hand, a Creation Graph responsible for processing a runtime updated texture has to run very efficiently. It’s all about finding the right balance between your performance, memory and quality constraints.
Read the full blog post on Creation Graphs to learn more.
