Building a Sync Tool for Blender to Defold

Hrm. Im not sure multiple uvs are supported in Defold just yet. I’ll do some tests. I can add another section to the buffer object and see if it is passed through.

why not, you can create mesh buffer of custom format
same for normal maps (if you plan to add them), you will have to export tangent as well (and maybe bitangent to avoid computation)

Yes, you definitely could, but then thats a custom mesh, and probably wouldnt be properly visible in the editor? Because the Sync Tool generates Defold based resources (buffers etc) and a resource structure, it’d be nice to keep it closely matched. I suspect a second uv would be relatively easy to add in the pipeline, if it isnt already.

Adding a texcoord1 to this:

Would be my preference. Custom buffers could be added, but are not really high on my todo list :slight_smile:

They are visible without issues as I remember, you can apply build-in shader or custom one.

Ok. I’ll give it a try - Im not sure how builti-in shaders would possibly work with custom buffers? Ie, the model material for example (for anim) definitely needs to have a specific buffer setup. Will see, should be easy enough to test.

Just make sure you use the same (as defold mesh exporter) buffer stream names for position\normal\texcoord0 - it’s “position”, “normal” and “texcoord0” :slight_smile:

1 Like

Im already doing this (see github link above).
The problem is if you make modifications to the buffer you will then need to add code or shader modifications to support the changes in the buffer elements.
The model material is even more strict, due to the anim. I have done a fair amount with the mesh component (in a geom generator too) and Im not sure you can get extra information into the buffer with out custom code or shaders.

I think what you are suggesting is something like this:

    "name": "texcoord0",
    "type": "float32",
    "count":4,           -- <<--- 4 instead of 2, adding extra uv's to the same buffer
    "data": [

Which would work, but again you need to be able to support that in the materials etc. Im pretty sure I tried this in the past, and the resource loader fails to load it. I’ll check again (was a early last year when I tested that).

What I was suggesting is another complete texCoord stream - which would require a engine change, but I think this might be potentially more useful, especially if it was designated a “custom” stream and thus allow buffers with all sorts of different data in them.

you will have to write your own materials anyway, I don’t think it’s possible to make a nice looking game with a single build-in material
texcoord0 with 4 coords probably will make buildin material look wrong but extra stream won’t break anything


Sorry, I was confused because you mentioned that built-ins should work fine and I didnt quite get how that could work. So yes, this is why Im not really wanting to do custom materials too much or modified buffers unless they can be supported by Defold directly - because otherwise there ends up being the need to create too many new resources for single use.

A possible solution will be to provide links to materials, shaders and buffer structures on the blender side, but again thats a substantial impact on the plugin so its not really a high priority. Id much rather have better PBR (env map specifically) and lighting before this.

The aim is to get the data sets into Defold “ready to use”. Then if people want to apply their own shaders and so on, they can. I will be testing the extra stream in a day or so, so if that doesnt break the resource pipeline, then I’ll add it as a custom option (should be fairly trivial to try out).

I’ll raise an issue on the repo so I can track this. If you want to try and add something yourself, feel free to fork, or do a PR.


I did a quick test with texCoord1 stream and I think its working. Added a secondary stream. Im currently using duplicate uvs in the shader, so I cant really tell for sure. Will try a secondary texture to see if its all good.

I’ll probably make it work on detection of secondary uvs sets on the Blender side.


So, after a late night last night. And more digging, its becoming quite clear that multi-layer maps (not pbr texture slots) are not a trivial thing to get happening - mainly because there are many ways to end up with verts with multiple uv layers.

The result, is that exporting the uv layers while possible, is probably going to introduce a world of pain. The other potential downside, is that you will end up with more draw calls on an object with multiple uvlayers. I suspect it would be better to do things like decals, shadowmaps and so on, within defold itself, because each developer will likely ‘have their own method’.

Im adding a checkbox that enables embedding the extra data as a second channel only but this is likely to be inconsistent, due to the way people generate art in Blender - ie, one vert has multiple layers when mapping two sides of the vert to different textures.

Summary: Single texture/material for single mesh is going to be the norm - secondary textures can be added (check box), but wont be supported in the PBR and the data output may be inconsistent.

1 Like

I have been tinkering some more. And I think there is a simpler way to handle shadow mapping. The PBR Im using supports an Emission texture. I think it is entirely possible to map a light or shadow map to this channel - which would make adding an extra uv stream a fair bit simpler - ie, it would be a fixed channel. Will build up a test over the coming weeks.


Starting to get some cleanup and feature into sync tool again.

  • Fixed major bug with normals not being exported.
  • Added initial second UV stream in buffer definition.
  • Working on pbr setup to support shadow maps as an emission map - ie, emission of 0 is dark(blackout) shadow, 1 (bright) is no shadow. May support other variants of this.

I hope to have much of this wrapped up tomorrow. And just bug fixes going in only. I will be testing a wide array of meshes/models - I’ll be using Khronos’s gltf mesh and anim test library, its a nice set to check against. I’ll put the results up on the github so I can track missing features and problems.

Here’s a little car I did recently (helped me find the normals issue).

Oops. Almost for got. Source:


I really hope we can get Defold close to the Sketchfab renderer . I dont expect exactly (because they are doing some nice multiframe composing) but it should get close… I hope :slight_smile:


What multiframe compositioning? TAA? That should be doable with Defold I think, or what are we missing? :thinking: As far as I remember it’s more or less storing an FBO that contains weighted samples from old frames and then some magic filtering based on object velocities. I’ve converted this project ( to javascript some time ago and it wans’t too crazy to implement. If it’s the only thing missing to get the sketchfab quality I can definately make an example project based on my old code :slight_smile:

I read an article a while back on their renderer. They do some of their radiosity, shadows and other “ray casting type features” over a number of frames - you can see it when you spin. When it stops it visually improves the render. Thats not really something you want in a realtime game :slight_smile: … but its great for showing off models. :slight_smile:

I’ll dig up the article. I used to do alot of threejs rendering, and sketchfabs renderer always impressed me. But yeah… need to remember use case :slight_smile:

Oh. btw. Def want to build up a way to make a nice render scene. So TAA is def a good idea. Im probably going to make some design docs, because I kinda want a “basic nice renderer” that works within the editor without too many hassles/problems for the use. Ideally something that people can customise to their own needs later. But I kinda want the asset pipe to support the default materials as well - it makes it a little messy. But I have a couple of ideas that should make it work ok.

One soon to be added feature (next week I think) is custom materials. The user can provide custom materials to map to Blender materials, and then it generates the asset set with the correct meshes and go’s with the custom materials - should be quite easy to do, but will allow alot of flexibility for people.

1 Like

That sounds awesome! One thing that has always been missing regards to getting more people into making 3D games with Defold is a set of basic lighting setups that kinda makes everything look good out of the box. Something like unitys universal render pipeline, but simpler. Most people don’t fiddle with the render scripts anyway, so there should be a way to build a setup that you can just hook in I guess. But yeah let us know if there are any show stoppers that we might be able to help out with!


Yes. Exactly what I was thinking - I have lights from Blender coming into the asset pipe, so having a nice/simple lighting thats GTG with a nice pbr and maybe some shadowmaps and possibly global illum (probe lights maybe). A suite of “3d ready to use scene” direct from blender. And that its should look “close” to the blender scene in Eevee - or key render features anyway.

Sorry editing. I had a thought. Do you think a set of render scripts would be ok to bundle? It means I could handle alpha and reflection/cube maps a bit easier too. Hrm… might have to make a thread for this. Dont want to make this too big :slight_smile:


Added this: What do you consider base features for 3D?


More fixes.

  • Found normals were not being set (omg stupid bug - was previously working!)
  • Now auto converts any non PNG texture image to png. Ive tested mainly JPEGs and its working well. May add an option to disable if needed. Conversion takes a little longer if there are many large JPEGs to convert.
  • Many little bugs.

Will check this in tonight. Its getting better. Im going to put a simple reflection map in tonight as well.


With reflection maps, it definitely is starting to get close.

Need to balance the pbr a little (the normal map is a bit strong now). But its ok.
Hrm… just realised… a little mp4 would be nicer… replacing img.

Note: Lights are still not quite right. I hope to have that sorted all out by tomorrow.