News:

 

Topic: Problems with Normals  (Read 563 times)

0 Members and 1 Guest are viewing this topic.

  • No avatar
  • Posts: 26
  • Vertex
December 13, 2018, 09:29:11 pm
2 examples of normals braking. Compute FaceWeightedNormals (All) does not fix it. For some reason attahcments don't work for me so I uploaded models here: https://ufile.io/v46uz

1. test.obj - looks good when imported, after action is preformed, normals break, action can be symmetry or just moving some random vertex, extrude etc.




2. test.fbx - looks good on import but all edges are in 'hard' mode (although smooth) and not in soft/hard like in .obj example. Upon executing an action like in previous example normals break and all edges get hard.



One question here not related to the bugs, obj has option for importing "Divide into objects by polygon groups", fbx does not, resulting in separated objects instead of being combined. Is it possible to add this?


  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 16, 2018, 09:47:58 am
Try this
http://www.digitalfossils.com/Download/NVil-Dec-16-18.rar

* Bug#1. Try this new tool, vertex mode > Transfer Normal. Align a vertex's normal to the normal of the closest vertex in a source mesh. Steps: 1- Align the two objects on areas of interest in object mode. 2- Set the source object as morph object in scene explorer window. 3- Deselect and maybe hide the source object. 4- Select the object of interest. 4- In vertex mode, select those vertex of interest then fire this command.

* Bug#2. Fixed.

* "Divide into objects by polygon groups" option is added to fbx import.

  • No avatar
  • Posts: 26
  • Vertex
December 16, 2018, 10:44:51 am
Thanks for new build!

1. Works good, but would it be possible to skip this tool and just keep normals from not breaking? Because right now I have to keep moving initial model with the one that gets tweaked and everything gets quiet hectic really fast especially if there are multiple objects like this.

Also correct me if I am wrong, right now we have this cylinder with a hole on one side and that's where normals break. In a case of extruding a polygon on the other side of the model, normals shouldn't change on the part with a hole?

2. Works good, thanks!

3. Thanks for the new option, works good, appreciate it!

  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 16, 2018, 11:00:54 am
1. It is too hard to implement because I have to remake all the tools, extrude/weld/split/tweak/... you name it. I don't think I am going to do that.

  • No avatar
  • Posts: 26
  • Vertex
December 16, 2018, 12:19:02 pm
Would it be possible to go one by one and not do all at once and fix this as time goes on? Maybe one or two per week or so? If not I guess I will have to try and find some different (easier) workaround, any suggestion appreciated.

To further clarify the issue, I work in combination with MoI3D and NVil, some parts are good to make in CAD, some parts are good to make in SubD modeling. NVil serves for me as SubD modeler and program where I assemble all the parts to finish robotic design. Parts that are made in CAD can be quiet heavy and detailed with not just one hole as in previous example but many many screw holes, vents and other detail, going in and manually fixing topology is not an option for me as a concept artist as I rely on fast and smooth workflow with as few technical hiccups as possible.

One more example of normals breaking on multiple parts

« Last Edit: December 16, 2018, 12:32:30 pm by thor6136 »

  • No avatar
  • Posts: 26
  • Vertex
December 16, 2018, 05:20:32 pm
Found one more issue with normals breaking on import for .obj file but not for .fbx you can get files here https://ufile.io/5paa0

If anything, for me having Symmetry Cut - WorldSpace_X(NoWeld) would be the most important to preserve normals. Others are a bonus :)

Edit: found one more potential issue, if you duplicate previous model, memory allocation seems to grow quiet a lot - around 300mb per duplicate. Feels a bit high for 25mb file?
« Last Edit: December 16, 2018, 05:53:52 pm by thor6136 »

  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 16, 2018, 09:35:57 pm
Found one more issue with normals breaking on import for .obj file but not for .fbx you can get files here https://ufile.io/5paa0

Can you point out what the issue is?

  • No avatar
  • Posts: 26
  • Vertex
December 16, 2018, 10:01:55 pm
Here you can see obj vs fbx result. These are one of the parts that get broken


  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 16, 2018, 11:00:36 pm
I suspect that the normals have not been exported correctly.
Normal values are not modified during import process.

Edit: Never mind. I found the bug.
« Last Edit: December 17, 2018, 02:26:12 am by IStonia »

  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 18, 2018, 09:31:37 am
Found one more issue with normals breaking on import for .obj file but not for .fbx you can get files here https://ufile.io/5paa0

If anything, for me having Symmetry Cut - WorldSpace_X(NoWeld) would be the most important to preserve normals. Others are a bonus :)

Edit: found one more potential issue, if you duplicate previous model, memory allocation seems to grow quiet a lot - around 300mb per duplicate. Feels a bit high for 25mb file?


Try this
http://www.digitalfossils.com/Download/NVil-Dec-18-18.rar

The .obj import bug is fixed.
Symmetry Cut will preserve normals.

  • No avatar
  • Posts: 26
  • Vertex
December 22, 2018, 12:22:03 pm
Thanks a bunch IStionia, appreciate the effort! Works good so far.

  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 26, 2018, 09:47:25 am
Would it be possible to go one by one and not do all at once and fix this as time goes on? Maybe one or two per week or so? If not I guess I will have to try and find some different (easier) workaround, any suggestion appreciated.

To further clarify the issue, I work in combination with MoI3D and NVil, some parts are good to make in CAD, some parts are good to make in SubD modeling. NVil serves for me as SubD modeler and program where I assemble all the parts to finish robotic design. Parts that are made in CAD can be quiet heavy and detailed with not just one hole as in previous example but many many screw holes, vents and other detail, going in and manually fixing topology is not an option for me as a concept artist as I rely on fast and smooth workflow with as few technical hiccups as possible.

I don't know how other apps handle this. Can you tell me what you know?

  • No avatar
  • Posts: 26
  • Vertex
December 27, 2018, 07:09:18 pm
I did some digging and apparently there were same issues in Blender, Softimage etc with models exported from CAD. There seems to be great information on Softimage wiki about so called User Normals and how they are implemented. They keep user normals in custom stack with custom stack when they are being modified. http://softimage.wiki.softimage.com/xsidocs/poly_shading_SettingUserNormalsonPolygonMeshes.html

Blender calls them custom normals: https://en.blender.org/index.php/Dev:Ref/Release_Notes/2.74/Modeling

And part from random Blender forum discussion

"And that’s the whole point of working with imported CAD normals: Not to mess with them in Blender, right?

Because as soon as you change the mesh in Blender, the custom normals will be corrupted. From my understanding that was the major breakthrough in Blender 2.74 and above: Blender finally leaving the imported normals alone."

This is exactly what is happening right now in Nvil, they get modified and 'corrupted'.

Hope this helps!

  • No avatar
  • Posts: 3503
  • Developer
  • Administrator
  • Polygon
December 28, 2018, 11:03:18 am
OK, I looped through all the tools and modified them to preserve custom normals. You can test it and let me know how it goes. Caution: It could be quite buggy since the amount of modification.

http://www.digitalfossils.com/Download/NVil-Dec-28-18.rar

  • No avatar
  • Posts: 26
  • Vertex
December 28, 2018, 12:07:09 pm
Holy shit you are golden! Works good so far, I will keep testing it and report if there are any problems, thanks a bunch!