Rework of 3D asset import workflow to improve usability

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

There are several problems users have with the 3D asset import workflow:

• Inheriting lets you edit the asset, but you need a separate file instead of pushing changes back. Several users complain that they dislike this.
• Editing the inherited asset has limitations:
  • Materials can't really be replaced there (at much overriden). This is not ideal anyway as it would be better if its done in the import dialog, but many times this is the easiest workflow, specially if you simply want to do something like replace a material that comes with the file and use a visual shader based one.
  • Imported animations can't be edited. To do this, you have to save them to files and Godot will do its best to keep changes you make. This workflow is quite awkward and unintuitive.
  • Imported animation libraries can't be edited.

All these make the general experience of managing 3D assets in Godot significantly more awkward than it should be. Large part of the workflow has improved with the advanced import dialog in Godot 4.0, but this is still far from perfect.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The idea here is to do some changes to the import workflow based on a lot of user feedback . This should hoperfully make the asset import workflow perfect. It should behave as a new user expects it should and be as intuitive as it can be.

This consists of 3 fundamental changes:

• Materials going to nodes by default instead of mesh, more similar to how Unity works.
• Animations can be edited directly in the edited scene without having to save them to external files.
• Opening FBX/GLTF files should "just work" and you can save them back with your changes.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Moving imported materials to MeshInstance node

As mentioned before, materials are placed by default on meshes after import:

But this has the problem that, in an inherited scene, you can't really override or edit this in any way (because it means you need to also duplicate the mesh and make it local to make changes). It is possible to override in the node, but for users this is confusing because if they look there, they don't see materials.

This change means that, by default, Godot will move those materials to the node when importing, so it will look like this to users:

Trying to edit it will not work, so users will be shown with this dialog:

Making it more straightforward to edit the existing material or replace it by another one if wanted.

As always, remember, this will be an import setting you can change to move back materials to meshes if you desire.

Note: It may be desired to make this feature exist but be optional, as a few people mentioned they prefer to edit materials in the advanced import dialog instead, so they remain on the meshes and the meshes can be used independently with this proposal.

Add Animation / AnimationLibrary extending

Currently, when you intend to edit animations that came from an imported asset, you are presented with this warning that pops up a dialog:

This explains to the user how to make the animation editable. In general, this is terrible usability because more often than not users are dealing with dozens or even hundreds of animations, and saving everything to files can get very messy, plus the workflow is not intuitive.

The idea here is to allow the user to extend those animations. This will change the dialog to look like this:

The extended animation means that the Animation resource has a new field "inherits : Animation" which is base animation. The extended animation basically contains all the same tracks as the base one, and the tracks added to it are extra tracks. This is done transparently inside Animation, so it requires no extra changes to the rest of the engine.

Likewise, users will be able to add new tracks, but the original tracks will remain read-only.

The same goes to AnimationLibrary, if the user attempts to edit it, an extended one will be created (which references the original one):

Direct saves to imported assets

Currently, it is not possible to open an imported asset directly. At much it can be inherited and saved to another file.

Users have complained again and again that they are not happy with this workflow, they want to edit the imported asset, save the changes, and expect Godot will keep those changes.

The idea here is that from now on, trying to open the asset will create an inherited scene by default, no questions asked. Saving this scene should also "just work". What will happen in practice is that Godot will save the inherited scene to something like: asset.fbx.edit. This is a .tscn basically containing the metadata, but saved with this extension and hidden from the filesystem dock.

The main issue with this is that currently, when you double-click a fbx/gltf, it opens the advanced import dialog, which is really handy. To not lose this easy access, a button will be added that you can click to pop up the advanced import dialog:

And that's it. This should hopefully make the 3D imported asset experience in Godot as intuitive as possible. These changes do not require breaking compatibility, as these existing projects will continue working normally.

If this enhancement will not be used often, can it be worked around with a few lines of script?

N/A

Is there a reason why this should be core and not an add-on in the asset library?

N/A

[frkntlr]

When we click on a model, the import tool now appears. Here we can only export the materials. It does not give us the chance to use the ready materials we have.

If we drag our model onto the stage. Nothing about the material appears in the Inspector section.

There are 2 ways to change materials. We will change it by opening the instance or directly inside it to create a scene below. Or we will be able to see the children by right clicking and saying editable Children.

Of course we have the possibility to modify the materials by exporting them. But to add the materials we have ready, we need to edit in these 2 ways. This is not practical for a beginner or when editing too many objects. While many adjustments are made in an application that will already make 3d editing to adjust it, people are dealing with such processes in the game engine.

I think there should be an area on the Inspector where we can change and modify these materials without seeing the children. All the materials of the child children are in this area. It can also be listed by child names.

This is also how you can access the aimations. But instead of creating a scene and adjusting it, it would be more practical to add a structure pane like the one I suggested about these materials.

by creating a new scene or when we open the edit children section. Should we click on Mesh and change the material from there. Or it causes confusion whether we should change it from there by saying Surface material override. I don't know which one is right.

If there is only 1 material changing place, there will be less confusion. The material names we give in the 3D editing program come by default. If we want, we can change the names by clicking on the down arrow. If we want to change the editing not on the asset we imported, but on the default, by clicking the Apply button, we change the default name or material in this way (a better word can come to the place where apply is written). I don't know how appropriate this would be in a technical sense, but I think people would like it more in terms of practicality.

[reduz]

@frkntlr This is what this pull request is for: https://github.com/godotengine/godot/pull/86430

Here you can change materials or reassign them at import time.

[ArseniyMirniy]

My biggest suggestion is to make it a little like Unreal, here's what I mean:

Currently importing big scenes can be both handy and questionable. Generally everything is in place, pivots (origins) are set, hierarchy is correct, etc. But for any medium-big game it is very important to treat it like building blocks, not like it will be used only once as a whole.

The scene should be easily convertible into smaller pieces to rebuild it with instancing, meshes of each object should be convertible into meshes to be re-used if needed, etc. And I mean all of it should be much faster turned into files in file tray to then mass-edit all of that.

Additionally, materials approach is currently a pain even for a single object

These multiple sections of materials for each object are a mess, how they re-write each other and where should you really place them for instanced objects is the thing, I forget each time and it's what people are complaining very often. It's not just about technical issues, but also require some usability and visualization upgrades.

1. The materials from the import are not editable, but let's make a local copy if the user is trying to edit it.
2. It should be fast and clear to just re-use existing materials from the model to fine-tune them
3. Let's make it clear in which order the engine reads materials

[reduz]

@Rinocrosser

As mentioned above, for the materials, both this proposal and this PR: https://github.com/godotengine/godot/pull/86430 should solve the material editing issue, so you can both edit the imported materials, replace them by existing ones and, ultimately, replace them in the scene if you need. This gives you the freedom to do it as you wish.

Then, there is this proposal (https://github.com/godotengine/godot-proposals/issues/8750) that lets you treat an imported scene as a collection of assets you can use in your other scenes.

Does this cover what you mean, or is there anything else you believe should be needed?

[ArseniyMirniy]

Yes, @reduz

This sounds more or less like the issues I'm talking about. Will share feedbacks on arrival of these updates.

[reduz]

@Rinocrosser What makes this very hard is that different people have different preferred workflows. Some prefer to edit a whole stage in Blender and then export to Godot and at much tweak the materials. Others prefer to import individual assets and build whatever they need in the engine.

We have to cater to everyone and this is pretty hard, as it means allowing redundant workflows.

Likewise, some people do a model with all the animations and export it. Others need to separate models and animations and reuse multiple models and animations, which is harder. Everything has to work.

[ArseniyMirniy]

@reduz

This isn't about preferences of people, but more into scalability. Scenes edited in Blender will be worse performance-wise than ones properly edited in the game engine with reasonable instancing and re-use of meshes around. It will also require developers to switch back to Blender every time to make any serious changes.

I was a game producer on several medium-size projects and this isn't the approach anyone would bet on. Blender-phase is fine for level design blocking and not for any level-art and environment art stage. This is why the ability to divide scenes isn't a matter of taste, but a nessesarity to make the game of any commercial scale.

[TrickyFatCat]

@reduz the common workflow in many games is to create modular set of 3D assets which can be reused in many ways, including:

1. Level Design
2. Environment Art
3. Gameplay Objects
4. Etc.

Also, it's quite a common way to sell asset packs for Unreal Engine and Unity, as it enables people to experiment and keep only those assets they truly need, especially for developers who are not into Blender and 3D.

[AWKgamedev]

This should help a lot to untangle the mess that asset importing often is. However, I believe that imported animation tracks should be editable too since it's normal to want to tweak things within Godot like the positions of a particular animation that happens to be offset wrongly (and I've done it myself) without having to hop back and forth between programs. If an animation with an edited track is re-imported they could both fit into a dropdown where you pick one in the animation editor, I would also consider a popup to pick between the reimported or edited track but that would easily get out of hand and users could often want to keep both tracks to compare them before picking one, and I'm against making the user be forced to choose without having a good look at what is actually being chosen.

This might be a hot take I think it would be wise to just go away with the concept of files and their types entirely on the user side of things, pack anything importable into a consolidated asset filetype that contains a copy of the imported file (or files) and tuck the original somewhere where users don't usually have to care about in the UI, making a distinction between "source" files and "thing" files. Inheritance data can be kept for updating files and the assets that use it but the asset file should be self-contained so it's easy copyable between projects without having to also copy separate sidecars and project metadata files. The downside of this is having a proprietary filetype and the OS filesystem complications that it entails.

[reduz]

@AWKgamedev unfortunately you can imagine it is a huge amount of work and to maintain to do something like this (an animation merging system) when the demand for this is so, so little.

Additionally, when you export animations from a 3D app, the animations are baked, you no longer have access to the original keyframes or curves. This is not a Godot limitation,but how it works in all the exchange formats (FBX, GLTF, etc), because things like IK, several curve editing options and other modifiers are very custom to each app not supported by those exchange formats, hence the animation has to be baked and It's no longer practical to edit.

To add even further, animations are often compressed when imported, because they take a lot of space, so while Godot will still display keyframes, they are in no way editable. So the possibility of editing it in the engine is near none.

So, that is not going to happen anytime soon. What users need the most is the ability to add their custom tracks that toggle/animate custom properties, call functions, play sound, etc. in the existing imported animations.

[reduz]

@Rinocrosser It really depends, in my own experience (but also there are a lot of postmortems from AAA games, including games like Uncharted) where the levels are grayblocked (or CSGed) and then this is exported back to the DCC and artists just fill up the scene there. These companies often have plugins for Maya where they can see the game materials and properties in the DCC (today since everything is PBR, its not as necessary). For other types of games (generally open world) it is more common as you say to create modular assets and just build with this in the engine editor.

I definitely discussed with many Godot users who prefer this workflow too, so definitely it is a matter of preference, or a matter of what fits best the art direction or game design.

The thing is, Godot has to support all common workflows properly and equally as easily. There is no right or wrong workflow.

[ArseniyMirniy]

@reduz Semi-procedural and modular / "construction kit" approaches are standard now for almost any game. It's possible that certain buildings and structures are solid, but the majority of games (not only open-world) use modular approach very often. Otherwise it will force to make too many assets and spend too many hours on them.

Yet again, Godot is already nice for small games and the question is "how to make it better for bigger games", same as @TrickyFatCat said: if there is a team working on a game, they should not be forced to swtich to any other app if they don't want to. It should be editable in Godot, no doubt.

[reduz]

@Rinocrosser Again, this discussion is pointless when we already established that all workflows should work.

[WickedInsignia]

@Rinocrosser Again, this discussion is pointless when we already established that all workflows should work.

This is a self-contradictory response when you are elsewhere suggesting that we should not pursue features with little demand like below:

@AWKgamedev unfortunately you can imagine it is a huge amount of work and to maintain to do something like this (an animation merging system) when the demand for this is so, so little.

The manpower spent on making Godot work seamlessly with Blender scene import could instead be spent on better support for modular workflows. The former is a sizeable undertaking with little relevance. Importing whole scenes from an application is a nice novelty, but there's a reason it's not done very often. It's also worth considering that many Godot users are generally hobbyists working on small games and jams: the way they work may not be well-informed or scalable. It might not be wise to treat public consensus as equal to established industry standards on this issue.

"We" aren't establishing that "all workflows should work," you are deciding that on your own. All workflows are not equal and some are simply ill-informed. It would be worth prioritizing the approach that benefits scalability before pursuing corner cases and niche workflows. An engine should probably prioritize efficient workflows and encourage users into them. Godot isn't a "do it however you want" engine anyway, since the nature of its inheritance structure encourages users into certain ways of working with it. It wouldn't be worth pretending the engine isn't like that, or that the manpower is available to create and maintain features that support every possible workflow.

[TrickyFatCat]

@WickedInsignia in addition, a good modular workflow can make the life of asset creators easier, especially, when Godot will open an asset store.

@reduz talking of Maya, Houdini and other exports in AAA. Usually they're built in a very particular way which suits production pipelines and project tech via a dedicated team.

[reduz]

@WickedInsignia Do you spend a large amount of your time talking to different Godot users, receiving feedback and generally trying to understand how people needs to use the engine? No, you don't.

So then again, trying to convince me that things should work only the way you prefer or think should work (because you are somehow entitled to be right) is pretty toxic.

Different people have different workflows and you have to deal with it, there is no right or wrong workflow. It does not matter to me if one workflow is more used than another.

This is why on my end the focus is that everyone can be happy with their preferred workflow. You can be happy with yours, others can be happy with theirs. All workflows properly supported. If you don't agree with this, then please take your entitlement somewhere else.

[reduz]

@TrickyFatCat Nobody is saying modular workflows won't be supported, In fact as I mentioned, there are many proposals open towards this goal that are being discussed (the main one is this one). I don't understand why the defensiveness.

[ArseniyMirniy]

Everyone, please, calm down!

@reduz the only thing all folks above (me included) were saying is that Modular = Scalable, and Scalable = Bigger Games, which Godot needs. Keeping some sort of non-modular mode is also reasonable (since it is already there and some people with smaller games are enjoying it).

But some of your comments looked like you are not very interested in modular approach and "someone would do it it", but in Godot community your understanding and your support is crucial to some changes. This is why everyone was so concerned about your replies.

Also, Happy New Year, everyone!

[reduz]

@Rinocrosser I never denied any of this at any time, quite the contrary I agree this has to be supported well, so I don't really understand why the aggressiveness.

[reduz]

@Rinocrosser As you edited your reply, I understand what you mean now. You don't have to convince me particularly, I understand there is clear interest on this and other contributors already put up pull requests towards this goal, so I am trying to organize that work via opening a proposal and trying to get some consensus on how it should work, then I will try to help organize the work to get this done.

[ArseniyMirniy]

@Rinocrosser Perfect, thanks!

If needed, I will be glad to provide any consulting support on how it usually works in Unreal for medium-size teams.

[WickedInsignia]

@WickedInsignia Do you spend a large amount of your time talking to different Godot users, receiving feedback and generally trying to understand how people needs to use the engine? No, you don't.

How could you possibly know this? Assume for the sake of discussion that I do: I certainly wouldn't use it to assert my own authority on this topic. Established industry standards play as important a role in defining Godot's workflows as user feedback, especially since the overwhelming majority of that user-base is hobbyist in nature and may not be aware of commonly scalable methods.

So then again, trying to convince me that things should work only the way you prefer or think should work (because you are somehow entitled to be right) is pretty toxic.

I never said it's the only workflow that should ever be implemented.

Different people have different workflows and you have to deal with it, there is no right or wrong workflow. It does not matter to me if one workflow is more used than another.

It does very much matter if one workflow is used more than another and there absolutely are right and wrong workflows in games. That's not to say there's only one right way of doing things: there are just many that lead to inefficiency or aren't common. Ideally support most of them, but that's not feasible without strenuous work and maintenance.

Ultimately what I'm trying to say is that proven workflows should be focused on first. You've openly admitted in the past that Godot doesn't have the manpower to stack up to other proprietary engines, so not all workflows are openly achievable right now. If there's one workflow that reflects the way most games are made and is a proven industry standard, it's the modular workflow. That would offer users the best support for their projects upfront and afford them a great deal of scalability, with support for less common workflows following later. Decisions made at this time around import workflow would be benefited by prioritizing modular workflows, since we can't feasibly prioritize every possible workflow.