The short version of this post, if you don’t want to go into technical details, is that one aspect of using bump mapping is now better in Castle Game Engine. Our data transfer and logic is more efficient and more aligned with glTF and latest X3D specifications.

And if you still don’t want to go into technical details, you can clone our demo-models repository and open the models in subdirectory bump_mapping/tangents/. There are 3 models there, and they are all available in both glTF and X3D model formats (scene.gltf, scene.x3d). Open them using the latest Castle Model Viewer snapshot (5.3.0) and they should work equally well and pretty.

You can also clone glTF-Sample-Assets and open the testcase NormalTangentMirrorTest there and observe that we handle it correctly (well, as much as we can without environment lighting).

You can also watch our old video about using normalmaps with Blender and Castle Game Engine. When using normal maps, you do bump mapping and then exporting your models with tangent vectors makes sense. It’s literally one checkbox when doing Blender->glTF export.

An if you’re still reading, time’s out! Now I assume you want to go into technical details 🙂 So what are tangents and what’s going on?

• To make bump mapping look good, the 3D models may provide explicit information about the tangent vectors at the surface.

• Our proposal of Tangent node contains a good explanation what tangent vectors are and why do we recommend to provide them in 3D models (if you use bump mapping). In short, tangent vectors, along with normal vectors, define the tangent coordinate space in which the values of the normal map are provided. Whatever process you use to create normal maps (most of you bake normal maps), it’s best to provide to the rendering engine the same tangent vectors as have been assumed when creating the normal map. In other words, simplifying, it’s best if Blender calculates tangent vectors, and uses the same tangent vectors for normalmap baking and passes the same vectors to glTF.

• glTF standard defines how to store tangent vectors, Blender->glTF exporter can generate them, and we read the information from glTF, and convert it into X3D Tangent node.

• We already had Tangent node in our engine for some time, but with a definition that had a small simplification: I defined the vectors there as 3D, right-handed. In contrast, glTF defines them as 4D, with XYZ designating direction, and W designating the handedness. We think the glTF idea is quite smart and useful 🙂

• We have recently recommended to add Tangent node to the X3D spec, the proposal is here. While adding to X3D, we also proposed to add them in a version more aligned with glTF, so 4D.

• Of note is that X_ITE, another cool open-source X3D viewer, also has compatible Tangent node. With 4D, matching also glTF. So after this, we’re all better aligned.

• The new X3D prose about Tangent node is here.

• And to close the circle, the Castle Game Engine has now adopted this Tangent node specification with 4D vectors. This means we display X3D models with the new Tangent node, and when reading glTF we convert the glTF -> X3D information in the trivial way (glTF 4D tangents -> X3D 4D tangents).

Does anyone still follow? 🙂 Hopefully above was a good summary and link to hopefully useful resources.

If you like what we do, in Castle Game Engine but also around standardization efforts like X3D, we always appreciate your donations. Thank you!