PDA

View Full Version : IF it existed....: "Poly Normal Move"???

jeric_synergy
07-27-2014, 06:45 PM
IF the tool "Poly Normal Move" existed (besides RMB "Move Plus"???) would it differ from Point Normal Move?

Or is the math absolutely equivalent?

JoePoe
07-27-2014, 07:25 PM
Isn't that what RMB Move Plus is? That's how I've been thinking about it at least.

And yes it's different.

jeric_synergy
07-27-2014, 07:30 PM
So, the poly normal is not the average of the point normals? I guess that makes sense in a recurve situation.

JoePoe
07-27-2014, 07:37 PM
Well wait a sec.... I think it is the average. But that's a difference in the math like you asked in the op.
We have both options for shift inside the one Multishift tool. Average Point Normal (which is the same as normal moving a single poly), and plain ol' Point Normal. There's also Average Poly Normal.... but that comes into play with, u guessed it, multiple polys.

jeric_synergy
07-27-2014, 07:44 PM
I guess I should phrased that more mathaformally:

For any given valid poly
is the poly normal
the average
of the constituent
point normals?

Huh, near poetry.

I'm using 'valid' here as shorthand for "planar". I guess it's not that much shorter.

JoePoe
07-27-2014, 07:47 PM
Practically a haiku! :yingyang:

Wellllll... I can't give you a mathematical proof.... but that has been my assumption lo these many years. :D

spherical
07-27-2014, 08:31 PM
For practical purposes, one could assume that they are equal. Taking the case of an extreme n-gon, where there are a cluster of points pretty much equidistant from each other and one or two points way far off from the center of that cluster, the move may not end up in the same location. Academic, otherwise.

jeric_synergy
07-27-2014, 09:16 PM
I was recently trying something....

Use the Ball tool to make a level2 tessalation ball
delete two adjacent tris, base to base
select the Edges around the hole

At that point I was trying to use the new Transform tool but couldn't get it aligned to the apparent cumulative normals of the hole.

SHOULD I be able to do that?

JoePoe
07-27-2014, 11:09 PM
For practical purposes, one could assume that they are equal. Taking the case of an extreme n-gon, where there are a cluster of points pretty much equidistant from each other and one or two points way far off from the center of that cluster, the move may not end up in the same location. Academic, otherwise.

I'm not sure to which statement you are referring when you say "they are equal".
Poly Normal move equals Point Normal move, or, that a poly's normal is essentially equal to the average of it's point normals?

spherical
07-27-2014, 11:37 PM
Well..... in the context of this... exercise, aren't those two options themselves equal? IOW, in the case of non-extreme polys, an example of which I cited, the point normal average would roughly equal the vector of a poly normal. The differences between the two results would be difficult to quantify.

Kryslin
07-28-2014, 10:23 AM
Actually, I think it's the opposite - the point normals are the average of the polygon normals that the point makes up.

A point, by definition, cannot have a surface normal, that being a property of a surface or solid (specifcally, a planar surface - since everything in CGI ceoms down to triangles, a normal for that micro-triangle on that NURBS surface patch can be computed. Triangles cannot be non-planar, by definition)

You need at least 3 points (A,B,C) to make the 2 vectors (AB, AC) to compute the surface normal (N = AB x AC , x denoting the cross product of the two vectors).
(*edit* The point order is also important - taking points in a Clockwise order around the polygon will yield a different result than CounterClockwise. I believe LW uses CCW winding.)

However, if all you have is derived point normals, the average of them should be the polygon's normal in most cases.

JoePoe
07-28-2014, 04:49 PM
Actually, I think it's the opposite - the point normals are the average of the polygon normals that the point makes up.

A point, by definition, cannot have a surface normal, that being a property of a surface or solid (specifcally, a planar surface - since everything in CGI ceoms down to triangles, a normal for that micro-triangle on that NURBS surface patch can be computed. Triangles cannot be non-planar, by definition)

You need at least 3 points (A,B,C) to make the 2 vectors (AB, AC) to compute the surface normal (N = AB x AC , x denoting the cross product of the two vectors).
(*edit* The point order is also important - taking points in a Clockwise order around the polygon will yield a different result than CounterClockwise. I believe LW uses CCW winding.)

However, if all you have is derived point normals, the average of them should be the polygon's normal in most cases.

Aha! Well that makes more sense doesn't it. And it supports the empirical evidence to a T (well at least I think so :stumped:). The distinction may in fact may be academic fodder but the practical implications are more "real world" within our virtual reality :D.

Well..... in the context of this... exercise, aren't those two options themselves equal?

No. Poly Normal Move and Point Normal Move are quite different animals and in most cases yield different results. A lot of times very different.

...Taking the case of an extreme n-gon, where there are a cluster of points pretty much equidistant from each other and one or two points way far off from the center of that cluster, the move may not end up in the same location.

Sure, a single poly is a single poly, n-gon with crazy points or not, it'll move the same by points or poly normal.
It's all about what the poly is connected to (as Kryslin has pointed out :thumbsup:)!
Within a mesh, I can only think of a couple special situations where there would not be a difference.
1) A single/cluster of flat polys within a bigger perfectly flat section of polys.
2) If one is trying to Normal move an entire object.
Another case where there would simply be a less noticeable effect would be...... as the mesh gets denser and the selection set gets smaller. But still, a larger selection on a dense mesh will show the difference again. And even a single poly on a corner or edge will have a different reaction to the two action types.

simple object... 123315 Poly Normal Move 123316 Point Normal Move 123317...And that's just to start, there are more options in Multishift.

jeric_synergy
07-28-2014, 07:54 PM
So, Points making up a 2point poly do NOT have a point normal?

Empirically this seems to be the case, as PNM has no effect on a point in a 2point poly.

(While mathematically correct, it seems that as a tool, a convention that said "in the case of points comprising a 2point poly, the point normal is the same as the vector the poly describes." This would be convenient in that sizing would happen when using PNM, instead of nothing. --Awaiting pushback from the mathematicians out there.

I don't think we should let mathematics prevent us from being productive.

“A foolish consistency is the hobgoblin of little minds..."

spherical
07-28-2014, 08:47 PM
Poly Normal Move and Point Normal Move are quite different animals and in most cases yield different results. A lot of times very different.

Yes, with what Kryslin cited, easy to see that they would be different, due to surrounding polys influencing the point normal vectors; not the other way around.

The "two options" I was referring to were quantified: (Poly Normal move equals Point Normal move) and (a poly's normal is essentially equal to the average of it's point normals). They're equal to each other in the fact that they both aren't equal within themselves; the latter now having been shown to be incorrect is icing on the cake. Bad logic joke—I know. No wonder no one got it.

Nothing to see. Move along.

JoePoe
07-29-2014, 08:46 AM
Happy to have helped.

Kryslin
07-29-2014, 10:57 AM
So, Points making up a 2point poly do NOT have a point normal?

Empirically this seems to be the case, as PNM has no effect on a point in a 2point poly.

(While mathematically correct, it seems that as a tool, a convention that said "in the case of points comprising a 2point poly, the point normal is the same as the vector the poly describes." This would be convenient in that sizing would happen when using PNM, instead of nothing. --Awaiting pushback from the mathematicians out there.

I don't think we should let mathematics prevent us from being productive.

“A foolish consistency is the hobgoblin of little minds..."

And with a little math, we could probably figure out a way to generate a normal vector for those 2 pt. poly chains (aka polylines).

If you treat a 2 pt. polychain as an infinitesimally small plane, it's trivial - but which direction do you use to compute your offset points?

It gets even better if you treat a 2pt polychain as a infinitesimally small cylinder. Tangents and normals are a bit of math away... (RI_Curves primitives in Renderman® work this way, from what I've read on the subject. It's what makes them useful for hair and fur.)

However, your idea is a good one.

jeric_synergy
07-29-2014, 06:56 PM
:D I think the effect of " a 2pt polychain as a infinitesimally small cylinder" is for practical purposes what I suggest as a convention.

Amurrell
07-30-2014, 04:44 AM
I don't know about the math, but I use the transform tool to move along the poly normal.