Did you update the cop car or not?
If not, I’ll reiterate the fact that the origin is (0,0,0) from the export itself, and the vertices are shifted. I don’t think there’s something we can do in this case.
The skeleton/animation stores extra data that allows it to transform the vertices.
Thanks! I’ll look into these!
Thanks for reminding me!
I need to make this work for an M1 as well.
Multiplatform/architecture is quite fiddly sometimes!
@anon95708182 Which editor version are you using? The one I’ve linked at the top?
Ah - sorry, Mathias , I missed this. I tried on the current standard editor version. Will give it another shot.
Just did: all there, really cool and no probs at a quick glance! Thank you very much - now I can play around and have a look 
@Mathias_Westerdahl
Mathias, just a quick feedback.
As probably expected, I have the same issues as @MasterMind with setting up animations on my mini m1.
And, just on a sidenote: there is no smoke in the animation collection, so the editor moans about the missing instance. 
But the main script might be @MasterMind 's and not yours.
Everything else is cool!
You are right, the missing particle in this collection was my fault. i’ll get that fixed.
thanks , I’ll have to look into this further.
Tested playing animation from a script, is not working.
using :
model.play_anim(model_url, roll, go.PLAYBACK_LOOP_FORWARD, { playback_rate = 0.9 , blend_duration = 0.2 } )
Get a crash when building if model property “Default Animation” is set to none then trying to start animation via script. No crash if a default animation is set in model properties and trying to change the animation via script has no effect.
The crash occurs from passing blend_duration in model.play properties table when there is no default animation selected , no animation playing to blend with.
You are correct, when testing the transforms offset issue from before I had accidently saved the project file after applying delta transforms to the copcar and armature out of habit, then never reverted the transform. I cleared the delta transforms but the issue seems to be still present.
Update: The offset still happens when no animation is set in “Default Animation” property. it only happens when exporting with armature selected. Armature(Bones) also have the same origin location as the model. I will still try and pin it down, but if all else users can set the model to zero world position to export if they need the default no animation selected in model setting.
I will recreate model and animations from scratch and confirm the issue.
I’ve updated the build with some more fixes.
As far as I know, there are no outstanding issues with this build.
The only thing left to do on my side is to clean up our unit tests, and write a few more for the new format. If nothing unforeseen happens, I expect it to be released in the 1.3.7 release.
Confirmed blending property crash is fixed.
Confirmed selectable “Default Animation” property for glTF single animation setup is now working properly.
Now when applying an animation set file in model properties and choosing a “Default Animation” the animations do not show in drop down menu , now only the name of the animation set file is shown.
I have worked out the proper exporting settings for glTF from blender and now got the animations playing from code.
interesting step needs to be made on export for both model and skeleton. The animation action needs to be set active on both model and rig separately, then exported. Much different than .dea animation export.
couldn’t find any other bugs 
Updated project file:
Test_importer_Agustin.zip (985.4 KB)
Hah, thanks for this. I really thought I tested that.
What’s plans for including this in a beta/release?
Not sure if it’s a real issue or not but if I tried exporting a model that did not have UVs it would not work. It either complained the file was corrupt or drew the whole screen as black. Until I created UVs, exported again. I was using objects that are shaded only with colors so didn’t care about UVs.
We want to release this as soon as possible, once we are confident that all major issues have been resolved. This thread and everyone in here testing the new importer has been a fantastic help to us. I will let @Mathias_Westerdahl share more about the release plans, but it should be fairly soon now.
Don’t rush it, it could be a very huge announcement, so better to take care of UX upfront 
I’m not into Defold 3D, so sorry I am not much of a help here 
but the work you are doing is amazing! 
The plan is to have it released in the next version or so.
This thread was created so that the users could report the different issues.
I’ll look into how to deal with missing uvs. It shouldn’t crash ofc.
If you could share a test model, I will take a look at it!
I’ve now submitted an fix for the animation set dropdown issue.
The CI is [currently building]( Fixed issue where the animation set wasn’t detected), so it should be available within ~1 hour.
Tested glTF with no UV’s , used built-in material and custom material shaders and couldn’t get any errors or reproduce Pkeod’s issue.
Does the latest build have the same SHA1 (cb80d9d5b2c18e52358f8a65e50312a2fa094ea9)?
If not where can I navigate to the latest test build?
The sha1 is 1aa8c581af20e09605957ebf707ad716553cffa2, and I’ve updated the download links in the top post.
glb_gltf_samples.zip (14.4 KB)
It’s possible they were exported wrong. But I did test adding UVs after and exporting and that version worked.
The branch is now up for review, and the hope is that it should be part of the next beta release, which is due this upcoming monday.
I’m trying to use the vertex color. I get a strange result. The editor displays mesh, model, model in the collection differently. In the build it is displayed as expected.
test_3d_gltf.zip (30.3 KB)
