Import PSD as separate layers or as plain image

[anunknowperson]

Describe the project you are working on

2D game with heavy use of cutout/skeletal animation

Describe the problem or limitation you are having in your project

Recently, I've been working on skeleton 2D animation, and I've found that transferring a layered picture from my graphics editor (SAI) to Godot is a time-consuming process that doesn't yield good results. For example, if my image has 50 moving parts, I would need to manually export 50 pictures to jpg and then set each picture to the right position in the editor. This process is not only time-consuming, but it can also create clutter in the file system of the project. This same issue also applies to Cutout animation.

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

This is a supplement to the https://github.com/godotengine/godot-proposals/issues/6302

It's important to note that, in this context, PSD shouldn't be associated solely with the proprietary software, Photoshop. PSD has become an industry standard over the years, and all advanced image editors now support exporting to it. Additionally, PSD is the only format that all editors can export to, including Photoshop, SAI, Krita, GIMP, and others.

Considering user-friendliness, supporting PSD could significantly improve the workflow for artists and animators.

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

See related proposal

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

This can be done as GDExtension plugin. I will most likely create a PR in the main engine branch, but if this proposal is not successful, it will be converted to plugin.

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

PSD is a very popular and standardized format, so it can be added for convenience.

[paddy-exe]

As stated here in Kritas documentation:

.psd, unlike actual interchange formats like .pdf, .tiff, .exr, .ora and *.svg doesn’t have an official spec online. Which means that it needs to be reverse engineered.

Sometimes, you might even see users saying that a certain program is terrible because it doesn’t support opening PSDs properly. But as PSD is an internal file-format without online specs, it is impossible to have any program outside it support it 100%.

Afaik Unity has a contract with Photoshop to use their SDK which makes it possible to have good support for their format. Not sure if it's feasible to implement this.

[Calinou]

Not sure if it's feasible to implement this.

https://github.com/godotengine/godot/pull/73417 features PSD support using psd_sdk, which is a reverse engineered library.

That said, if you want an open format that supports multiple layers, OpenEXR is the way to go. Godot doesn't support importing multi-layer OpenEXR files yet, but this could probably be implemented since tinyexr has support for it.

[lyuma]

PSD support is quite common across a variety of tools and engines, including Unity and Unreal Engine. Even Blender supports PSD files as textures, despite being open source.

I'm a little confused why the original proposal at #2758 was closed when the only two negative comments came from one person and there were only two other thumbs-down. Not every feature is beneficial to every user: that doesn't mean it is without merit.

From a technical perspective, it would be good to see what fraction of the wide breadth of PSD files are 100% supported by MolecularMatters/psd_sdk. If it's really good support over a variety of PSD files, it would be more useful. If psd_sdk is very poor, I would be concerned about making it a core feature.

I could see arguments for implementing as extension, but it would be nice to see a proper discussion, perhaps analyzing the amount of code added in psd_sdk, and the maintainability impact, since Godot core developers will be forced to keep this thing working, contrasted with the benefit to users by having the same PSD files they use in Blender and Unreal also work in Godot.

[lyuma]

@anunknowperson would it be possible to edit your PR to cross-link to this proposal? or is this a funamentally different approach, in which case the PR should be changed to draft status until the proposal is dicussed / implemented?

I could see strengths in both multi-layer EXR as well as PSD. They are different ideas, and perhaps could have different proposals. It's a good argument that .psd is not the only way to solve the problem of multi-layer import. I think it might be good to separate the two sub-problems of

• usability of having the popular proprietary format .psd work in Godot, and
• ability to import multi-layer files of which there are quite a few formats including .psd, .exr, .tif (Proposal #4620) and others

[Calinou]

For reference, this is something reduz personally desired to have a long time ago. Back in 2015-2016, the Godot documentation featured a "Artists Use PSD" header in one of the pages :slightly_smiling_face:

However, there were no production-ready, permissively licensed libraries available to read multi-layer PSD files back then.

I think it makes sense to support this, but if we support PSD, we should make sure to support another layered format that isn't proprietary at the same time (such as OpenEXR or TIFF). This is similar to the FBX situation: we support it, but we provide several fully functional open alternatives to choose from.

Engine bloat in the editor is definitely a concern for PSD or TIFF, but not for OpenEXR, since we already have tinyexr linked in editor binaries.

Engine bloat in export templates isn't an issue here, as libraries would only be included in editor builds. Supporting run-time loading of PSD files would require custom export templates, like we do with OpenEXR currently.

[ghost]

I'm going to repeat what I wrote in the PR, sorry, I was so appalled by reactions of some of the contributors, that I totally missed the proposal. Use of PSD format is a very common workflow that allows artists to skip the export process altogether by just editing and saving the .psd file directly, and having it updated in the engine. It makes no sense for artists to export their work into .png or whatever (surely they don't work in .png, unless it's something simple), for it to then be converted into BC7 or something by the engine. As much as I dislike Photoshop and the format itself, PSD is the only universally supported format that allows seamless use in actually good software like Clip Studio Paint or Paint Tool SAI, or any open source software. I like the idea of having an open source format, like GLTF, but there is no support for OpenEXR in most software, and there is a very slim chance of it happening.

Also just want to add that I'm new, and I really liked Godot, and I'm ready to close my eyes to the fact the asset pipeline for 3d is asinine (sorry), but the way some of the contributors outright refused the PR on the grounds that they don't need it, and others passive-aggressively defended their position, really got me worried about my decision to use it. Really didn't expect Godot to have problems with community of all things. I'm glad that at least the man behind the wheel knows what he's doing.

Also judging the demand for a feature based on GitHub activity is not right. I doubt many artists are going to come here to ask for a fix to a minor inconvenience. It's also not at the top of the list for most developers because there are more pressing issues requiring attention.

[cure627]

@dame-ng I get the feeling that people who need .psd support (artists) just don't visit github.

and some core developers simply don't need this feature.

but I don't understand why it gets so much negativity, because the psd import code simply won't get into the export.

(and I, as a person who works with 2D, would be very, very happy to see this feature in the editor)

[cure627]

I also want to say that the process of 2d skeletal animation in godot mentioned by OP is just hell, compared to spine2D or unity. Because of the lack of a lot of handy tools and having to do the same actions, which could be greatly simplified (like automatically distributing weights, or automatically creating meshes). Support for layered format, and preferably PSD, so that every time you don't need to transfer the files to some other program and export them to exr, because exr is not supported in many places (SAI, for example) would greatly simplify the process and make this toolkit a bit more attractive.

[ghost]

I get the feeling that people who need .psd support (artists) just don't visit github.

Yes, it is the problem with open source software for artists in general. Basically programmers make what they THINK artists need, not what artists actually need. And artists are rarely in the conversation, because they just use proprietary software. That's why Linux desktop is in a sorry state, why GIMP is unusable, and even Krita is nowhere near. Blender made a significant jump towards user friendliness and got a lot of love, I hope Godot will strive for that too (In fact Godot's user interface is fantastic, absolutely the best. Just the asset pipeline needs a bit of work).

[anunknowperson]

using psd_sdk, which is a reverse engineered library.

@Calinou, Are you sure it's reverse engineering?

The PSD format has an official specification: https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/

[anunknowperson]

Programs that support PSD import: Game Engines:

Not open source: Unity (https://docs.unity3d.com/Manual/ImportingTextures.html) (supports import by PSD and TIFF layers)

Open Source: Unreal Engine (https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Textures/Importing/)

(supports PSD import, most likely by layers, I haven't checked)

3D Software:

Open Source: Blender (since 2.7, https://blendersensei.com/holy-crap-psd-support-in-blender/) (Supports layered PSD and Tiff.)

Not Open Source: 3Ds Max (https://blendersensei.com/holy-crap-psd-support-in-blender/) (Supports Layered PSD)

Image Editors: Open Source: Krita, GIMP

Not Open Source: Photoshop, SAI, Clip Studio Paint

And these are just a small number of examples. So far, almost all the programs I have opened support PSD. So I can say with 100% confidence that PSD has become a standard not only for the image industry, but also for gaming industry. I see no reason why it shouldn't be in an editor. (especially when we support fbx)

[anunknowperson]

@paddy-exe

As stated here in Kritas documentation: .psd, unlike actual interchange formats like .pdf, .tiff, .exr, .ora and *.svg doesn’t have an official spec online. Which means that it needs to be reverse engineered.

Isn't that what you need? And, as far as I know, it was released a long time ago. https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/

[YYF233333]

Hello, I am currently learning godot and trying to port a visual novel to it. I would be very happy if we have layered image support, because visual novels basically just work around layers. Character image usually has over 10 layers representing different faces and actions. Without such support, I have to export each layer and reimport and build them up at runtime, which is quite annoying and require a lot of setting. PSD import is the best beacuse we get these images in psd format, but TIFF is also ok. (sorry for poor writing, english is not my mother tongue)

[anunknowperson]

https://www.moon-soft.com/program/FORMAT/graphics/PSD.pdf .psd format specification released in 1997

[paddy-exe]

@paddy-exe

As stated here in Kritas documentation:

.psd, unlike actual interchange formats like .pdf, .tiff, .exr, .ora and *.svg doesn’t have an official spec online. Which means that it needs to be reverse engineered.

Isn't that what you need? And, as far as I know, it was released a long time ago.

https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/

I would just want to clarify that I am not by default against it. I was with that Statement not sure if this open-source SDK for PSD format was reverse-engineered or not. Plus, I am not sure what exactly the problem for a GDExtension would be (maybe considering it become first-party)? Depending on the LoC the addition of this feature adds, the complexity of maintaining it and the stability of the underlying SDK (plus their maintainability) all influence if this is a viable solution in my humble opinion. I get that artists will want this feature and I agree that it would make sense for studios to have this feature as well. Just please understand the thoughts above that are coming from contributors (and especially from core contributors) since they will have to maintain it in the future.

[anunknowperson]

By the way, i just checked and in blender 3.0 dragndrop psd import works perfectly. But in blender source code I didn't notice psd_sdk in libs. Which library does blender use or is there its own import code?

[yosoyfreeman]

I'm going to repeat what I wrote in the PR, sorry, I was so appalled by reactions of some of the contributors, that I totally missed the proposal. Use of PSD format is a very common workflow that allows artists to skip the export process altogether by just editing and saving the .psd file directly, and having it updated in the engine. It makes no sense for artists to export their work into .png or whatever (surely they don't work in .png, unless it's something simple), for it to then be converted into BC7 or something by the engine. As much as I dislike Photoshop and the format itself, PSD is the only universally supported format that allows seamless use in actually good software like Clip Studio Paint or Paint Tool SAI, or any open source software. I like the idea of having an open source format, like GLTF, but there is no support for OpenEXR in most software, and there is a very slim chance of it happening.

Also just want to add that I'm new, and I really liked Godot, and I'm ready to close my eyes to the fact the asset pipeline for 3d is asinine (sorry), but the way some of the contributors outright refused the PR on the grounds that they don't need it, and others passive-aggressively defended their position, really got me worried about my decision to use it. Really didn't expect Godot to have problems with community of all things. I'm glad that at least the man behind the wheel knows what he's doing.

Also judging the demand for a feature based on GitHub activity is not right. I doubt many artists are going to come here to ask for a fix to a minor inconvenience. It's also not at the top of the list for most developers because there are more pressing issues requiring attention.

Well, as an artist i would like to clarify some things you said:

• PSD never been a good idea to sharing things to anything other than photoshop except is for tools that directly pay adobe to use it. Is really far from being universally supported and you even need an extension to import them in blender.

• I don't know what you mean by "Actually good software" but there is actually good software more than clip studio or SAI, some of them even open source that are more capable in terms of inporting/exporting. Prioritizing The workflow between multiple proprietary software over a solution that allows layered images from open formats would not make so much sense. This is similar to FBX, i wanted a better support but it really made sense to improve the open alternatives as much as possible before.

• I been and I am kind of new with Godot too, i understand that participating in discussions can be imposing but Godot have no problem at all with the community. Is one of the most kind, accepting, patient ones i ever seen. some of the technical persons in Godot see hundres of PR's and have no much time so they do the possible to be clear and polite even tho via text message can not always appear that.

I get the feeling that people who need .psd support (artists) just don't visit github.

Yes, it is the problem with open source software for artists in general. Basically programmers make what they THINK artists need, not what artists actually need. And artists are rarely in the conversation, because they just use proprietary software. That's why Linux desktop is in a sorry state, why GIMP is unusable, and even Krita is nowhere near. Blender made a significant jump towards user friendliness and got a lot of love, I hope Godot will strive for that too (In fact Godot's user interface is fantastic, absolutely the best. Just the asset pipeline needs a bit of work).

Saying that artist just use proprietary software is not true as is not that that Linux (The most advanced and secure User OS ) is in a sorry state. Krita is one of the best, if not the best digital painting tool available right now, specifically to blend colors, as it has a unique algorithm to imitate proper color mixing and propagation. Blender is the most advanced 3D software you can get.

Large story made short., i know starting using open source tools can be tricky. The interface is not like what you used to use, the workflows are different, the formats are different. Nothing of that made them unusable, and people trying to explain that open formats have a priority is not a bad community.

[anunknowperson]

@yosoyfreeman

even need an extension to import them in blender.

You don't need an extension for this, the psd import works by default. I've already checked it recently.

Is really far from being universally supported and you even need an extension to import them in blender.

But it is well supported in most programs (including game engines) and this is a fact that I have already pointed out above.

[ghost]

@yosoyfreeman By "Actually good software" I meant "not Photoshop".

Have you actually used Clip Studio Paint to say Krita is the best? Have you seen blending in SAI? Blender is awesome, but have you ever used 3ds Max or Maya professionally?

I want to clarify, it wasn't my intention to attack open source software, but to share my own experiences trying to transition to it. It was off topic, shouldn't have mentioned it.

PSD never been a good idea to sharing things

It's not really related to this discussion, but PSD IS the way to share things most of the time, because you can open it anywhere, unlike .csp, .sai2, or Krita's format. It is also the format, that is natively supported by all painting software, and can be used instead of those .csp, .sai2, etc. EDIT: That means blending modes, clipping masks and all that stuff will look exactly the same everywhere. So if you want to share your source files with a wide audience of people all using different software, it's the way to go.

people trying to explain that open formats have a priority is not a bad community.

That's not how it went.

Lack of support for PSD wasn't the reason I chimed in. I actually was ready to ignore this inconvenience when I first discovered it. It was when I found the PR that I came into this discussion.

[CarpenterBlue]

I would like to note that this place is likely a secluded echo chamber since most people here are primarily programmers who use and make open-source tools and have unrealistic expectations of the artists. You don't want PHP programmer start coding in Javascript if they never seen the language before. As someone who has both perspectives I can assure you that having good pipeline is absolute king when working in a team. If you are looking for consensus onto this topic, ask users on Twitter if the team's artist would prefer sharing the PSD. The proposal will have then overwhelming support.

Furthermore 1) Retraining artist is costly and unlikely, most would rather quit than use different tool than the one they learned. 2) You don't want to retrain them anyway as the quality and more importantly speed of their art often times drops when you force them to use something else than what they are comfortable with.

For the game I am working on, my artist uses Clip Studio Paint and I am experiencing exactly the same problem OP is describing. After lot of experimenting we settled on workflow where my artist shares the the files to me in PSD format, the reason being that exporting assets is much easier from Photoshop through the Photoshop's asset generator feature. For now pipeline is Godot's biggest bottleneck at the moment and without it being properly artist friendly, the chances of Godot being more than just a indie game engine are slim.

Side note, I wouldn't use comparisons to 3D support of FBX as a an example, GLTF support in Godot is only really an option because Blender has such a strong position in the industry and it's not something 2D painting applications are even remotely close to.

[ghost]

retraining artist is costly and unlikely, most would rather quit than use different tool than the one they learned.

Retraining is totally possible, I switched from Photoshop to SAI, and then CSP replaced both. The question is why would you change your tool to an inferior one, when you already own the tool you like?

Well, soon programmers will replace artists with AI generators and everyone will be happy.

[Zireael07]

Retraining is possible, however in professional capacity, it is indeed costly and not very likely.

[yosoyfreeman]

Have you actually used Clip Studio Paint to say Krita is the best? Have you seen blending in SAI? Blender is awesome, but have you ever used 3ds Max or Maya professionally?

Yes, i did al my studies (The ones i was able to afford) with 3DS MAX, Maya and Substance and i personally found them over bloated tools with an archaic workflow, substance being the exception), that's why when i had the chance to work professionally i always used blender. I never found a situation where i wanted to do something and couldn't did it in blender, natively or with plugins.

That said, i recognize that 3DS max is a good choice for the minority of people working on extremely complex movie productions. But even that gap is more based on the proprietary plugins 3DS support more than it's native power. That without counting that Autodesk actively try to harm it's users with crazy monetization process and prices made blender the default option for freelance, indie, small and medium teams, and lately some large ones.

I want to clarify, it wasn't my intention to attack open source software, but to share my own experiences trying to transition to it. It was off topic, shouldn't have mentioned it.

Thanks for the clarification. It wasn't my intention to sound rude but to help understanding that a transition to a not only open source, but an open source centered engine comes with some intrinsic core mentality changes. There are things in Godot that are not as easy as other engines, while others are. But Godot engine is allowing lots of people who want control over the tools they use or that cannot afford the massive cost of basing your workflow in tools that, while being great, are privatively expensive. We need Godot to able to work first with the other open source format and tools to create a good ecosystem. I think nobody is going to say you that Things like PSD format or runtime substance texture are not good, but just not a priority.

PSD never been a good idea to sharing things

It's not really related to this discussion, but PSD IS the way to share things most of the time, because you can open it anywhere, unlike .csp, .sai2, or Krita's format. It is also the format, that is natively supported by all painting software, and can be used instead of those .csp, .sai2, etc. EDIT: That means blending modes, clipping masks and all that stuff will look exactly the same everywhere. So if you want to share your source files with a wide audience of people all using different software, it's the way to go.

I still don't relate to that but when using open alternatives you gain some things and you loose some things. I understand your situation as i been there before(Or i am, i didn't find an open audio alternative that i like, and is painful).

people trying to explain that open formats have a priority is not a bad community.

That's not how it went.

You probably right. I find hard to understand context many times.

Now, i think there must be a at least a way to improve this situation. I been doing some research and there is a plugin called exr-IO that is specifically designed to allow Photoshop to read and writer OpenEXR files for 3D applications like 3D engines. Could you test it? @Calinou said that seem to be plans for multi layered openEXR. Wouldn't that make for a proper workflow? I also found a clip studio response about this same thing, and ask user to open a request if they want support. https://ask.clip-studio.com/en-us/detail?id=79316

Have a nice day.

[anunknowperson]

@yosoyfreeman

PSD never been a good idea to sharing things to anything other than photoshop

I don't understand why you just take this expression as fact without making any argument for it. Although I've said several times here that .psd is the only convenient option for transferring images with layers from any program that has no open alternatives. All leading game engines support PSD, all leading CG software supports PSD. There is no better option for image transfer here.

...3DS MAX, Maya and Substance and i personally found them over bloated tools with an archaic workflow, substance being the exception), that's why when i had the chance to work professionally i always used blender.

On the contrary, I always thought that blender is a program for aliens with the most complicated interface ever. But this is a pointless discussion that has nothing to do with the topic of the proposal.

We need Godot to able to work first with the other open source format and tools to create a good ecosystem.

It seems to me that we should not sacrifice user-friendliness for the sake of some ideals. Moreover, I want to remind you that Godot is about to have Directx 12 (which itself is closed-source) support .

Now, i think there must be a at least a way to improve this situation. I been doing some research and there is a plugin called exr-IO that is specifically designed to allow Photoshop to read and writer OpenEXR files for 3D applications like 3D engines. Could you test it?

I am in a content creator support program for a very popular game that currently has >4000 artists. And I noticed that 80% of them use CS Paint for their work. The only export format with layers that CS Paint supports, like SAI, which I use is Psd. That's why I don't want to download additional software like Krita to transfer files there and add a huge number of meaningless steps to the develop pipeline.

Large story made short., i know starting using open source tools can be tricky. The interface is not like what you used to use, the workflows are different, the formats are different. Nothing of that made them unusable, and people trying to explain that open formats have a priority is not a bad community.

As I said, there are no open-source alternatives to PSD here. And PSD support is implemented in many open-source programs, such as Blender or Krita, and has been for over 10 years (in Blender). And they have no problem with it.

I still don't relate to that but when using open alternatives you gain some things and you loose some things. I understand your situation as i been there before(Or i am, i didn't find an open audio alternative that i like, and is painful).

There are no alternatives, the industry has recognized PSD as the leading format and it is used everywhere, including open-source.

[CarpenterBlue]

Just to illustrate the point here is list of some software exporting/importing or both PSD files: Krita Unity Affinity Designer Paintstorm Studio (Sadly not listed in features but it is possible and i can attest to that) Procreate (reply is from tech support) Artstudio Pro Gimp CorelDRAW Unreal Engine Blender Maya Clip Studio Paint I am too lazy to find source for the following: ToonBoom Harmony, Spine2D, TVPaint, OpenToonz, Moho, Live2D Of Course the whole Adobe Suite which is industry standard.

[anunknowperson]

@CarpenterBlue also 3ds max, SAI and many others...

[Calinou]

Moreover, I want to remind you that Godot is about to have closed-source Directx 12 support.

The Godot Direct3D 12 renderer code is open source. It should also be possible to run it on open source platforms using WINE and vkd3d-proton (not that you specially need to, since there's already a Vulkan backend).

There seems to be a common misconception about supporting proprietary standards in open source software, so I'll reiterate: you can implement support for proprietary formats with 100% open source code, even if there are software patents along the way. Otherwise, there's no way something like x264 could exist :slightly_smiling_face:

[anunknowperson]

https://github.com/godotengine/godot/pull/70315. It should also be possible to run it on open source platforms using WINE and vkd3d-proton (not that you specially need to, since there's already a Vulkan backend).

Sorry for the misunderstanding, I meant that DirectX 12 itself has a closed source code.

After all, the PSD import code is also open-source.

[NielsGx]

devs trying to understand artists workflow (impossible)

[Calinou]

@NielsGx I have to remind you that we have a Code of Conduct. Please stay constructive.

[unfa]

Open Source: Unreal Engine (https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Textures/Importing/)

I believe you are conflating proprietary source-available software with open-source. Unreal Engine isn't Free Software. Unfortunately a lot of articles online and people are making this mistake. More here.

I think stuff like PSD import support is a candidate for an extension. Many people won't ever use that. Regardless of PSD's proprietary nature, I don't think supporting files like XCF or KRA is reasonable either - these aren't distribution formats, are very complex and might never be needed by the majority of user base.

SVG is a bit of a different matter, as it's an open, lightweight and text-based format that is perfect for UI or other scalable texture assets. Being able o import it in Godot directly has the benefit of allowing rendering it at any resolution without the need to re-export from Inkscape (or other SVG-capable vector editing software) and needleslly bloating the game's assets. SVG happens to be an open format that is actually widely supported in proprietary software. not entirely unlike GLTF, though GLTF doesn't see such a wide adoption yet (sadly, since FBX is a mess).

Still - Inkscape has excellent tools to export individual named images from layers, canvases (pages) or individual objects, so the current single-layer import is perfectly adequate.

AFAIK there are add-ons for Photoshop to batch export layers so you can update your textures with one click. I worked with an artist at one studio who used this for creating assets for a 2.5D cinematic I made in Blender. Fist we started animating in SPine2D but it became clear isn't not what we need, and Blender will do much better. Still - I didn't want or expect PSD import inside Blender.

I think stuff like PSD or even XCF or KRA import should be handled by an extension. I won't ever use that, but I do see the appeal for people who have been working with proprietary software for years.

I can see FBX import making sense via 3rd party software, but I wouldn't want to have extensive, tool-specific import code directly in the Godot editor. I know there's a convenience feature to import .blend directly (in reality it calls Blender's executable to export to GLTF and uses that), and even though I work in Blender I don't know if I'll ever use that, because it seems like giving up a lot of control over how the export is done. I'm using the FBX Bundle add-on to batch export assets to GLTF (yeah, kinda of a misnomer) - I use that add-on with Unity with great success already. Would I want native Blender import in Unity? No :D At least the Blender import in Godot doesn't require a lot of complex code - it still could be moved to an extension in my opinion.

Such integration to specific external tools makes sense for extensions. You could have a Substance or Material Maker integration extensions for Godot, why not - but putting that complex code inside Godot's editor seems like needlessly complicating the editor to provide a bit more convenience to a part of the user base, while inconveniencing the rest.

And remember that any feature added to the core adds to maintenance burden and can affect other features, making the codebase stiffer. I think Godot's approach to be very, very considerate about this is paying off and should be kept up. it's also a great differentation from other popular engines and provides a unique appeal.

As for Godot being different from the proprietary engines in not leaning itself so well towards other proprietary tools - I think it's a worthy trade-off. Godot isn't for everyone. It can't and shouldn't try to be. it has an identity and a vision.

Still - I do believe extensions are the perfect tool to bridge that vision with whatever else studios or single devs might need that doesn't really fit the core.

If someone comes to Godot and wants everything to work like in Unreal Engine or Unity - maybe what they want is not Godot? Or maybe it'd be worth it for them to learn something new and adjust?

As a 3D/tech artist in game dev I wouldn't recommend my boss to start the next project on Godot 4. At least... not yet. it wouldn't work well and artists would have to re-learn so much. Not to mention programmers. We complain about Unity every day, but I am sure we'd complain about Godot as well- just for different reasons :D

But for single indie devs or small teams that are more open to change and adjusting their workflow? Absolutely.

Please don't take it as me dismissing the needs of artists who've been working in the industry and had to adjust to what is considered standard. I just think that a change in that standard is much needed and Godot is doing the right thing pushing it forward.

[Crystalwarrior]

I don't think there's any harm in importing .psd's. It's industry standard, widely used by artists and there's already options to import it to some extent. Gimp and Krita already support it as well!

In fact, Godot already supports .blend files, from the documentation:

.blend (Blender). This works by calling Blender to export to glTF in a transparent manner (requires Blender to be installed).

As far as the end user is concerned what matters is that it's easy. The goal is to ease up the artist workflow and make it much more convenient to work with the engine to implement layered assets, etc. - Visual Novels especially benefit.

A .psd importer would make it much easier to import the layers and position them in the engine where they should be using layer offsets, etc. and as @YYF233333 mentioned VNs heavily benefit from multi-layered sprites over static .png's, including due to optimization and file size concerns. Not only that, VNs benefit from targeting mobile platforms as well where such optimization matters even more.

I am working with the artists and I have the job of converting their work into the engine. We're still figuring out the most efficient workflow, but either way my artists can send me .psd files, I can import them into Gimp, then I use a Gimp plugin for batch layered exporting, and then I go into Godot to manually place the sprites and position them while checking back with Gimp where the Offset X and Y for each layer is... Yeah. If I could just tell Godot "open .psd NOW!!!" and it did that, that would save me about 5 steps of work, effort and time. And this is a solution that will benefit a huge majority of artists, too!!

So I can't in good faith accept that this is a feature that 'no one will use' as we're already seeing demand. Godot isn't just targetting programmers that are 'in the know', it's also an engine that pays attention to new users, indie devs, non-programmers, animators and artists, and its popularity + publicity is on the rise. The engine is constantly improving and there's this awesome sense of growth and I appreciate how everyone's voice actually matters :)