bad Normal vector in STL Ascii Export #39755

New Issue

Pierre Pontic · 2014-04-16T12:18:34+02:00

Pierre Pontic commented

2014-04-16 12:18:34 +02:00

When exporting a mesh with STL ASCII format, normal vector is written for each triangle, that's good.

BUT, the normal vector is always 0 0 0, whatever the triangle orientation. Some softwares (pyCam in my case) are not able to manage this inconsistency.

solutions :

don't write the normal vector
compute the rightnormal vector
have a checkbox that enable to write the right computed normal vector.

When exporting a mesh with STL ASCII format, normal vector is written for each triangle, that's good. BUT, the normal vector is always 0 0 0, whatever the triangle orientation. Some softwares (pyCam in my case) are not able to manage this inconsistency. solutions : - don't write the normal vector - compute the rightnormal vector - have a checkbox that enable to write the right computed normal vector.

Pierre Pontic commented

2014-04-16 12:18:34 +02:00

Changed status to: 'Open'

Pierre Pontic commented

2014-04-16 12:18:34 +02:00

Added subscriber: @Pierre-Pontic

Campbell Barton commented

2014-04-16 13:50:22 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-04-16 13:50:22 +02:00

This bug report is incomplete, no blend file or output STL.

Quick test shows face normals are not zero'd here.

This bug report is incomplete, no blend file or output STL. Quick test shows face normals are not zero'd here.

Pierre Pontic commented

2014-04-16 14:06:52 +02:00

I just downloaded the last build, and, lol, a wild "Write Normals" checkbox appeared, but it's not super effective.

If checked, normals are OK.

If not checked... Normals are written, and false.

I just downloaded the last build, and, lol, a wild "Write Normals" checkbox appeared, but it's not super effective. If checked, normals are OK. If not checked... Normals are written, and false.

blender-admin commented

2014-04-16 17:11:34 +02:00

This issue was referenced by blender/blender-addons@9ad943c1a7

This issue was referenced by blender/blender-addons@9ad943c1a74bc4b633c31592086f1185022baf1b

Campbell Barton commented

2014-04-16 17:12:08 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-04-16 17:12:08 +02:00

Campbell Barton commented

2014-04-16 17:12:08 +02:00

Closed by commit blender/blender-addons@9ad943c1a7.

Campbell Barton commented

2014-04-16 17:12:16 +02:00

Thats bad, somehow this slipped by me when reviewing, fixed now.

Pierre Pontic commented

2014-04-17 11:47:23 +02:00

Changed status from 'Resolved' to: 'Open'

Pierre Pontic reopened this issue

2014-04-17 11:47:23 +02:00

Pierre Pontic commented

2014-04-17 11:47:23 +02:00

Woops, I didn't tested as well as I should :D

With "Write Normals" checkbox unchecked, normals are not written, but the "facet" keyword neither. So it result a parsing error (in pyCam, at least).

Woops, I didn't tested as well as I should :D With "Write Normals" checkbox unchecked, normals are not written, but the "facet" keyword neither. So it result a parsing error (in pyCam, at least).

Pierre Pontic commented

2014-04-17 11:48:03 +02:00

tested with the latest release (a5b9f22)

tested with the latest release (a5b9f22)

Campbell Barton commented

2014-04-22 07:22:09 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-04-22 07:22:09 +02:00

Campbell Barton self-assigned this 2014-04-22 07:22:09 +02:00

Campbell Barton commented

2014-04-22 07:22:09 +02:00

My bad, read up on the STL spec and they are NOT optional,

I assumed because Blender's existing exporter didn't originally write correct normals that they weren't required, but seems enough applications ignored the normals that it worked (in some cases).

So, now normals are always written, as they should be.

closing.

My bad, read up on the STL spec and they are NOT optional, I assumed because Blender's existing exporter didn't originally write correct normals that they weren't required, but seems enough applications ignored the normals that it worked (in some cases). So, now normals are always written, as they should be. - closing.

Pierre Pontic commented

2014-04-22 09:33:49 +02:00

The last problem was not they weren't writen (I didn't know they were optional), most of my programs were able to load the files without normals. I think it is a good feature to avoid to write normals if they are not needed, that could save a lot of space (near 25%) for big files...

The last problem was when you skipped the normal information, you skipped the 'facet' keyword too, while you where adding 'end facet' in end of each face definition...

But, if it works like this, it's ok.

The last problem was not they weren't writen (I didn't know they were optional), most of my programs were able to load the files without normals. I think it is a good feature to avoid to write normals if they are not needed, that could save a lot of space (near 25%) for big files... The last problem was when you skipped the normal information, you skipped the 'facet' keyword too, while you where adding 'end facet' in end of each face definition... But, if it works like this, it's ok.

Pierre Pontic commented

2014-04-22 09:48:26 +02:00

sorry : I didn't know they were NOT optional.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

bad Normal vector in STL Ascii Export #39755