Exporting from Blender using Babylon.js exporter failing

I’ve got a 3d scene that I’m trying to export using the Babylon.js exporter; however I’m running into this issue:

Exporter version: 2.93.4, Blender version: 2.93.3
========= Conversion from Blender to Babylon.js =========
	Scene settings used :
		Inline textures     :  false
		Material Type       :  PBR
		Positions Precision :  4
		Normals Precision   :  3
		UVs Precision       :  3
		Vert Color Precision:  3
		Mat Weight Precision:  2
		Keep Z-up r-handed  :  no
		Texture directory   :  C:\Users\Mics\Desktop\house\
	Python World class constructor completed
	WARNING: No active camera has been assigned, or is not in a currently enabled collection
	processing begun of mesh:  building_03.001
		processing begun of material:  material-env-project


			processing texture Nizar_Ztn_Palette_256_Gradient
				texture type:  diffuseTexture, mapped using: "uv1"
			bake time:  0 min, 0.008 secs
		Custom split normals with tangents being used
		num positions      :  18784
		num normals        :  18784
		num tangents       :  75136
		num uvs            :  37568
		num uvs2           :  0
		num colors         :  0
		num triangles      :  7616
	Output cancelled due to data error
========= end of processing =========
elapsed time:  0 min, 0.3642 secs

I found this existing thread: Error reporting in exporting from blender to a Babylon file—— ERROR: UN-EXCEPTED NODE TYPE(SHADERNODENORMALMAP). CANNOT CONTINUE. processing begun of material: TopBack

This is the Shader Editor view of my Blender model:

If I do as the above thread seems to suggest and change the “Normal” property value from “Normal/Map” to “Default” (which also removes the “Normal/Map” box from the Shader Editor chart above), the Babylon.js exporter works.

Just wondering:

  1. what exactly is this “Normal” property? changing it from “Normal/Map” to “Default” didn’t seem to have any visual impact on the exported model from what I could tell.
  2. is it a bug in the Babylon.js exporter that it can’t handle the “Normal: Normal/Map” case? could this be fixed?

cc @JCPalmer hope you don’t mind me pinging you - from my understanding you’re the owner of the exporter, would love some advice here, thanks

The only thing I can confirm is that @JCPalmer is not only the owner but mainly the brillant mind behind this exporter :slight_smile:


My guess, confirmed after a quick try, is that the exporter expect a texture after a NormalMap node. Here in your material you don’t have a normal map, so basically just delete the NormalMap node and it should be fine.


Well, some times things go wrong when playing with switches you do not understand. A normal in general is a value from 0-1. How it relates to geometry (ignoring flat shading) is there are 3 normal values (x, y, z) for each vertex, which tell what direction is “out” or “front”. So for these pair of pants there is a 3 element normal for each vertex in the geometry area.

As far as to normals being part of a material, your situation, sometimes you may want additional info like winkles, but not have to pay for it with additional geometry. You can specify a texture which has very high grained normals, encoded as colors, which are applied just like other textures are in the fragment shader of a material. Here is the normal texture for geo above. It does not look like much but does give an more embossed look.

Act of exporting as it relates to material is kind of like a scavenger hunt. The exporter traverses the node tree, and finds things which can be translated into an exported material. There are many types of Blender nodes which have no equivalent, e.g. Glass, Magic. In cases like this, the exporter attempts to bake the result of the material into a texture.

For this, it does look like there was a slight over reaction. The material went on to bake a diffuse texture. Just before the output generation pass though, a check for any errors got the process to self terminate. Deleting the node was the right answer though.

I will revisit this for the next LTS release, 3.03.0. Perhaps a more tolerant approach is do-able. Since 3.0 has still not arrived, that may be longer than May for the next LTS.


Well, I will go as far as accepting dangerous. Danger and luck are the ingredients for brilliant.


Thanks for the explanation! I ended up removing the Normal values and resolving the issue.

Well, some times things go wrong when playing with switches you do not understand.

In my defense, this was the file provided to me by someone from Fiverr who I contracted to make a map scene for me :sweat_smile:

1 Like

View that statement in terms of the post about danger. No danger = limited upside, so no defense required.

Also, I really have to admit that I knew you did not do this model. No one who did custom split normals in Blender would ask what normals are. That is pretty advanced.