Setting individual origins seems very useful for those of us who like to import whole asset libraries into godot and saving the meshes to their own files.
Hey Michael - addon looks great! I've been looking for a tight solution for Blender -> Godot and this seems really promising. I wanted to add my two cents though on the origin point functionality: the addon needing to move the origin point to the center of geometry to generate the collision shapes is less than ideal. In many cases (like with these Kenney assets shown in this video), the origin is intentionally placed such that the asset will snap to the floor, or such that assets can snap together perfectly (for example, if you're making a pack of modular building pieces). Moving the origin to the geometry's center of mass makes it much more difficult and less scalable to work with assets. Maybe there's a way to temporarily move the origin to create the collision shape and then set it back? I'd defer to you on the implementation. But wanted to voice this as it's a pretty essential part of the common workflow in the games industry.
I hear you entirely on this one. I have already been prototyping a second way of doing collisions, but the problem is that it effectively it requires sending more info from blender to Godot - both the bounding box origin center position and size. This would basically break the current API (and all past versions). I am considering doing this eventually. Aside from the logistics of the add-on API, it is possible to get this info from the add-on - basically the addon sets the object's origin to the center of the bounding box, captures that position, rolls back the origin change, and then send that info to Godot. On the Godot side, the collision shape itself can have the object's BB origin (offset relative to the actual origin, since it will be parented to a Body3D, i.e. the feet example) and it all works great. The problem is just time and effort to get that code in there. The collision solution would need a pretty big overhaul to make this happen.
@@michaeljburt I appreciate that you're continuing to build on the addon! And glad to hear you were already thinking about this. Godot's 3D workflow is a bit maddening in comparison to other 3D engines so tools like yours end up being live savers. Looking forward to seeing progress over time :)
14:00 I had the same issues "cpp:345 - Condition !is_inside_tree() etc." get introduced to my import plugin going from 4.2 to 4.3. It was from accessing global_position of a node while it was outside of the tree. Funny enough I wasn't even using the var, just a leftover debug print causing me grief Since the scene is not in the tree when you are not currently editing it, maybe that will solve the needing scene open issue, though it's that not that big of a deal IMO
Interesting. Thanks for your comment! Yeah this one has caught me a few times. I am not sure if I totally understand why some properties are accessible outside the tree and some not.
@@michaeljburt "World3D space (global) Transform3D of this node." this the description of global_transform from docs, so I'm guessing it can't access the World3D. I've been getting errors from other scripts when trying to get_tree() from outside the tree. So it probably comes to that, can't access parts of the tree when the node isn't inside. I was able to reconstruct my scenes accurately using just the local position, so it's probably a quick fix if your worried about. Anyway, cool plugin man! Interesting to see the different work flows
Is there any way we can convert blenders shaders so it van be used in godot? Like some scrolling lava textures would be so nice to make in ble der u know material maker can convert it to a godot shader but idk about blender
when using blender 4.2 I had a similar experience with the shaded viewport slowing down.for me at this usually happens the when i open blender and switch to shaded view for the first time.after that it kinda speeds up on its own again.IDK why its like that.But i switched back to 4.1 for these minor issues.Things you don't notice till u look for them
Right. Well good to know it's not just me. It's funny it didn't happen during the video, but I believe you're right. It happens when switching for the first time and I must have already done it
@@michaeljburt maybe it's the code behind the software.i feel like it's supposed to be a way of optimizing blender, like it cache's existing materials the first time for future reference in that session . But it might also be a bug for certain users cause most blender tutorials I've seen don't seem to have this problem
Setting individual origins seems very useful for those of us who like to import whole asset libraries into godot and saving the meshes to their own files.
Hey Michael - addon looks great! I've been looking for a tight solution for Blender -> Godot and this seems really promising. I wanted to add my two cents though on the origin point functionality: the addon needing to move the origin point to the center of geometry to generate the collision shapes is less than ideal. In many cases (like with these Kenney assets shown in this video), the origin is intentionally placed such that the asset will snap to the floor, or such that assets can snap together perfectly (for example, if you're making a pack of modular building pieces).
Moving the origin to the geometry's center of mass makes it much more difficult and less scalable to work with assets. Maybe there's a way to temporarily move the origin to create the collision shape and then set it back? I'd defer to you on the implementation. But wanted to voice this as it's a pretty essential part of the common workflow in the games industry.
I hear you entirely on this one. I have already been prototyping a second way of doing collisions, but the problem is that it effectively it requires sending more info from blender to Godot - both the bounding box origin center position and size. This would basically break the current API (and all past versions). I am considering doing this eventually.
Aside from the logistics of the add-on API, it is possible to get this info from the add-on - basically the addon sets the object's origin to the center of the bounding box, captures that position, rolls back the origin change, and then send that info to Godot.
On the Godot side, the collision shape itself can have the object's BB origin (offset relative to the actual origin, since it will be parented to a Body3D, i.e. the feet example) and it all works great.
The problem is just time and effort to get that code in there. The collision solution would need a pretty big overhaul to make this happen.
@@michaeljburt I appreciate that you're continuing to build on the addon! And glad to hear you were already thinking about this. Godot's 3D workflow is a bit maddening in comparison to other 3D engines so tools like yours end up being live savers. Looking forward to seeing progress over time :)
hmmm sounds so useful
14:00 I had the same issues "cpp:345 - Condition !is_inside_tree() etc." get introduced to my import plugin going from 4.2 to 4.3. It was from accessing global_position of a node while it was outside of the tree. Funny enough I wasn't even using the var, just a leftover debug print causing me grief
Since the scene is not in the tree when you are not currently editing it, maybe that will solve the needing scene open issue, though it's that not that big of a deal IMO
Interesting. Thanks for your comment! Yeah this one has caught me a few times. I am not sure if I totally understand why some properties are accessible outside the tree and some not.
@@michaeljburt "World3D space (global) Transform3D of this node." this the description of global_transform from docs, so I'm guessing it can't access the World3D. I've been getting errors from other scripts when trying to get_tree() from outside the tree. So it probably comes to that, can't access parts of the tree when the node isn't inside.
I was able to reconstruct my scenes accurately using just the local position, so it's probably a quick fix if your worried about.
Anyway, cool plugin man! Interesting to see the different work flows
Is there any way we can convert blenders shaders so it van be used in godot? Like some scrolling lava textures would be so nice to make in ble der u know material maker can convert it to a godot shader but idk about blender
when using blender 4.2 I had a similar experience with the shaded viewport slowing down.for me at this usually happens the when i open blender and switch to shaded view for the first time.after that it kinda speeds up on its own again.IDK why its like that.But i switched back to 4.1 for these minor issues.Things you don't notice till u look for them
Right. Well good to know it's not just me. It's funny it didn't happen during the video, but I believe you're right. It happens when switching for the first time and I must have already done it
@@michaeljburt maybe it's the code behind the software.i feel like it's supposed to be a way of optimizing blender, like it cache's existing materials the first time for future reference in that session . But it might also be a bug for certain users cause most blender tutorials I've seen don't seem to have this problem