Hi guys! This thread is for discussing the possibility of changing the Import/Export system in Godot 3.0.
Current one works by having two separate import and export systems. It works, but it's complex for a lot of users, as you generally need to have a separate directory for stuff you want to import, and also separate options for the stuff you want to export.
As a result, the code is difficult to maintain, generally buggy, and not that user friendly.
My proposal is to move to a system more similar to how Unity works, where you just copy your assets like .dae , .wav, .png, to the project directory.. then Godot does a forced import of the assets, yet your code can keep referencing those files as if they were native. At export Godot will just export it's native assets and replace internally.
After seeing a lot of people working with Unity this way, I really think it's difficult to deny that it's more user friendly. It will also make the import/export process and code _much_ simpler.
Any thoughts?
Will we still be able to set processing options to assets? (possibly depending on target export platform)
@Zylann yeah that should not change
+1
Something many suggested also is that, instead of having a list of platforms, we allow the user to create many export presets per platform (with different settings)
Doing things the unity way poses a few problems though..
1) If you copy a .dae or something else to the project foler, the imported version would not be modifiable (will not be able to save it back). Unity solves this by making separate files for the materials, but this would be pretty messy in Godot. Right now you can edit the scenes imported in Godot, reassign materials, and when the source is changed it keeps the material changes. I see no way to keep the functionality as is (Godot will not be able to write a dae file). A specific workaround to save modified materials would be needed... any ideas?
2) It would be fantastic if images can be force-imported always, so you could change a lot of information in them (like, fix alpha borders, compress to webp automatically, compress to S3TC/ETC2 automaticallly, etc). The main problem with this is that if you want Godot to deal with images directly as resources, it would no longer work. (Ie, to dowload an image and load it in a game, or saving an image from a screencap and load it back would not go any more via resourceloader/resourcesaver).
IMO, for:
1) the Scene -> Save option for this scene in the Scene menu might have to display "Save material reassignments" or something like that (as in, disallow save, but show some different save text instead?)
2) I think this would not be too bad
What about putting a shadow directory for imported content in project folder?
This may allow to define force import procedures for "project tree -> shadow directory" operations and export modified resource procedures for "shadow directory -> project tree" operations I think.
Godot may prefer shadow directory version over project directory version when one found.
Downloaded images or screencaps can be processed as a new file from project directory and force imported to shadow directory immediately for usage given that importer is part of the exported code.
VCS systems may track "shadow directory" or omit it as needed.
Also external converter for dae format from shadow directory may be coded at later time (theoretically speaking).
@reduz, about the two points above:
.scn, which is inherited in a .tscn and changed there..dae loaders and everything, so people can use them if they want out of the editor).Probably the shadow directory can be kept outside the project until export,
that should make things easier
On Jan 2, 2017 09:51, "hubbyist" notifications@github.com wrote:
What about putting a shadow directory for force imported content in
project folder?This may allow to define force import procedures for "project tree ->
shadow directory" operations and export modified resource procedures
for "shadow directory -> project tree" operations I think. Godot may prefer shadow
directory version over project directory version when one found.Downloaded images or screencaps can be processed as a new file from
project tree and force imported to shadow directory immediately for
usage given that importer is part of the exported code.VCS systems may track "shadow directory" or omit it as needed.
Also external converter for dae format from shadow directory may be
coded at later time (theoretically speaking).—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7408#issuecomment-269968596,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wWMrG160dXhdXsZuHQpaSJC4amKks5rOPLSgaJpZM4LYx3Z
.
Also, an alternative could be to simply save materials to files on import
On Jan 2, 2017 10:18, "Juan Linietsky" reduzio@gmail.com wrote:
Probably the shadow directory can be kept outside the project until
export, that should make things easierOn Jan 2, 2017 09:51, "hubbyist" notifications@github.com wrote:
What about putting a shadow directory for force imported content in
project folder?This may allow to define force import procedures for "project tree ->
shadow directory" operations and export modified resource procedures
for "shadow directory -> project tree" operations I think. Godot may prefer shadow
directory version over project directory version when one found.Downloaded images or screencaps can be processed as a new file from
project tree and force imported to shadow directory immediately for
usage given that importer is part of the exported code.VCS systems may track "shadow directory" or omit it as needed.
Also external converter for dae format from shadow directory may be
coded at later time (theoretically speaking).—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7408#issuecomment-269968596,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wWMrG160dXhdXsZuHQpaSJC4amKks5rOPLSgaJpZM4LYx3Z
.
Can it be that due to the work on this, the Import menu is totally empty at the moment?
Yes
On Jan 26, 2017 17:05, "Ray Koopa" notifications@github.com wrote:
Can it be that due to the work on this, the Import menu is totally empty
at the moment?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7408#issuecomment-275497896,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21550Wq1NXXe64Tu6exWwTUxvQ6Aks5rWPxugaJpZM4LYx3Z
.
Closing, this discussion is finished :)
Most helpful comment
Something many suggested also is that, instead of having a list of platforms, we allow the user to create many export presets per platform (with different settings)