Closed oliv3r closed 10 months ago
Hmm, that definitely seems like something weird is going on. Did some quick tests with your provided .pcb3d
file and the issue also occurs if I just import the pcb.wrl
file. So the issue is either present in both, Blender's VRML importer and my code, or it's on the export side (i.e. KiCads VRML exporter), which I find somewhat more likely.
Can you share the KiCad pcb file you are exporting from? Also, what KiCad version are you using exactly?
Hmm, that definitely seems like something weird is going on. Did some quick tests with your provided
.pcb3d
file and the issue also occurs if I just import thepcb.wrl
file. So the issue is either present in both, Blender's VRML importer and my code, or it's on the export side (i.e. KiCads VRML exporter), which I find somewhat more likely.Can you share the KiCad pcb file you are exporting from? Also, what KiCad version are you using exactly?
I'm using the kibot docker container, ghcr.io/inti-cmnb/kicad7_auto_full:latest with the digest 20587c39f16b93ab90962f09add23886a92152f1a6e76a206461e881565d2c0f
Hi @oliv3r and @30350n !
I loaded the WRL using FreeCAD and it looks ok:
I'll suggest using stepUp to make the 3D model usable without any offset and/or rotation. Even when these values are available KiCad behaves very poorly honoring them when exporting to VRML and STEP formats.
Huh, odd! Guess it's an issue with Blender's VRML importer/my code after all then, will check that in the next few days ^^
I'll suggest using stepUp to make the 3D model usable without any offset and/or rotation.
I'd suggest free2ki :P
I'd rather not 'fix the wrl' as it's something I just got from the kicad library/lcsc library. That said, if we got a bug somewhere, then there's a bug somewhere that ought to be fixed?
Yep, there's probably a bug somewhere in the code that handles VRML rotations in Blender (as well as in my addon, probably because I more or less copied that code). The .wrl files are fine, nothing to fix about them.
I'd rather not 'fix the wrl' as it's something I just got from the kicad library/lcsc library.
I disagree with @30350n. If the WRL needs rotations and/or offsets it must be fixed. KiCad can't really handle it. You might be using a 3D model from KiCad libs, but you are tweaking its use, so you should rename it and adjust it for your needs. Otherwise you'll see problems in various places.
I'd rather not 'fix the wrl' as it's something I just got from the kicad library/lcsc library.
I disagree with @30350n. If the WRL needs rotations and/or offsets it must be fixed. KiCad can't really handle it. You might be using a 3D model from KiCad libs, but you are tweaking its use, so you should rename it and adjust it for your needs. Otherwise you'll see problems in various places.
I"m not really. I'm only rotating it a bit. Nothing that matches that weird diagonal offset even.
I'd rather not 'fix the wrl' as it's something I just got from the kicad library/lcsc library.
I disagree with @30350n. If the WRL needs rotations and/or offsets it must be fixed. KiCad can't really handle it. You might be using a 3D model from KiCad libs, but you are tweaking its use, so you should rename it and adjust it for your needs. Otherwise you'll see problems in various places.
Why would KiCad not be able to handle simple transformations? 🤔 I'm translating/rotating models in KiCad all the time and never had an issue with that. Also in this case the exported .wrl looks fine in FreeCad but not in Blender, so KiCad is obviously not the issue here.
Why would KiCad not be able to handle simple transformations? 🤔 I'm translating/rotating models in KiCad all the time and never had an issue with that. Also in this case the exported .wrl looks fine in FreeCad but not in Blender, so KiCad is obviously not the issue here.
In years using KiCad I found a lot of issues with this, until I started using stepUp to avoid offsets and rotations. No more problems.
Well I've only used it since 5.9 only so maybe it has only recently been working flawlessly 🤷 StepUp still seems like one big but though, pretty much unusable software imo.
Great so this seems to be a fundamental bug in Blender's Euler conversion code which got reported 2 years ago, but noone could be bothered to fix it.
@30350n ouch, well nice that you've found something about it!! That's step 1 :D
Cool, just tried the newest Alpha 4.1 build from https://builder.blender.org and it seems like they fixed it!
Amazing! Why does your render look better then mine? :p anyway, I'd be happy to close this issue, we can always re-open it if after 4.1 lands and this still isn't resolved.
@set-soft I suppose once 4.1 is released we can include it in 1.6.4 or 1.6.5?
@set-soft I suppose once 4.1 is released we can include it in 1.6.4 or 1.6.5?
Blender 4.1 will be stable on march, here is the schedule
I think this will be for 1.6.5.
Amazing! Why does your render look better then mine? :p
Lighting probably 😅 . I'm not really using anything special, really just HDRIs from polyhaven with their Gaffer Addon. To be exact, here I used this one ^^
anyway, I'd be happy to close this issue
sounds good!
@set-soft can we do this lightening plugin in kibot too? :D
Hi @oliv3r!
I don't know what exactly is needed. If you can try it and explain it step by step I could try it, what is needed? how it works?
You'd have to:
bpy.ops.gaffer.hdri_path_add(...)
in Blenderabandoned_factory_canteen_02
would for example download the hdri from https://dl.polyhaven.org/file/ph-assets/HDRIs/exr/4k/abandoned_factory_canteen_02_4k.exr
to the hdri folder.bpy.context.scene.gaf_props.hdri_handler_enabled = True
gaf_props.hdri_handler_enabled = <path to hdri file>
Depending on how 5. works exactly, 2. could maybe even be skipped.
- Install the Gaffer addon
I tried copying it to the scripts dir and then tried:
import addon_utils addon_utils.enable("Gaffer")
It fails:
Traceback (most recent call last):
File "/usr/bin/3.5/scripts/modules/addon_utils.py", line 369, in enable
mod.register()
File "/home/salvador/.config/blender/3.5/scripts/addons/Gaffer/__init__.py", line 710, in register
bpy.context.preferences.addons[__name__].preferences, bpy.context
KeyError: 'bpy_prop_collection[key]: key "Gaffer" not found'
Looks like the code is wrong and works only when already registered. Which may be true when using the GUI.
2. Create an hdri folder and add it via
bpy.ops.gaffer.hdri_path_add(...)
in Blender
This also fails, looks like this is interactive:
Traceback (most recent call last):
File "<blender_console>", line 1, in <module>
File "/usr/bin/3.5/scripts/modules/bpy/ops.py", line 111, in __call__
ret = _op_call(self.idname_py(), C_dict, kw, C_exec, C_undo)
TypeError: Calling operator "bpy.ops.gaffer.hdri_path_add" error, expected a string enum in ('INVOKE_DEFAULT', 'INVOKE_REGION_WIN', 'INVOKE_REGION_CHANNELS', 'INVOKE_REGION_PREVIEW', 'INVOKE_AREA', 'INVOKE_SCREEN', 'EXEC_DEFAULT', 'EXEC_REGION_WIN', 'EXEC_REGION_CHANNELS', 'EXEC_REGION_PREVIEW', 'EXEC_AREA', 'EXEC_SCREEN')
- Install the Gaffer addon
I tried copying it to the scripts dir and then tried:
import addon_utils addon_utils.enable("Gaffer")
It fails:
Traceback (most recent call last): File "/usr/bin/3.5/scripts/modules/addon_utils.py", line 369, in enable mod.register() File "/home/salvador/.config/blender/3.5/scripts/addons/Gaffer/__init__.py", line 710, in register bpy.context.preferences.addons[__name__].preferences, bpy.context KeyError: 'bpy_prop_collection[key]: key "Gaffer" not found'
Looks like the code is wrong and works only when already registered. Which may be true when using the GUI.
You have to use the name of the folder inside of the zip.
- Create an hdri folder and add it via
bpy.ops.gaffer.hdri_path_add(...)
in BlenderThis also fails, looks like this is interactive:
Traceback (most recent call last): File "<blender_console>", line 1, in <module> File "/usr/bin/3.5/scripts/modules/bpy/ops.py", line 111, in __call__ ret = _op_call(self.idname_py(), C_dict, kw, C_exec, C_undo) TypeError: Calling operator "bpy.ops.gaffer.hdri_path_add" error, expected a string enum in ('INVOKE_DEFAULT', 'INVOKE_REGION_WIN', 'INVOKE_REGION_CHANNELS', 'INVOKE_REGION_PREVIEW', 'INVOKE_AREA', 'INVOKE_SCREEN', 'EXEC_DEFAULT', 'EXEC_REGION_WIN', 'EXEC_REGION_CHANNELS', 'EXEC_REGION_PREVIEW', 'EXEC_AREA', 'EXEC_SCREEN')
bpy.ops.gaffer.hdri_path_add(directory=...)
should work.
bpy.ops.gaffer.hdri_path_add(directory=...)
should work.
Seems to work!
You have to use the name of the folder inside of the zip.
Hmmm ... nope, I didn't use the .zip and trying to rename the repo and use it fails.
Blender tries to register the add-on, but fails.
What did you use? 🤔
What did you use? 🤔
I cloned the repo, so the dir is named "Gaffer". Blender 3.5.1 finds it, but the mechanism used to "register" the preferences:
ui.update_category(bpy.context.preferences.addons[__name__].preferences, bpy.context)
From the register function fails when programmatically enabling the add-on. It works if I use the GUI, but this is impossible for the CI/CD. I'm enabling pcb2blender using the same code:
import addon_utils
addon_utils.enable("pcb2blender_importer")
How does it "fail" exactly?
How does it "fail" exactly?
Traceback (most recent call last):
File "/usr/bin/3.5/scripts/modules/addon_utils.py", line 369, in enable
mod.register()
File "/home/salvador/.config/blender/3.5/scripts/addons/Gaffer/__init__.py", line 710, in register
bpy.context.preferences.addons[__name__].preferences, bpy.context
KeyError: 'bpy_prop_collection[key]: key "Gaffer" not found'
I don't know much about the registration process, addon_utils.modules() finds the module and, as the traceback shows, the module is loaded and the register function called. Don't know what is missing ... looks like some registration in the bpy_prop_collection
Hmm, odd. Do you possibly get any errors before that? I could imagine it failing sooner (pre-registration), thus the addon preferences wouldn't be created correctly.
Hmm, odd. Do you possibly get any errors before that? I could imagine it failing sooner (pre-registration), thus the addon preferences wouldn't be created correctly.
Nope, this is the first error I get when I start from scratch
I'm not sure if this is an issue with pcb2blender, or if the issue is elsewhere, so apologies if I'm reporting it in the wrong location.
My workflow is currently using kibot's docker kicad 7 full image, which should have all the tools installed. The configuration snippet I use,
I made a PCB, which has a 3D file (from lcsc) but is abused ('its a through hole part, that I rendered rotated by 90 degrees to make it an edge connector). Also the lcsc part was offset, on the Z (-2.2) axis to compensate for the height, the X (-2.5) to get it from half the location to the correct location, and the Y (30.5) to move the pads in the correct spot. All in all, a few adjustment, but nothing major, and probably not relevant. (p.s. I realize that my story's coordinates don't match the offsets, but I'm sure you understand what I mean :p)
Opening the generated blender file, I see that the X and Z rotation are at -43.06 and 43.06. This is obviously wrong, which results in the following image.
Adjusting the X and Y rotations to -45 and +45, everything is perfect. So where do these rotations come from? Even though I'm abusing the wrong part, all modifications I made cause no problems in kicad itself. And the fact that both X and Z are incorrect by the same amount, and everything else is perfect, is surprising to me. I've attached the pcb3d (renamed to pcb3d.zip) but I'm not sure if all the needed information is in there. Who's responsible for mapping these transformations? Everything else renders really well.
breakout_hdmi-blender_export.pcb3d.zip