# VertexData.ComputeNormals() Issues

**URL:** <https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962>\
**Category:** Bugs\
**Tags:** gltf\
**Created:** [November 2, 2021, 2:15pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962 "2021-11-02T14:15:28Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![pnut](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/pnut/32/9457_2.png) [@pnut](https://forum.babylonjs.com/u/pnut)\
**Post date:** [November 2, 2021, 2:15pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/1 "2021-11-02T14:15:28Z")

</div>

Hi all,  
I’m trying to use the `VertexData.ComputeNormals()` function to generate the normals for a glTF mesh without normals, and have run into a couple of issues that can be seen in this playground:

[https://playground.babylonjs.com/#7074FJ#12](https://playground.babylonjs.com/#7074FJ#12)

 ![Screen Shot 2021-11-02 at 10.02.49 AM](https://us1.discourse-cdn.com/flex024/uploads/babylonjs/original/3X/c/0/c0613615cd4e399842ae6020a8ae1e05d13e764f.jpeg)

1. The top and middle meshes show how the computed normals look different (flat vs smooth) for the same geometry depending on whether or not they were exported with the “Optimize Vertices” option turned on in the Babylon Exporter. Anyone know why that would be?

2. The middle mesh has a visible seam in the normals where the boundary of the UV map lies. Compare this with the bottom mesh, which had its normals pre-computed in Maya before exporting to glTF. There was a similar issue that was already addressed in the OBJ import process (see [OBJ loader - Computed normals are wrong if OPTIMIZE\_WITH\_UV is set to true](https://forum.babylonjs.com/t/obj-loader-computed-normals-are-wrong-if-optimize-with-uv-is-set-to-true/16896)), is this something that also needs to be addressed for the computeNormals() function?

---

<div class="post-metadata">

**Author:** ![msDestiny14](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/msdestiny14/32/9572_2.png) [@msDestiny14](https://forum.babylonjs.com/u/msDestiny14)\
**Post date:** [November 2, 2021, 3:04pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/2 "2021-11-02T15:04:43Z")

</div>

Let me see if I can get the ball rolling and share what I learned so far.

For your first question. `Anyone know why that would be?` Let actually take a look at the normals using the handy inspector. You can do this by click on the mesh in the scene explorer and then scrolling all the way down to debug and toggling Render Vertex normals.

 ![image](https://us1.discourse-cdn.com/flex024/uploads/babylonjs/original/3X/e/4/e446e29124051bab7d79a961b3bb809f44ed4cea.png)

Now this is just my observation but see how for the top mesh there are 2-3 normals for any given vertex. I think this is because you are getting 1 normal for each intersection point. While on the middle one I only see 1 in most places but 2 in the area of the seam. For the lowest one it seems to be some kind of average of all of the different normals so you only get a single normal.

I hope someone will have more follow up to this, and Ill be taking a look further myself to see if I can learn more. 🙂

---

<div class="post-metadata">

**Author:** ![pnut](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/pnut/32/9457_2.png) [@pnut](https://forum.babylonjs.com/u/pnut)\
**Post date:** [November 4, 2021, 5:26pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/3 "2021-11-04T17:26:57Z")

</div>

Cool, thanks @msDestiny14 for the visualization! Wondering if anyone else has any ideas about what the root cause of these inconsistent normal values is, and whether or not these are bugs. I would expect both the middle and top meshes to look like the bottom one after I use `computeNormals()` to update the normals.

---

<div class="post-metadata">

**Author:** ![sebavan](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/sebavan/32/57_2.png) [@sebavan](https://forum.babylonjs.com/u/sebavan)\
**Post date:** [November 4, 2021, 10:05pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/4 "2021-11-04T22:05:42Z")

</div>



---

<div class="post-metadata">

**Author:** ![jeremy-coleman](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/jeremy-coleman/32/15493_2.png) [@jeremy-coleman](https://forum.babylonjs.com/u/jeremy-coleman)\
**Post date:** [November 6, 2021, 3:51am UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/5 "2021-11-06T03:51:34Z")

</div>

Maybe u can make this work for your needs [GitHub - jeremy-coleman/normal-rust: A small Rust / Webassembly project to calculate Normals](https://github.com/jeremy-coleman/normal-rust)

---

<div class="post-metadata">

**Author:** ![pnut](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/pnut/32/9457_2.png) [@pnut](https://forum.babylonjs.com/u/pnut)\
**Post date:** [November 11, 2021, 1:28am UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/6 "2021-11-11T01:28:42Z")

</div>

Thanks @jeremy-coleman, will take a look when I get the chance. Still think it’s worth digging into what’s going on with `computeNormals()` since my team would like to be able to rely on the normals computation within Babylon. Anyone familiar with the function and might know why it’s being inconsistent in the given examples?

---

<div class="post-metadata">

**Author:** ![JCPalmer](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/jcpalmer/32/42_2.png) [@JCPalmer](https://forum.babylonjs.com/u/JCPalmer)\
**Post date:** [November 11, 2021, 11:25am UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/7 "2021-11-11T11:25:23Z")

</div>

1- back in the early days, smooth shading was deemed optimized versus flat. It is more compact, but just different. Apparently, computeNormals detects previous normals. Check source code.

2- I think seeing what happens with computeNormals when UVs are deleted would be instructive.

The rust code was a simplified (no options) version of computeNormals for the purpose of evaluating performance. Don’t think it will give different results, unless you are specifying options.

---

<div class="post-metadata">

**Author:** ![pnut](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/pnut/32/9457_2.png) [@pnut](https://forum.babylonjs.com/u/pnut)\
**Post date:** [November 11, 2021, 8:50pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/8 "2021-11-11T20:50:20Z")

</div>

Removed UVs and exported with and without optimized vertices (3rd and 4th meshes from the top). `computeNormals()` generates flat shading for both.

[https://playground.babylonjs.com/#BC8HYU](https://playground.babylonjs.com/#BC8HYU)

 ![Screen Shot 2021-11-11 at 3.39.03 PM](https://us1.discourse-cdn.com/flex024/uploads/babylonjs/original/3X/8/3/83042b451ab7d2194bf881776c8c0a34f5734e1b.jpeg)

Does this help at all? My goal is to be able to consistently generate smooth shading normals in Babylon, like the ones on the bottom mesh, for a mesh without normals. And also for there to be no visible seam where the uv boundaries lie.

---

<div class="post-metadata">

**Author:** ![pnut](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/pnut/32/9457_2.png) [@pnut](https://forum.babylonjs.com/u/pnut)\
**Post date:** [November 11, 2021, 9:43pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/9 "2021-11-11T21:43:36Z")

</div>

OK, I messed around some more and found that calling `forceSharedVertices();` on the mesh before computing the normals results in smooth shaded normals free of any artifacts!

---

<div class="post-metadata">

**Author:** ![sebavan](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/sebavan/32/57_2.png) [@sebavan](https://forum.babylonjs.com/u/sebavan)\
**Post date:** [November 11, 2021, 9:53pm UTC](https://forum.babylonjs.com/t/vertexdata-computenormals-issues/24962/10 "2021-11-11T21:53:31Z")

</div>


