Hi! Trying the exporter with a single triangle, but I cannot make it work.

I already asked in the threejs repo, and there are chances that the problem relies in the exporter: I've just tried, and cesiumjs viewer/converter fails trying to load the gltf.

Please go to the issue in threejs repo for all the details

Blender 2.77a

Currently glTF skins are exported, but not animations. We have the BLENDER_action extension for BlenderPanda, but we need to support specification compliant animations.

Some new settings have been added that are not yet in the readme.

It's so weird, my changes are being added to master, but the branch itself is not listed as a parent, so it looks non-merged. What's your process for merging PRs?

In the proccess of exporting multiple gltf files one after the other, I discovered that the exporter names all of them "buffer_combined.bin" (Which would be great to customize in settings or have it use the gltf filename as a base) and if this file already exists it will overwrite without prompting.

If the material / texture of an object is messed up in Blender, a mesh can contain a primitive that has an "indices" member that points to an accessor that has a "count" value that is 0.

"count" must be >= 1. See https://github.com/KhronosGroup/glTF/tree/1.0.1/specification#accessorcount-white_check_mark

The bufferView that the accesor points to, has a "byteLength" of 0 as well. (Not very useful 😉)

Python's assert keyword could be used to make sure generated .gltf file is valid.

It's possible this is an artifact from before the spec was updated, but I thought I'd bring it up. KHR_materials_common already specifies a format for outputting lights. I believe this addon currently exports them in an extras block.

Would you be supportive of an effort to separate the exporter code to a separate repo? Currently, the exporter will output virtually all data-blocks in a scene, regardless of whether or not they are used. In Issue #37 you explain that it does this to support the BRTE data transport use case, but it can produce grossly sub-optimal .gltf files with large scenes. Even zero-user meshes are exported.

My users need a solid export tool. I don't want to be divisive, but this seems like the cleanest solution. What do you think?

The simple dimensions concept we currently use has the following issues:

• Assumes Z-Up physics engine, but glTF is Y-Up
• Relies on consuming engines to extract information from dimensions (e.g., pick a dimension to treat as radius/height, perform extra math steps, etc.)
• Inconsistent use of scale and lack of transform information. Blender's dimensions have scale applied, but there is no clear way to determine scale or transforms of mesh shapes. Further more, with no transform, we cannot easily specify offsets.

However, it does provide the following benefits:

• Easy to export
• Does not make assumptions about how the consuming physics engines defines shapes

When I try to export the model with the vertex group, Blender shows the following error:

Traceback (most recent call last):
  File "C:\Users\victo\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\__init__.py", line 177, in execute
    gltf = export_gltf(data, settings)
  File "C:\Users\victo\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 1403, in export_gltf
    'skins': export_skins(state),
  File "C:\Users\victo\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 850, in export_skins
    for mesh_name, obj in state['skinned_meshes'].items()
  File "C:\Users\victo\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 850, in <dictcomp>
    for mesh_name, obj in state['skinned_meshes'].items()
  File "C:\Users\victo\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 838, in export_skin
    bone = arm.data.bones[group.name]
KeyError: 'bpy_prop_collection[key]: key "hair" not found'

location: <unknown location>:-1

Also, thank you for the Blender add-on.

We should explore whether we want to export per-scene physics settings such as gravity, and what this looks like.

One of the issues with exporting a gravity setting is defining units. We could say that BLENDER_physics exports a gravity setting as an acceleration value in m/s^2, but that assumes that one glTF unit will be represented as 1m in the engine consuming the file.

If we want to handle lights properly for glTF 2.0, it looks like we need to support the KHR_lights extension: KhronosGroup/glTF#1068

Hi,

I'm getting issues exporting the mesh even when just doing it with the simplest settings or more custom settings. Not sure why but it won't handle an Icosphere or even susan without the mesh exploding.

Thanks!

We should support some form of layers or groups/masks in BLENDER_physics. Blender's RigidBodyObjects only expose a layer option, but its game settings expose the full group/mask concept that Bullet supports.

I've run into an issue where the URI to a texture image file is missing from the glTF file itself. I am able to reproduce this in a simple case:

1. Create a new, default blend file with camera, light, and cube.
2. UV unwrap the cube.
3. Apply a texture to the cube (in this case the UV color grid) using UV mapping, and place the texture in an "img" folder in the same parent folder as the blend file.
4. Export the cube to glTF.

Although the image file is copied, the URI reference to it is blank:

"images": { "image_uv_color.png": { "uri": "" } }

I am attaching a source blend file and image, the result of the glTF export, and a snapshot of the export settings I used. I am using Blender 2.78.

Test Cube glTF.zip
TestCube.zip

Following readme instructions, I get:

Hi, awesome work on this glTF exporter so far! Can I make a small feature request?

Please add a Selection only checkbox, similar to the STL exporter in Blender, such that only the selected objects are written to the exported file. This would help for example when you need to create a file that just has a mesh or a model but no lights or cameras, etc. Thanks!

hi,

when I try to active the addon, I get this error:

Traceback (most recent call last):
  File "/private/var/folders/3g/5hppblhd2pzdxhvjt8tj5_z00000gn/T/AppTranslocation/0AEC2418-2E78-40E2-92CD-7E92AB860044/d/blender.app/Contents/MacOS/../Resources/2.78/scripts/modules/addon_utils.py", line 330, in enable
    mod = __import__(module_name)
  File "/Users/freder/Library/Application Support/Blender/2.78/scripts/addons/blendergltf-master/__init__.py", line 43, in <module>
    from . import blendergltf
  File "/Users/freder/Library/Application Support/Blender/2.78/scripts/addons/blendergltf-master/blendergltf.py", line 1019
    else if texture.image.channels not in [3,4]:
          ^
SyntaxError: invalid syntax

This exporter (and every other exporter/converter I've found) currently outputs each vertex once for every face it's a part of. This maximizes compatibility, and it's guaranteed to work, but it adds unnecessary bloat to the file in many cases. The exporter should check to see if a given vertex can be shared (i.e. no per-face normals/colors/UVs), and only output it once in that case.

If no one is available to work on this, I might just do this myself. I've done some Python before, but no Blender scripting, so we'll see how it goes.

I've installed this plugin for Blender and have the export option but there is no import option. This would be most useful considering I'm converting files with the nodejs bin from https://github.com/AnalyticalGraphicsInc/obj2gltf after exporting obj's with other VR apps.

Blendergltf currently exports material parameters as values that don't necessarily line up with a shader. Blendergltf should either switch to the common material extension or create a new Blender material extension instead of abusing material values.

This documentation should match the documentation for official glTF extensions.

Hi,

Thanks for this export plugin, you've done great job. I would like to know if you are planning support for binary gltf ? One of the main difference is raw binary mesh data instead of base64 encoding.
Here is some documentation :
https://github.com/KhronosGroup/glTF/blob/master/extensions/Khronos/KHR_binary_glTF/README.md

Thanks,

Jeanpul

I try to export a Blender model to glTF using this addon. However, the model has a reference to a image file which does not exist any more. I can't seem to easily find out how to remove the missing image either.

Blender version 2.78.

This is the error message:

                                                                                              Traceback (most recent call last):

File "C:\Users\andre\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master_init_.py", line 131, in execute
gltf = blendergltf.export_gltf(scene, settings)
File "C:\Users\andre\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 1207, in export_gltf
'images': export_images(settings, scene_delta.get('images', [])),
File "C:\Users\andre\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 989, in export_images
return {'image_' + image.name: export_image(image) for image in images if check_image(image)}
File "C:\Users\andre\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 989, in
return {'image_' + image.name: export_image(image) for image in images if check_image(image)}
File "C:\Users\andre\AppData\Roaming\Blender Foundation\Blender\2.78\scripts\addons\blendergltf-master\blendergltf.py", line 956, in check_image
errors.add('x dimension is 0')
AttributeError: 'list' object has no attribute 'add'

Representative traceback:

Traceback (most recent call last):
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/__init__.py", line 89, in execute
    gltf = blendergltf.export_gltf(scene, settings)
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/blendergltf.py", line 1047, in export_gltf
    'images': export_images(settings, scene_delta.get('images', [])),
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/blendergltf.py", line 839, in export_images
    return {image.name: export_image(image) for image in images}
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/blendergltf.py", line 839, in <dictcomp>
    return {image.name: export_image(image) for image in images}
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/blendergltf.py", line 832, in export_image
    uri = image_to_data_uri(image)
  File "/home/filip/.config/blender/2.76/scripts/addons/blendergltf-master/blendergltf.py", line 812, in image_to_data_uri
    for span in range((height - 1) * width_byte_4, -1, - width_byte_4))
ValueError: range() arg 3 must not be zero

In 1.0.1 of the spec TEXCOORD_ must end with an index. See meshes. So properties like "TEXCOORD_UVMap" are not allowed anymore. (And application-specific must start with an _)

Taking a quick look at the code, it seems babylon.js and three.js expect an integer after TEXCOORD_.

I assume that is what is described in GLTFLoader.js#L739-L768, and a quick test looks OK.

EDIT: Well, actually that code is not in a stable release yet. I was testing against dev branch.

After exporting a .blend file in folder A to a .gltf file in folder B. The "uri" attribute of images contains a path relative to folder A. Sometimes the paths are absolute.

Wouldn't it be better to copy the images to folder B instead? (so that the .gltf and the images are in the same folder)

If the material / texture of an object is messed up in Blender, material ID can be empty. But if "material" is defined, it must not be empty. See https://github.com/KhronosGroup/glTF/tree/1.0.1/specification#primitivematerial

Python's assert keyword could be used to make sure generated .gltf file is valid.

Khronos has issued a Request For Quotes for upgrading this addon for glTF 2.0 support. It sounds like the glTF 2.0 spec is close to completion, so we should look at getting the codebase cleaned up for whoever they bring on to do the support.

A checkbox could be used to decide whether uri of a buffer contains a filename or base64 inline data.

I'm getting this error message when trying to export a fairly complex blender file as a gltf:

Traceback (most recent call last):
File ".../Blender/2.78/scripts/addons/blendergltf-master/__init__.py", line 175, in execute data = used_only(data)
File ".../Blender/2.78/scripts/addons/blendergltf-master/filters.py", line 76, in used_only slot.texture for slot in mat.texture_slots.values()
AttributeError: 'NoneType' object has no attribute 'texture_slots'

location: <unknown location>:-1

It seems the source property of a texture object contains the filename, for example:

"source": "test.png"

However, according to the spec, it must contain the identifier of an image object. See https://github.com/KhronosGroup/glTF/tree/1.0.1/specification#texture and https://github.com/KhronosGroup/glTF/tree/master/specification#textures

The extension has more or less stabilized, so I think it's a good time to get some extra eyes on it. Submit a PR to the KhronosGroup repo, so we're on track for ratification.

I'm not sure why this happens, I haven't had time to dig, but when you attempt to export objects linked from another file, the data is not added to the buffer, but the bytelength is still increased. So I ended up with the size of the output buffer being significantly smaller than buffer.byteLength.

Meshes are still exported even if they are unused or used by hidden objects (not in nodes). I would sumbit a PR but maybe I'm missing something.

Currently, the glTF exporter outputs one vertex for every loop of every polygon. This preserves sharp edges at polygon seams, but dramatically increases the size of the resulting model when polygons share lots of vertices. I propose an option that would prevent vertex duplication by outputting "smooth" vertex normals instead of face normals per vertex. Alternatively, the exporter could decide whether to split edges based on the shading mode ("smooth" or "flat").

Meshes that have more indexes than can be represented by a short datatype need to be split into multiple primitives. Integer-sized indexes are not currently supported by the glTF spec.

I want to float an idea by you guys @Kupoman @Moguri before I actually start work on it. I think it's a good idea.

The export_gltf.py file is getting too large, and it will only get larger as new features are added. I propose moving the parsing code for each type into classes that inherit this base:

class GLTFSerialBase:
    def __init__(self, context, source):
        '''convert source to gltf format, using context
        context contains the object lookup table, and glTF structures so far defined'''
        pass

    def __dict__(self):
        '''returns the converted glTF-compliant data structure'''
        return {}

    def __bytes__(self):
        '''returns the binary content of this object, or None if no binary'''
        pass

I expect this to greatly improve the readability of the code base. What do you think?

glTF allows node transforms to be specified as a matrix or as separate translation, rotation, and scale values. We currently always export node transforms as a matrix, but in some cases a user may prefer the separate transforms.

The generated identifiers are quite verbose, producing larger than necessary files. I propose a setting that would compact all the identifiers in the file while preserving the necessary links. Perhaps it could share an option with "Pretty-print JSON"? So material_Material.001 and its ilk would be shortened to a single-character random identifier.

This looks very promising!

Does it support skeletal meshes and animation export yet ?

Thanks

1. Try to export a large file that fails to export. For example, one that produces the following exception: struct.error: ushort format requires 0 <= number <= (32767 * 2 + 1).
2. Ctrl-n to reset Blender to the default state and then open a small .blend file that can be exported successfully.
3. Export the small .blend file

The exported .gltf will now contain in addition to the expected accessors, buffer views, and buffers, also tons of accessors, buffer views, and buffers from the previous model that failed to export.

Meshes, nodes, and scenes seem to be OK.

Can someone fill in how to install this into blender? I am lost and the readme has no information 😢

For some reason, models exported with this addon display with flipped V coordinates in Three.js compared to the reference models in Three.js. Investigation pending.

We need a way to handle PBR materials to better support the glTF 2.0 specification. Since Blender 2.7x does not support PBR natively, we will need to add a material panel for PBR settings. The setting for this panel should be linked with Blender materials to give a rough preview to the user.

Right now everything is kind of thrown in at random, and few things actually have tool tips. It would also be nice to group some of the settings like the COLLADA exporter does.

I don't know how often master is updated, but it might not be the best version to use.

Also, tags or releases can be useful to rollback to an older working version.

I'm preparing to start working on this, but I want to make sure you're not going to beat me to it again lol.