lizhao21st / jsc3d

Automatically exported from code.google.com/p/jsc3d
0 stars 0 forks source link

Zero surface normals in STL files #37

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create any model in (for example) blender
2. Save as (binary) STL
3. View in jsc3d

What is the expected output? What do you see instead?

The object should be flat shaded - it's actually black.

What version of the product are you using? On what operating system?

Any version on any OS.

Please provide any additional information below.

The problem is that some STL exporters do not create normal vectors for each 
triangle - the standard (at least according to the Wikipedia page for the STL 
file format) is that the loader should test for zero length normals and compute 
it's own normal from the vertex coordinates of the triangle.  Worse still, the 
renderer uses the normal vector to do backface culling (which is pretty 
unconventional - most renderers use the vertex ordering to determine that).

Original issue reported on code.google.com by SteveBak...@gmail.com on 19 Jul 2013 at 7:18

GoogleCodeExporter commented 9 years ago
Thanks Steve! I'll fix this as soon as possible.

Original comment by Humu2...@gmail.com on 20 Jul 2013 at 4:15

GoogleCodeExporter commented 9 years ago
Thanks for the swift response!

To be completely clear, I only tested the problem with binary STL files from 
blender - but from a quick look at the code, I believe that ASCII STL's must 
have the same problem.

STL's are frequently used for controlling machine tools like 3D printers and 
CNC milling machines that don't care about surface normals, colors or anything 
else other than the triangle vertices - so it's fairly common for STL exporters 
to fail to write the normal vector and for STL importers to recreate them from 
the triangle edges.

The STL file format *really* sucks - it's horrifying that it ever became such a 
ubiquitous standard for machine tools!

Original comment by SteveBak...@gmail.com on 20 Jul 2013 at 1:20

GoogleCodeExporter commented 9 years ago
Thanks for the detailed explanation!

This bug has fixed by checking some normals loaded from an STL file. If the 
normal length equals to 0, the face normal buffer will be set to null so that 
they can be automatically calculated when mesh is initialized.

I'll commit the patch to the respository soon.

Original comment by Humu2...@gmail.com on 21 Jul 2013 at 6:10