Godot: Feedback on the automatic asset import workflow

Created on 23 Aug 2017  路  30Comments  路  Source: godotengine/godot

To cancel the current resource management mechanism, to restore to the 2.0 resource management, resource import needs a large number of current copy files and lead to the low efficiency in the current editor, import mechanism scalability is poor.

discussion enhancement editor

Most helpful comment

oh, also, if you are not doing mobile, you can disable etc2comp in the project settings. This makes the import process a lot faster

All 30 comments

Do you mean you want to have an option to disable auto-import? (it's an option in Unity which I currently use for the same reason as you said)

Not going to happen, but what was discussed is that images will be imported on background eventually, so they don't become such an annoying workflow.

Context note: I disable auto-import in Unity to be able to stay in play mode while editing code, this way my test environment doesn't annoyingly change as I am fixing it.
More importantly, it also doesn't force me to wait an awfully long time needlessly everytime I change anything in a script if I actually don't want to (our project takes like 20 seconds to compile with a beefy computer and blocks the editor everytime it gets focused, even if just one line changes in some script).

In Godot it's less of a problem because GDScript scripts aren't recompiled the same way as Unity does, and the game runs on a separate process.
However, it would become the same, big annoyance if GodotSharp did that :( @neikeq ?

@Zylann possibly we can use a project setting to disable auto-importing for gdnative and C# scripts?

(And have it enabled by default, so they're only reimported when the game runs)

I have to admit that even with a SSD, the process is really slow. Takes me at least one minute to open the 3d material test demo. There might be a problem of efficiency somewhere anyway no ?

@Zylann if GodotSharp did what? Block the editor when building?

@neikeq yes, if scripts change, its very useful to be able to manually tell when you want to compile, because on large codebases it can take a very long time as I explained (maybe some Unity users can relate?). It's not yet a problem for me anyways so I don't mind if such option isn't available yet, but I just fear that auto-import becomes a problem on very large projects in the future (also I don't understand why such an option would be impossible to do?)

@Zylann I would wait until that becomes a real problem and people complains. Doing stuff just because we think it might be useful might not be a good idea. C# in general compiles very fast so the codebase has to be gigantic

@groud the problem is mainly etc2comp, which is used when you develop for mobile

what was discussed is that images will be imported on background eventually, so they don't become such an annoying workflow.

Having this done before 3.0 would go a long way to reduce the frequency of complaints about the workflow. Then we could indeed keep it at that and only go further if there are really use cases for having more control over the import workflow.

@akien-mga I agree that background threading would be god-send.

Most people (I assume, like me) do not have SSDs on their machines, and it's simply _excruciating_ to work with complex meshes.

@akien-mga I can attempt to do it when i'm done with the first bugfixing pass

I know this is annoying, but please understand that before optimizing it, it has to work and until recently I am still fixing issues on it.

oh, also, if you are not doing mobile, you can disable etc2comp in the project settings. This makes the import process a lot faster

Sounds great, I'll open a clearer issue about implementing background import for Beta.

Superseded by #10583, as the initial feature asked for here, i.e. restoring the 2.x import system, won't happen (at least for now) as mentioned above.

@reduz
At present, the import system does not have any advantages, the game development process does not need to rely on the fine arts resources, import system currently limits the Godot resource expansion, editor accident increased the burden, Godot and not unity3d, Godot needs to be extended more flexible mechanism. The worst thing is why copy duplicate Art Games? Complete the release of resources is not better?

@cjmxp The new system solves a lot of problems we had before, even if the worflow changes. It also is more user friendly. I'm sorry if you were used to the previous one, but it will not come back.

Instead, we want to focus on helping you make the new workflow work best for you

@reduz
I have 1000+ PNG file Filter Mipmaps to each set of these attributes and so on at present, there is no global default settings, currently I work very hard to do, every time to replace the resource editor will no response.... I cannot be extended at present, cannot solve this problem

You're not suppose to work with the 3.0 version yet. As suggested, the import should be ran as background task in the final 3.0 release. We're not going to revert changes we are still working on...

I am Godot users, of course, how to set up the system and I can not decide, the 3 change is my love and you a great deal, I just say I import function shortcomings. Well, that was the end of the subject.

@cjmpx you can set a setting as default for a resource, check the import menu. You can also select many resources of a type and group edit them

thanks @reduz

@cjmxp Note that we do acknowledge that the current system has shortcomings, especially on the usability side. For example, as @reduz mentioned you can now specify a default import setting for a type, but if you already imported your 1000 assets, there is no easy refactoring tool to reimport them AFAIK - I'd personally like to see a kind of import manager tab where you can do global operations on the imported assets, instead of having to rely on the Import dock for a given resource. But that's out of the scope of this issue.

These things will come little by little as the rest of the engine stabilizes, more users experiment with it and ideas for usability improvements pop up. So don't worry, 3.0 should already been much better, and likely 3.1 will bring even more usability improvements.

I guess we can keep this issue open to gather early feedback - most of it should eventually end up in specific detailed issues like I did for the background loading though, so that we have a chance to improve the workflow gradually. I'll just rename it.

@akien-mga Actually, there is an easy refactoring tool. Just write .png in the filesystem dock, select everything, go to the import tab and set the setting for all of them

Still less easy than what I have in mind ;) I'll make a mockup of my idea in the coming weeks.

@reduz
In addition, I have a suggestion, whether or not you can, Filter, Mipmaps these attributes written into the ".STEX" file, the current large number of ".Import" files to do my head file management is not a bit confusing

I have a "mini client" project the first client contains only the engine and the script "is again play while downloading art resources used by PCKPacker may not be suitable for 3, resource loading restrictions led to the current project I can only modify the source code, this is not what I want to do for the version conflict and so on, can increase the number of small package support in resource loading system?

Of course, it is better to support binary access to resources, because the client may be modified by hackers, resulting in leakage of resources

Many of the initial usability issues have been fixed, and the overall design won't be reverted as asked initially, so I think this issue can now be closed. New issues can be opened for specific aspects that still need improvement.

Was this page helpful?
0 / 5 - 0 ratings