[Fixed] Polygon "Normal" Move

Hi IStonia,

This as been a bug for a long time that I thought I had mentioned before, but will post a bug report.

If you look at(for example) the tools:-

[Streamline engine]
Subobject Tools >> Tweak_NormalMove(RespectPolygonNormal)
Polygon Tools >> Polygon_LocalMove_PolygonNormal

You will find those tools do not move polygons with respect to polygon normals. They appear to work more to vertex normals/polygon average normals, which is different, and can give incorrect results.
Also, those tools do not function at all if all polygons on object are selected.

Quick example:-

Closed box with slot.
If all polygons are selected, the above 2 functions will not work.



With the polygons on base not selected, but all other polygons on model selected, using "Tweak_NormalMove(RespectPolygonNormal)" (soft selection disabled), the movement appears to be based on vertex normals/polygons average normal directions.



Performing same function is "Wings 3d", the result is correct:-



-------------------------------------

To add for some clarity.

I have taken a section of the above simple model, and triangulated.


 With any tool/function that works with respect to polygon normals (move/extrude etc), should be working with the polygon normal directions of the polygons, not the vertex normals or the average normals.(If I want to work to vertex normals or polygon average normals, there are other specific tools/function).
But when using
[Streamline engine]
Subobject Tools >> Tweak_NormalMove(RespectPolygonNormal)
Polygon Tools >> Polygon_LocalMove_PolygonNormal

The result is not respecting those polygon normals:-


The same results are made if using "Polygon_LocalMove_AverageNormal" or "Tweak_NormalMove(IgnorePolygonNormal).

-----------------------------------------
Other tools/functions, such as (again, as example)"Polygon_Extrude_PolygonNormal" can also give incorrect results. It is put forward about using hard_edges to control such extrusions, but hard_edges control vertex normals, not polygon normals, so changing between hard/soft edges should not be changing the results of extrusion made in respect of polygon normal directions.


I can post more examples if required.

Test this
http://www.digitalfossils.com/Download/NVil-Aug-12-14.rar

Hi IStonia,

On checking with Tweak_NormalMove(RespectPolygonNormal), I see you are still calculating based on hard_edge information. On the above example model, with hard_edges applied to the 90deg edges, I do get expected results. But when the edge angles are not 90 deg, with or without hard_edges applied, the results are still incorrect.

Example (using "Tweak_NormalMove(RespectPolygonNormal)":-
Base model


No Hard_edges, tweak made:


Auto_hard_edges @ 30. Tweak made


All hard_edges. Tweak made:


Result from Wings3D (polygon > move > Normal)


Please check when you can find time.

Thanks,

Try this
http://www.digitalfossils.com/Download/NVil-Aug-15-14.rar

Normals will be grouped by smooth setting. After that normals will be grouped again so normals which are close to each other enough(less than 1 degree) will be grouped as one normal. If the number of final normals is more than 3, there is no way you can get correct result.

Hi IStonia,

The results I see are now correct for the examples above.

If the number of final normals is more than 3, there is no way you can get correct result.

Other modelers I checked do not appear to have an issue.

Quick example.
Nvil: "Polygon_LocalMove_PolygonNormal"
Calculations for polygon normal movement are quite a long way off.



Wings3D: "Polygon > Move > Normal"
Correct



Silo: Polygon > LocalMove
Correct

try this
http://www.digitalfossils.com/Download/NVil-Aug-17-14.rar

Your last example is a special case in which 4 normals can be divided by a symmetry plane with two normals on each side. There happens to be a solution for this.

Hi IStonia,

Your last example is a special case in which 4 normals can be divided by a symmetry plane with two normals on each side. There happens to be a solution for this.

In that case yes, it does have a symmetry plane, but there are many time such a symmetry plane would not exist, or there may be more than 4 surface normals to take into account.

I know various other applications have problems with "local move polygon normals" or do not even have such an option/tool and instead use only vertex normal movement. But as Nvil does have such a function/tool, I was hoping for better implementation/calculations.

An example:-

Nvil:-
Polygon movement made with "Polygon_LocalMove_PolygonNormal". Some movement based on polygon normals, but some based on vertex normals. So result incorrect.


Wings:-
Polygon movement by polygon Normal. Result correct.



I could and will just put this down to a limitation due to implementation in Nvil, but it is possible to get better results.

The method Wings uses is choosing some polygons and ignoring the rest. So the result is actually partially correct. You may have noticed that the algorithm it uses has its own problem.


Try this
http://www.digitalfossils.com/Download/NVil-Aug-24-14.rar

I use similar idea. Hopefully it works better.

Hi IStonia,

Many thanks for the new build.

The method Wings uses is choosing some polygons and ignoring the rest. So the result is actually partially correct. You may have noticed that the algorithm it uses has its own problem.

I have not looked at the code used. I do know there are various issues with Wings, but the majority of the time the results look correct. With poly modeling I do not expect high precision output from tools/functions. If it looks OK, then it is OK. It is just that with Nvil the results did not look OK the majority of the time.

Try this

I use similar idea. Hopefully it works better.

On quick tests, that is looking excellent.

Many thanks.