I’m trying to understand normal transform orientations.
Look at the two attached images, in the first one I have selected a group of faces on a rotated object and the transform manipulator nicely aligns with the faces. From here it’s easy to do extrudes and other transforms.
In the second image I have only selected the edge of a single walled object. What I don’t understand is what the manipulator is doing. It’s showing global coordinates in a situation when I need a coordinate system that aligns with the loop I wish to manipulate. Yes I can extrude the edge / scale it a small amount and then use the resulting faces to get the orientation I need, but that sure is clumsy.
Shouldn’t the manipulator in this instance use the selected vertex normals and align to them?
Or, what is it I have forgotten, or have missed? :eek:
A little more research shows that you only get the normal orientation for vertexes when no more then 3 vertexes are selected. The empty is there as a point of reference.
Image 1: 3 vertexes selected - the widget is nicely aligned with the selected vertexes.
Image 2: 4 vertexes selected - note how the “normal” based widget is aligned with the empty which is on Global coordinates.
Someone please tell me what I don’t understand here.
So, should I post this as a bug, or will I end up feeling like an idiot within minutes of doing so?
This is my ONE frustration with being a Blender user, I run into situations where I either cannot find information on how an item is INTENDED to work, or the purpose of the existing tool cannot really be explained.
Is the normal manipulator SUPPOSED to switch to global space when more then 3 vertexes (or 2 edges) are selected? If so, why? It’s a very annoying behavior when one is doing extrudes. This directly effects the speed I can model at, so I REALLY am interested in some form of answer.
I’ll be happy to post a bug report if anyone will give me the confidence to do so.
Hi, pappy, what version of Blender are you using ? I tried the same examples here on my laptop with 2.44 …
Well actually I can maybe explain the second example you posted with the vertices … Normals are calculated using faces not edges normally (:p) . When you have three verts (enough to form a tri) you have enough data that Blender can calculate to form an accurate normal data, but when you add another point (even if it is co-planer with the other points) but it doesn’t actually form a face the normal data can be off just because you don’t form an actual face (and even if you do convex/concave quads within certain tolerances are allowed and the normals for those can be off also - tris are the gold standard for calculating normals) …
And as for your first examples … look at the 3D header on the cylinder edge normal selection example screenshot … You have the 3D widget aligned to the Global coordinates … not Normal … not sure if that was an oversight when you edited your post, but I couldn’t duplicate the same issue on 2.44 or on an SVN buid …
I updated the second image. Too much of a hurry the first time.
Running todays SVN built on my ArchLinux laptop with scons. Same results with my primary development desktop running ArchLinux also.
There are no faces in my third example, yet the widget is nicely aligned. ??
So your normals orientation does work beyond 3 verts? Can you extrude a circle that has been rotated off global axis, and have the extrusion constrained so it creates an even cylinder? - I can’t.
There are no faces in my third example, yet the widget is nicely aligned. ??
So your normals orientation does work beyond 3 verts? Can you extrude a circle that has been rotated off global axis, and have the extrusion constrained so it creates an even cylinder?
Well I guess I didn’t explain myself clearly … in your third example you have three verts selected which is enough to form a triangle and the combined average of the vertex normals is enough to get the widget to align properly … in your fourth example the fourth added vertex might not be coplaner with the other vertices giving you the off set in the widget . You can get a “proper” alignment in the last case by converting the vertices into a face .
And in the case of a circle composed of verts and edges and then rotated … no the vertex normals do get all wonky relative to each other … but then again they don’t have any other reference points other then each other, and so you get the offset normal widget … note that this doesn’t happen with the circle when it is first created no matter how arbitrary the user view the circle is created in, the widget is aligned properly, it is only when you rotate it afterwards and the vertex normals are recalculated (to view ? camera ? ) … And like I said if the circle is filled with faces there is enough data for the normals orientation to be properly aligned (and if you need an open circle for some reason you can just delete the central vertex later) …
But your second example is the one that stumps me … The normals should be calculated properly based on the side faces of the cylinder … And I can’t duplicate the same problem here on 2.44 on windows … Perhaps this is a bug with the the “crazy space bug” fix … Edit : I just downloaded today’s SVN and I did get the same problems as your second example with the build version … but it only happens with manifold edges not with faces proper … but hope they fix this soon … could be an issue with holes in meshes like eyes …:spin::spin::spin:
But your second example is the one that stumps me … The normals should be calculated properly based on the side faces of the cylinder … And I can’t duplicate the same problem here on 2.44 on windows … Perhaps this is a bug with the the “crazy space bug” fix … Edit : I just downloaded today’s SVN and I did get the same problems as your second example with the build version … but it only happens with manifold edges not with faces proper … but hope they fix this soon … could be an issue with holes in meshes like eyes …:spin::spin::spin:
There’s a lot more then eyes this effects. Try building a saxophone with MANY small extruded pieces that are off the local or global axis. Eyeballing the “straightness” in view mode of each part gets old quick.
So, is this a bug? I haven’t seen it in the bug tracker.
Well the cylinder edge selection thing seems like a bug to me … this doesn’t happen in 2.44 only on the SVN build … the normals should be properly aligned because you have adjacent faces to help calculate the normal direction, but they don’t in the SVN build … and even the vertex normals are pointing at the proper direction too …
The edge/verts examples you posted I can reproduce in 2.44 . And as far as I can tell the vertex normals realign when you arbitrarily rotate them in Edit Mode (maybe to the orientation of it’s object space ???) … But once you actually create a face out of them the widget aligns as expected … even with more arbitrary rotations added …
You might just have to temporarily create faces for those manifold edges with E->S->0->W->Remove Doubles to get normals that point properly after a rotation . Then just delete the center vertice if you need to later … Or get an earlier version to do the modeling …
So, is this a bug? I haven’t seen it in the bug tracker.
Well not everybody uses manifold edges to model … least of all in an SVN build, usually most people get those just for the new features … I do remember that for the next release they had fiddled with the orientation matrix to fix the “crazy space” problem (the widget remaining at the object’s non-modified position even though the modifier is turned on in Edit Mode - like say with the armature modifier … ), so maybe something was tweaked that shouldn’t have been ? But the cylinder edge select transform orientation is definitely not behaving like it should in the SVN build …
(I completely agree with you).