reproduce file:

monster.blend.zip

In the exported levels all nodes have a Transform that contains a rotation value of (-90,0,0).

This becomes and issue if you want to animate an object to rotate around the game's z axis due to gimbal lock.

Instead of setting a rotation the coordinates in the mesh data should be exchanged (x becomes z, z becomes-x, if I am not mistaken).

• Version : master / 88a8803

When exporting a model with a lot of control bones (i.e. an IK setup), it is desirable to exclude such bones from being included in the exported result.

Better Collada has such an option which is quite useful in such a scenario, so it'd be good if we can implement the same feature in Blender exporter too.

Also, please consider this issue if you are going to follow the functionality in Better Collada exporter, godotengine/collada-exporter#60, as it's limiting its usability to some degree.

• Version : master / 88a8803

Currently, it seems that the exporter does not import animations even when the relevant setting is enabled in the associated import settings.

Possibly it could be simply because the feature hasn't been implemented yet, but I'm reporting it to track progress.

Blender automatically flips the normals of objects with negative scale. Godot doesn't, resulting in a difference in appearance between blender and godot that is hard to find the source of the problem. This can be handled two ways:

• Only positive scales supported
• If an object has a scale, export it with an inverted mesh (May result in otherwise identical objects not being able to share a mesh).

I think it should be fine to leave this as a "keep your scales positive" so long as a warning is raised when an object with negative scale is present.

I'm not too sure if it's an issue with the exporter or Godot itself. But when I change import settings for *.escn to store meshes as separate files, a file with a blank name ('.mesh') is generated after the importing process, making Godot crash when trying to open the modified .escn file.

Current support for IK (#63) is implemented by calling blender API bake_action to baking constraint to actions, however, blender bake_action inner calls frame_set() for every frame. So call bake_action for every object has constraints is a waste of performance,

there are two possible way to solve it:

1. for blender > 2.79.1, there exist API bake_action_objects to bake multiple objects at once
2. simple use the approach of BetterCollada addon, we iteratively call frame_set() to export all the animation, give up the current implementation of evaluating fcurves

Hi,

I have an fbx that I open in blender - it looks fine and the animation (of a woman standing idle) plays fine. When I open the escn file in godot created by this exporter, it all appears to load (the layers and animationplayer are there) but the meshes are invisible. The animation seems to play but I can't see the character. The meshes (body, shoes, clothes, etc) are visible in the inspector but not in the editor window. Any suggestions appreciated!

Here's the fbx file (~36mb)
https://drive.google.com/open?id=1-2tAMi7XbvjBJqJDYc8mPVgJZnRXR1B2

we are using pep8 for static analysis and it is now being renamed to pycodestyle.However we need to make sure the new pycodestyle package can be found across all the popular platform (we may have developers work in different environment) before we simply rename it.

hello,
I'm trying to export a simple hierarchy of objects with simple animation and the result in godot is not conserving all needed.
it consist of wireframe meshes used as physic collision to which visible mesh are parented, with simple animation (rotation) on one child physic mesh
hierarchy like this :

BaseCollisionMesh (set to wireframe)(active rigidbody)
-BaseMesh
-ArmCollisionMesh (animated) (set to wireframe)(active rigidbody)
--ArmMesh

result in godot exported with SCENE_ANIMATION is giving

BaseCollisionMesh (rigidbody)
-BaseCollision (collisionshape)
-BaseMesh (mesh)
-ArmCollisionMesh (collisionshape)
-ArmMesh (mesh) (location reset to 0.0.0)

and no animation

if the collision meshes are set to normal render, the animation is exported, a "better" hierarchy too, but still no rigidbody and correct parenting ...

here is the simple test I made to play with :
blender-export-phystest.zip

• Version : master / 88a8803

Currently, it seems that the exporter ignores shape keys (or 'blend shapes') when it exports a mesh. But they are quite commonly used for animating facial expressions, or lip syncing(phonemes) in a 3d character, so it'd be good if we could support this feature.

I wish this issue could get priority even though it might look like a minor feature compared to others.

The reason is, we have no viable method of using shape key based facial expressions or lip syncing animations in Godot at this moment, which could be quite a significant limitation since two most widely used open source character models - namely, Manuel Bastioni Lab and Make Human - all support those features through shape keys.

While it is possible to workaround other limitations of Blender exporter by mixing the result from different exporters, like it's the case with materials for example, there's no other exporters that support shape keys reliably with a rigged mesh for now.

There's an issue report for Better Collada (godotengine/collada-exporter#41) which was created in 2016, but apparently that project looks to be made obsolete in favor of Blender exporter or GLTF.

So, I hope this could get resolved before more people begin to use Godot for 3D projects, because facial expressions or phonemes could be quite important features for such type of games.

Hi,

I'm providing a sample file that includes armature animation+shape keys animation+nla. The armature animation gets exported correctly but not the other two.

sample.zip

The README for this plugin contains some steps for installation. However, the documentation leaves out any concrete usage instructions. Please add one or more usage examples, such as:

• exporting a triangulated geometry with textures
• exporting a mesh with animations

When exporting with Exclude Control Bones option, other deforming bones which were parented to one of the control bones removed by the option will get orphaned, potentially resulting in animation problems.

Better Collada, on the other hand, seems to handle such a situation by connecting such orphaned bones according to their hierarchical positions.

Again, you can test this feature with my model which I shared for another issue:

• https://github.com/mysticfall/AlleyCat/blob/master/Design/Blender/Characters/Human/Female/Body.blend

The bone hierarchy for the neck head area is as follows:

• head -> struct_hd -> neck -> struct_nk -> spine03

And the two bones whose name starts with struct- are controlling bones, thus get removed when being exported with the above mentioned option, leaving the former two orphaned. So, ideally it can be automatically connected again as:

• head -> neck -> spine03

After exporting the model, you can find those bones at the very end of the bones array.

LICENSE.txt contains the GPL 3 but the README says "GNU General Public License, version 2 or later"

First up, this is fantastic work that you guys are doing, much appreciated!

Was wondering if it is possible to get an option to export a mesh from Blender directly to a .mesh file (with uv's, vertex colors and poly selections). It would be a very useful option in several scenarios. I am making a game that uses large sets of .mesh files to procedurally populate my levels. Currently I export to obj and convert this manually to a .mesh file from Godot. Being able to do this directly from Blender would be a massive time saver.

Also, if you are doing a low poly game and texturing via vertex colors all you would need is the .mesh file straight from Blender into Godot, without worrying about any conversion of an .escn file. This can reduce a lot of clutter in a project.

Additionally, when using a texturing workflow between Blender-Substance Painter-Godot, it would be nice to just export a .mesh and obj file from Blender. Then I can texture in Painter using the obj file, export my pbr maps directly into my godot file structure. Then it is just a matter of adding in the .mesh file direct from Blender and I have all I need for a static model. Once again without having an intermediary file format to clutter up my project folder structure (which is important when you start getting hundreds of models piling up in your project).

The .escn approach you are currently using is perfect for exporting large scenes and animated models from Blender, but for single static models (which usually comprises the majority of a game), direct .mesh export would be wonderful!

I freshly downloaded the new Blender 2.79 RC and then installed the godot exporter from user preferences menu. But it won't show up in the addons list, can somebody reproduce this behavior ?

Nothing shows in the console, window just hangs and I have to force close Blender.
Using all the default settings and exporting the default blender scene (cube, light, camera).

It seems that IK is not implemented yet then we can't use rigify addon.

Test IK.zip

The PEP 8 style should be applied to the Blender exporter code.

Tools

• autopep8
• PEP8 Speaks (automatically scans pull requests for code style violations)

Estoy revisando el codigo pero no entiendo mucho cómo es el diseño de este programa, ni como funciona.Alguien tiene un diagrama de flujo de esté programa,tengo poco tiempo con python,pero seria una buena practica tratar de ayudar a desarrollar esté software.

I am reviewing the code but I do not understand much how is the design of this program, or how it works. Someone has a flow diagram of this program, I have little time with python, but it would be a good practice to try to help develop this software.

Although, now exporting blendshapes itself works great after recent changes, the resulting file(*.escn) seems to be excessively large in size, compared to its original Blender source.

For example, my model contains about 80 shapekeys which is stored as a 20mb Blender file. However, when I export it using Godot Blender Exporter, it becomes over 220mb in size and it seems to be causing various issues like visual glitches or increased loading time.

I wonder if there's any way to mitigate this problem, either by changing the Blender source file, or change the way its exported by the addon code.

In the test-case blends, the animations are 100 frames at 24FPS (~4 seconds). Inside Godot, they are ~3.5 seconds. It looks like this is corrected (line 38 of animations.py), but it seems something non-obvious is happening there.

the blender object's properties (e.g. transform) can be affected by animation. If a user build a scene which has an animation, but forget to set the frame to zero before exporting, it would generate a unwanted result. So maybe it should have a bpy.scene.frame_set(0) before the exporting procedure starts.

This is the player from the TPS demo. Fails on export.
It contains multiple actions which should be exported as separate animations in the escn file. Works fine with BetterCollada.

player.zip

the current exported ArrayMesh resource use the format ( "array", "morph_array"). I find it is tagged as 'old format' in godot: mesh.cpp. so is it need to use the new format (the "array_data" one), in case the old format deprecated in the future？

So it will continue building and comparing even if there are errors during export. This makes debugging hard.

This stems from the fact that blender closes with exit code 0 even if the script fails. If I remember correctly, this can be solved by calling exit(1) from inside the script, though we also need to ensure the python traceback is presented to the developer.

As exporter has more and more support on rigged mesh, the existed mesh exporting functions have a small problem: there are several flags and mappings passing across functions, making the code less pretty, and even sometimes it is not an easy thing to passing flags.

I plan to do these several things:

• add a class to store the flags and mappings, make them easy to access
• have a better serialization of surface ( currently it use string concat, maybe consider to use structures.Array
• there is a place can cause a Exception (vertex in rigged mesh with no bone weights), but currently it gives too less information about in which mesh, which vertex has no bone weights

( this issue is kind of a keeping a note for myself

The exporter has the options to not export a certain kind of objects. In the current implementation, nothing of the unexported node will be kept in the output escn file. But in some circumstance, it may have a problem.

For example, exporting a blender scene with structure Mesh1 -> Armature -> Mesh2, if Armature node is configured as not exported, the result escn would have the structure Mesh1 -> Mesh2. The problem is the Armature object may have a transform, removing the Armature object lose this transform and consequently changed the Mesh2's world space position.

For this problem, there are two solutions.

1. we do nothing, so the outputted escn node is a one-one mapping of blender object, with same transform, but as the tree structure may change, the world space position of each node may be different.
2. we multiple the transform of unexported node down to its exported children nodes, then whole scene would be visually the same in Blender and Godot.

it's a question about which is more important for user, the consistency of each node or the consistency of the whole scene ?

Hi! I'm interested in working on this addon, as I have done Blender addons in the past. So I was wondering if there are any official plans for this, how it should work etc.
But first I would like to refactor and document it, if that's OK, as right now it's quite cryptic and it's difficult to understand what's going on. Also, what are the plans about the .escn filetype? Is there any documentation about its structure?

IMO the test files and the .escn writing part doesn't need to be GPL licensed.

MIT/X11 is a GPL compatible license:
http://www.gnu.org/licenses/license-list.en.html#X11License

which means that MIT-licensed code can still be included with a GPL-licensed blender add-on, see e.g.:
https://git.blender.org/gitweb/gitweb.cgi/blender-addons.git/blob/HEAD:/io_import_dxf/dxfgrabber/__init__.py

For things like tilemaps, it is useful to export multiple scenes from a single blend source file. It would be nice to support this.

One way to implement this is that each parenting-hierarchy is exported as a different scene file

However, there are a couple issues that need to be worked through:

• Is each exported parent-tree centered to world origin? (I think yes)
• How are exported files named?
• How should data shared between files handled (eg materials)

Also to consider is that this makes integration with some build-systems hard, as you cannot know the output files, or how many of them there are until the export is completed. (For example, tup could not deal with this).

In current master, physics properties are handled through a physics material. This produces a load of warnings on importing escn files.

I've got a simple blender model that looks like this:

Exporting with the better collada exporter results in a similar-looking model in godot:

When I export to .escn, however, it looks like the sides of the ship are "caved-in":

I'm new to godot and blender, so it could be that I designed my model poorly, but since the collada exporter seems to get it "right", it could be a bug in the .escn exporter.

blender_file.zip

After seeing a post on the godot facebook group that blender scenes with cycles materials could be exported to godot with this plugin I immediately gave it a try with a scene from a tutorial series I'm doing. The materials are pretty complex. Of course for in game they need to be baked, but this was just for testing purposes. The Objects, geometry and lights are coming through, but not the cycles materials. This would be really nice if they did.

I've made a simpeler scene with very basic cycles materials on a few suzannes. One with just a diffuse color, red, one with just a checker image texture, groenSchaakbord.png, and one with principled shader using the same texture and Metallic value 1. I don't see any materials in Godot again.

Here is the second test scene:
github issue blender godot export import.zip

• Version : master / 88a8803

I tried to import a rigged character to Godot using godot-blender-exporter, but it made some parts of the mesh deformed as shown below:

The source Blender file that caused the issue can be found in the below link:

• https://github.com/mysticfall/AlleyCat/blob/master/Design/Blender/Characters/Human/Female/Body.blend

In godot the model not has texture when importing from Blender, this can be make manually, but have an option to auto import the image texture would be great.

Example blend:
zero_vertex.zip

This is understandable because there are no tangents to an infinitely small point, however the exporter should not fail on the case, or should fail more gracefully. Wrapping a try-except around the calc_tangents() call is the simple fix, but I'm not sure in what other cases calc_tangents() fails. I'd like to do some more research before committing that as a fix.

Currently the only option I see to make materials work, is by creating an eqivalent in godot and using the same name. Or using blender render.
But since the principle shader is verry similar it could be used, to create a material in the escn which than gets imported to godot.

Hi, I have a sample animation that plays fine in blender but when I use the godot exporter (latest code) the following happens:

1. No escn file is created
2. The animation in blender is now missing
3. There's nothing on the commandline to suggest anything is amiss.

[INFO]: Exporting scene: Scene
[INFO]: Exporting 4 objects
[INFO]: Exporting Blender Object: Hips
[INFO]: Exporting Blender Object: Poly_HF_mixamo_export

I have attached the file that I import into blender. Happy to help debug if I can.

PS. I'm really impressed with this project!

HF_low_poly_100frames.fbx.zip

This is the environment from the TPS demo:

demolevel.zip

No matter what I test, no geometry is exported, only the lights. Works fine with BetterCollada.

Attaching project, seems to work fine with Better Collada (Option: Export animations but not multiple actions)
IK-GRABTEXT.zip

How it should look:

If I am not mistaken there is currently no way to create physics objects in blender that would be exported to areas, and there doesn't seem to be a good workaround.

Currently the exporter produces things like:
Vector3Array(-6.572353328238023e-08, 0.0, -1.0, -1.0, -0.4999999701976776, ...

Which can obviously be better represented as:
Vector3Array(0.0, 0.0, -1.0, -1.0, -0.5, ...

Fixing this will decrease filesize and may also solve some cross-platform differences in the reference-exports.

Tested with 22dca94

I'm using "blender render".

Blender file: color.zip

When exporting a mesh to an .escn file, material names are not preserved and show up as empty fields after being imported to Godot.

Even though the addon currently does not properly export material settings, preserving material names would fascilliate the workflow significantly, since it's usually the case to externalize materials to *.material or *.tres when importing an *.escn file into Godot then repeat the exporting process as necessary.

Without such a feature, a user has to always open each meshes in Godot and manually input material names again (which is not an easy task when there are several material slots because there's no way to tell which slot is for which part of the mesh without memorizing the order).

Have an auto import texture feature would be great.

Testing and I get:

  File "/usr/share/blender/scripts/addons/io_scene_godot/structures.py", line 69, in add_internal_resource
    raise Exception("Attempting to add object to file twice")

Should this be an error? I would expect to return the same index if this is the case.

there is a procedure to create a hash for every vertex and check for duplication before serialize them (it creates some trouble for morph exporting), I wonder why it is needed, I think the blender mesh.vertices already has no duplicated vertex.