Failure to import .blend with Blender package from Arch Linux
#76338
Comments
|
Some additional logging (using the Overgrown Subway Scene project) and a build of |
|
Core add-ons got missed, oops. This was fixed a few days ago for Fedora 38, but it had not been fixed in Fedora 37 before I upgraded. This is happening because godot is expecting a plugin like |
|
As @lyuma asked for it in another ticket, here's a minimal Godot project which reproduces the problem. Apologies for the file size (25MB zipped, around 80MB unzipped), the bug occurred for me for this particular mesh. Everybody should be able to grab the project here: https://drive.google.com/file/d/1x0qtp9gOUEhcNYNqRqXPATD7WDu2dPmC/view?usp=sharing This is what the project looks like for me:
There are several issues with this minimal project for me:
My Setup:
I do have multiple blender installations floating around on my machine, is that a problem? I specified the 3.5.1 version in the Godot settings. I had to disable and re-enable the "Blender" import plugin to make Godot recognize the |
|
Does the library blend import if you rename it to something w/o underscore? |
|
@Zireael07 no, haven't tried that. Would be really funny if that were the case. I can try it when I get home after work today. |
|
@Zireael07 I've tried renaming the file by removing the underscore, unfortunately the behavior is still the same. So that wasn't the cause. |
|
I'm getting this error in Godot 4.1.1 with Blender 3.6.0 It seemed to be working before, although I don't know if that was because I was on Godot 4.1 or an earlier version of Blender, or something else entirely. |
|
Pretty much the same issue here, the error message looks slightly different for me: Godot version v4.2.dev.custom_build [https://github.com/godotengine/godot/commit/75f9c97deaa8378477441e07ea1782ecab6d2eca] Godot v4.2.dev (75f9c97) - Arch Linux #1 SMP PREEMPT_DYNAMIC Mon, 24 Jul 2023 20:19:38 +0000 - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 5500 XT () - AMD Ryzen 7 2700X Eight-Core Processor (16 Threads) |
|
Testing this, I was previously using Blender through pacman (v3.6.0), but the Blender flatpak (v3.6.1) seems to not have this issue. I wonder if this is because of the slightly newer version or because of the packaging format. (flatpak vs system package manager) @nano13 If you want to solve this issue now and don't mind using flatpak, install the org.blender.Blender flatpak and set the "Blender 3 Path" in Godot's editor settings to |
|
Arch linux blender package currently in testing (3.6.1-1) doesn't have this issue anymore. Earlier version had the |
|
On blender 3.6.2-1 on ArchLinux (from This happens in a loop, and each re-import opens a new external editor instance, filling the screen with windows. |
akien-mga
changed the title
.blend with Blender 3.5.blend with Blender package from Arch Linux
|
See #79881. So far all reports point to the Blender package from Arch Linux being problematic. The workaround is to download Blender from blender.org, which works fine. |
|
Just mentioning - my original report was from Fedora 37. Unsure whether these share the RPM source somehow though, or whether this issue was repurposed. |
|
My bad, I overlooked this. I guess this ticket is now being repurposed :P The problem with Arch is likely similar to the problem Fedora 37 briefly had, where they were not including all core addons. Arch and Fedora don't share package sources but it might be that a missing build dependency or build option leads to not compiling all Blender addons we need (here notably glTF export stuff I suppose). |
FWIW, the GLTF plugin is installed and I can manually export GLTF from the blender UI. I can also export with a minimized version of the script Godot uses: However, the following fails: The docs do list |
|
Aha! Found this in https://projects.blender.org/blender/blender-addons: commit 96a73cb664bca687b7ea2e464c4d08f8082d5012
Author: Julien Duroure <julien.duroure@gmail.com>
Date: Tue May 23 16:12:03 2023 +0200
glTF exporter: keep backward compatibility for export options
diff --git a/io_scene_gltf2/__init__.py b/io_scene_gltf2/__init__.py
index 0d50f4ad..a469c81e 100755
--- a/io_scene_gltf2/__init__.py
+++ b/io_scene_gltf2/__init__.py
@@ -4,7 +4,7 @@
bl_info = {
'name': 'glTF 2.0 format',
'author': 'Julien Duroure, Scurest, Norbert Nopper, Urs Hanselmann, Moritz Becher, Benjamin Schmithüsen, Jim Eckerlein, and many external contributors',
- "version": (3, 6, 21),
+ "version": (3, 6, 22),
'blender': (3, 5, 0),
'location': 'File > Import-Export',
'description': 'Import-Export as glTF 2.0',
@@ -601,6 +601,19 @@ class ExportGLTF2_Base(ConvertGLTF2_Base):
default=False
)
+ # This parameter is only here for backward compatibility, as this option is removed in 3.6
+ # This option does nothing, and is not displayed in UI
+ # What you are looking for is probably "export_animation_mode"
+ export_nla_strips: BoolProperty(
+ name='Group by NLA Track',
+ description=(
+ "When on, multiple actions become part of the same glTF animation if "
+ "they're pushed onto NLA tracks with the same name. "
+ "When off, all the currently assigned actions become one glTF animation"
+ ),
+ default=True
+ )
+
will_save_settings: BoolProperty(
name='Remember Export Settings',
description='Store glTF export settings in the Blender project',The parameter was removed recently, but re-added in even more recent addon versions for backwards compat. |
|
In line with @ShawkMusic's suggestion, a simple workaround on Arch Linux is to download Blender 3.6.2 directly from their website, extract the "tar.xz" file with |
Regardless, Godot should not try to import these in a infinite loop. EDIT: This issue is not related to |
|
One more insight: the model that didn't import for me in Godot is using the Blender Asset Library feature. Could this be the cause? |
|
The comment in #81194 explains more, but to clarify, this is not specific to ArchLinux. This is specific to a certain range of blender versions that removed the More recent versions add that back for "backwards compatibility", but the re-added parameter does nothing (so it's not really backwards compatible).
If you see |
|
Godot v4.1.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 31.0.15.3667) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads) |
Fixes godotengine#76338. Blender 3.6 imports fail with: ``` TypeError: Converting py args to operator properties: : keyword "export_nla_strips" unrecognized ``` The `export_nla_strips` flag was removed and replaced with `export_animation_mode`. In 3.6.0-3.6.21, this option does not exist at all and causes the failure above. In 3.6.22, this option was re-added, but does nothing. See https://projects.blender.org/blender/blender-addons/commit/96a73cb664bca687b7ea2e464c4d08f8082d5012. We now need to check the blender version to determine what flags to use. This adds an additional shell command before every import. We might consider caching the version, but we'd have to invalidate the cache if the blender version or path changes. As an aside, the "group animations" setting in Godot does the opposite of what I'd expect. When `group_tracks=true`, each animation is exported individually. When `group_tracks=false`, all animations are exported as a single track. This seems backwards, but I've kept the 3.6 behavior consistent with 3.5. From https://docs.blender.org/api/3.6/bpy.ops.export_scene.html: > ACTIONS Actions – Export actions (actives and on NLA tracks) as separate animations. > ACTIVE_ACTIONS Active actions merged – All the currently assigned actions become one glTF animation. Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
|
I'm having the same problem. Godot version= 4.1.2-1 The logs are these, repeating in loop: |
|
I was able to get it working with Godot
Not a real solution though. This new blender's version keeps crashing Godot. |
|
@akien-mga any chance this can get backported to 4.1? Are there plans for another 4.1 patch before 4.2 comes out? |
|
Yes, that's what the |
|
Ah, sorry! I saw the 4.2 milestone on the issue and assumed it was just 4.2. Thanks! |
Fixes godotengine#76338. Blender 3.6 imports fail with: ``` TypeError: Converting py args to operator properties: : keyword "export_nla_strips" unrecognized ``` The `export_nla_strips` flag was removed and replaced with `export_animation_mode`. In 3.6.0-3.6.21, this option does not exist at all and causes the failure above. In 3.6.22, this option was re-added, but does nothing. See https://projects.blender.org/blender/blender-addons/commit/96a73cb664bca687b7ea2e464c4d08f8082d5012. We now need to check the blender version to determine what flags to use. This adds an additional shell command before every import. We might consider caching the version, but we'd have to invalidate the cache if the blender version or path changes. As an aside, the "group animations" setting in Godot does the opposite of what I'd expect. When `group_tracks=true`, each animation is exported individually. When `group_tracks=false`, all animations are exported as a single track. This seems backwards, but I've kept the 3.6 behavior consistent with 3.5. From https://docs.blender.org/api/3.6/bpy.ops.export_scene.html: > ACTIONS Actions – Export actions (actives and on NLA tracks) as separate animations. > ACTIVE_ACTIONS Active actions merged – All the currently assigned actions become one glTF animation. Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
Fixes godotengine#76338. Blender 3.6 imports fail with: ``` TypeError: Converting py args to operator properties: : keyword "export_nla_strips" unrecognized ``` The `export_nla_strips` flag was removed and replaced with `export_animation_mode`. In 3.6.0-3.6.21, this option does not exist at all and causes the failure above. In 3.6.22, this option was re-added, but does nothing. See https://projects.blender.org/blender/blender-addons/commit/96a73cb664bca687b7ea2e464c4d08f8082d5012. We now need to check the blender version to determine what flags to use. This adds an additional shell command before every import. We might consider caching the version, but we'd have to invalidate the cache if the blender version or path changes. As an aside, the "group animations" setting in Godot does the opposite of what I'd expect. When `group_tracks=true`, each animation is exported individually. When `group_tracks=false`, all animations are exported as a single track. This seems backwards, but I've kept the 3.6 behavior consistent with 3.5. From https://docs.blender.org/api/3.6/bpy.ops.export_scene.html: > ACTIONS Actions – Export actions (actives and on NLA tracks) as separate animations. > ACTIVE_ACTIONS Active actions merged – All the currently assigned actions become one glTF animation. Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com> (cherry picked from commit 7e64c6c)
Godot version
4.0.2-stable
System information
Fedora 37
Issue description
This is related to #67275. I noticed my
.blendimports failing after my recent upgrade from Blender 3.3.1 to 3.5.0.Blender 3.5 hasn't yet been discussed in that issue, and so @lyuma suggested this may be a different problem to the ones we've experienced between 3.0 & 3.4.
I have also confirmed this isn't a problem with Blender 3.4.1.
As is the case with #67275, the import keeps happening on a loop, which prevents me from working because the import modal repeatedly pops up:
Aside: it'd be useful to be able to debug this from the production editor build, perhaps by dumping Blender stderr into
.godot/somewhere.Steps to reproduce
.blendfile to the projectYou'll need to keep mashing Ctrl+Q to get the editor to quit after this.
Minimal reproduction project
src.zip
The text was updated successfully, but these errors were encountered: