11 min read
Our new website is a work in progress, please let us know what more you would like to see.
With our Godot Integration Architecture, all this and more is going to be possible. Read on to learn more about our design, the current status and our plans for the future.
After you read our post, we also have a big ask from you: Please fill out this form , and tell us your thoughts, which features you need most, what you liked and most importantly what is missing. We are looking forward to hearing from you!
One of the most critical points of game development (including any other 3D, graphics-intensive application development) is the Asset Pipeline: in essence the process of getting graphics assets (models, textures, animations ... etc.) from the mind of the graphics artists into the game engine.
And we need it in a form that allows high performance, real-time rendering with as good quality as allowed by the target hardware and the engine.
The standard method is to use an elaborate Export / Import process from the graphics designers' tools into the Game Engine. During the design process, the artists have to follow specific rules to make sure that the exported assets can be imported into the Game Engine without any hiccups.
This Export / Import procedure is a destructive operation: the industry standard transfer formats like FBX and the open standard GLTF are not native formats of any engine. This means that they cannot represent every feature of the game engine thus providing a suboptimal workflow. For example, transparent, glass-like surfaces were not supported by GLTF, even though it is possible to represent them in Godot.
There was a great presentation at this year's Blender Conference by Miro Horváth exactly about this topic: Game Asset Production Pipeline for ARMA Reforger .
One of the key advantages of starting a project with Unity and Unreal Engine is the untold number of assets designed for those engines. Despite the great efforts of the Godot Community, this is a hard-to-fix problem.
At Migeran, we wanted to build a vehicle simulator with high-quality assets (maps, vehicles, pedestrians, and other props) based on Godot 4. We already had expertise in developing and customizing the Carla Simulator , so we knew that it has everything we need, but all the assets were made in Unreal Engine's native format. Check it out from the Carla 0.9.13 announcement post :
Lossless export functions are (understandably) not very high on the priority list for any commercial game engine.
The Architecture, as implemented today has 4 important elements:
I will elaborate on each component below.
To embed Godot into another process, we not only have to build it as a shared library (which is already done for Example for Android), but also to define a simple, easy-to-use C API, that can be used by the host process to initialize the engine, and later control its main loop.
In its original design, Godot looks for plugins that use the GDExtension API in dynamically loaded shared libraries, that are loaded and managed by Godot itself.
For our use case, we had to extend this design, so the host process can also register new GDExtensions with the embedded engine directly. This way the host process can interact with any core or extension class using the GDExtension API to access the full capabilities of the engine.
We also extended the GDExtension API with more introspection capabilities: it is now possible to query all exported types (core and extension) and to register for notification if an extension type is added or removed.
We are well aware of TouilleMan's great Godot Python Extension , and usually, we are a big fan of Not reinventing the wheel.
Why did we decide to create our own version in this case? In some cases very similar software problems - in our case using Python to access the Godot APIs - can be solved in completely different ways, with different design goals.
Our goals were:
import godotprint("Godot module imported successfully!")array_mesh = godot.ArrayMesh()vertex_array = normal_array = uv_array = # Filling of arrays omitted for brevity.index_array = [0, 1, 2, 0, 2, 3] # NOTE: Godot engine uses clockwise indexing.surface_array = [None] * 13surface_array = vertex_array # Mesh.ARRAY_VERTEXsurface_array = normal_array # Mesh.ARRAY_NORMALsurface_array =  # Mesh.ARRAY_TANGENTsurface_array =  # Mesh.ARRAY_COLORsurface_array = uv_array # Mesh.ARRAY_TEX_UVsurface_array =  # Mesh.ARRAY_TEX_UV_2surface_array =  # Mesh.ARRAY_CUSTOM0surface_array =  # Mesh.ARRAY_CUSTOM1surface_array =  # Mesh.ARRAY_CUSTOM2surface_array =  # Mesh.ARRAY_CUSTOM3surface_array =  # Mesh.ARRAY_BONESsurface_array =  # Mesh.ARRAY_WEIGHTSsurface_array = index_array # Mesh.ARRAY_INDEXMesh_PRIMITIVE_TRIANGLES = 3array_mesh.add_surface_from_arrays(Mesh_PRIMITIVE_TRIANGLES, surface_array)
Of course we can also save our newly created Mesh into a resource file:
resource_saver = godot.ResourceSaver()error_code = resource_saver.save(array_mesh, "/path/to/test_plane.tres")
We are currently working on Unreal Engine integration, and as you can see from the first image, we can already convert simple static meshes without materials. The next step is adding PBR material support, and then observing all the basic sample meshes provided with Unreal inside Godot.
We chose to use Python because it is the most common integration language in the industry, it is Blender's main extension API, and both Unreal Engine and Unity support it.
What about using C# with Unity? With the latest GDExtension support in Godot's C# bindings, it should be pretty straightforward to add support for using C#, if there is interest in it from the community.
As you can see we have already laid the foundations and have shown the Proof of Concept. But there is much work ahead.
We intend to develop tools for both Unreal and Unity, which make the migration of assets, but also scripts (e.g. Unreal Blueprints) a straightforward experience.
The goal is not to provide a 100% automated solution, but to provide tools that can already do 80% of the work, and enable developers who are working on the specific migration projects, to quickly develop their custom scripts to handle the project-specific tasks.
With the above pieces of technology in place, it will be possible to create the Ultimate Blender Integration of Godot into Blender. This includes:
Currently, we embed Godot in Headless mode, so no graphics output can be shown inside the Host Application. While this is already good enough for doing automated pipeline integrations, like converting foreign assets to native Godot formats, we want to go further.
We want to be able to embed the Godot Engine output into the host application. This will allow features like Live Interactive Previews inside Blender: the artist could see the assets she is working on without any delays or additional steps. This will provide a huge productivity boost for the graphics asset design, especially for Indie Games with very tight budgets.
Currently, only a single instance of Godot may be initialized in one process. However, there are many use cases, where hosting multiple instances in one process would have huge benefits:
At the moment the PyGodot bindings are still a bit limited, some features, like enums, are not included yet. It is also not possible to implement new extension classes in Python. We intend to add these missing features, to have a complete solution.
We hope that our vision of the Ultimate Asset Pipeline and all the related technologies make you as excited as we are.
We have a big ask from you: Please fill out this form , and tell us your thoughts, which features you need most, what you liked and most importantly what is missing. We are looking forward to hearing from you!
Sign up for our newsletter to be the first to know about updates on this topic or any other insights that we share.
If you are interested in starting an outsourced software development project, contact us, we would love to work with you.
Migeran is a full-service software engineering company. In the past 15 years, we have been delivering software projects for our clients in a large variety of markets using a broad set of technologies, including:
Our first own product, Migeran for iOS was acquired by Intel in 2015 and released as the Multi-OS Engine.
We are available for new projects, you may contact us if you would like to learn more or have a project that you would like to discuss with us.
Share this post on Twitter.