Talk:Blender 3D: Noob to Pro/Coordinate Spaces in Blender

Must not, may not, need not?
I've written in the original text:
 * The origin of the the local coordinates is called the center of the object (which must not necessarily be in the center of the object). 

Someone corrected me and wrote:
 * The origin of the the local coordinates is called the center of the object (which may not necessarily be in the center of the object).

Well, what I want to say is, that the object center may be in the center of the object, but it isn't necessarily the case. The object center may be anywhere. So who can put this right? --SoylentGreen (talk) 15:54, 18 March 2009 (UTC)

I think it's confusing because it's called object center, and that's not really what it is. "The origin of the local coordinates is called the rotation axis; it can be located anywhere." would make it clearer to me. --Wgoelkel (talk) 00:13, 5 April 2009 (UTC)
 * No, the rotation axis is something different. The object center is a point (0 dimensions), an axis is a line (1 dimension). So it's just what it is - "the center of the object is the origin of the local coordinates". Nothing more and nothing less. --SoylentGreen (talk) 16:00, 5 April 2009 (UTC)


 * Good point. How about: "The origin of the the local coordinate system is called the object center. It can be located anywhere, inside or outside of the object."
 * A little variation: ""The origin of the the local coordinate system is called the object center. It can be located anywhere, e.g. in the gravitational center of the object or even outside the visible mesh."
 * I find it difficult to describe, because the term object has in Blender several meanings, and you have to be completely aware of the context in which the term is used. A visible object like a cube has at least two parts:
 * a data structure that holds the position/rotation/scale of the object
 * a mesh data block that contains the position of the individual vertices.
 * Often beginners say "Object" and mean only no. 2, whereas a more advanced user always thinks no. 1 together with no. 2. --SoylentGreen (talk) 05:39, 6 April 2009 (UTC)


 * I've seen where other programs refer to it as a Handle point. Meaning that if you were to pick up, or manipulate an item, you'd do so with it's handle.  Is there anything tying us down to using a reference to "sometimes non centered center point"?  Now, if that center point is the center of the Bounding box, I could see it being called that, but otherwise, it's simply not a center at all unless you decide to rotate the object with it.  "Object Origin Point" (vs. World (or global) Origin Point, as you mentioned here) seems more informative in an associative definition, and more accurate under all conditions, rather than a single operation.--Deadguy (talk) 15:59, 24 August 2009 (UTC)

Invisible grandparent
From the article: ''In Fig. 1b the cup is a child object of the right coordinate cross. The child itself has no local rotation. The right coordinate cross has itself an invisible parent. It is parent and child at the same time. The right coordinate cross is rotated along its global Z axis, the tilt against the world axis is created by the invisible grandparent.''

Isn't the tilt caused by the tilt of the parent, regardless of whatever caused it to tilt? I think perhaps it should stick to that, perhaps including the suggestion that the parent may also be the child of another parent, whose movements may affect all of it's attached children, and their children. The concept of introducing invisible grandparents when everything else they run into is likely to refer to parents and children might confuse the issue.

I understood the concept before I read it, and had to look at it for awhile to understand how a third party was at work on the rotation shown, as opposed to a straightforward rotation. If this were a new concept, I'm not sure I would have followed well enough to understand that the invisible grandparent was more of a "it could be" scenario, and instead would have moved-on thinking I'd try and figure-out the impact of that tidbit later-on if I saw it again.

Great article though.. --Deadguy (talk) 16:14, 24 August 2009 (UTC)
 * You are probably right. Is it sufficient to change the text, or should the image also be altered? If changing the text is enough, would you like to do it? --SoylentGreen (talk) 04:34, 25 August 2009 (UTC)

Surface Normal Description
In the section "Normal coordinates" you say that the normal "is always perpendicular to the surface" (which fits with my previous encounters with the term), but later say that for edges "the normal runs along the edge".

This runs counter to my previous 3D experience, and also contradicts the earlier definition. Surely, the normal on an edge is the average of the normals of the faces on either side ? Unless Blender users the term in an odd way. --Alun (talk) 10:28, 7 November 2009 (UTC)


 * I removed the claim, which seems highly unlikely. I'm still looking for evidence that Blender uses "normal coordinates" in any context.  I think the key concept here is "normal", which should be explained in a different module. --Stepheng3 (talk) 14:37, 21 October 2010 (UTC)

Normal Coordinates (!?!!?)
The last section begins "Although Blender is a 3D program, only the faces are visible." I'm guessing this is detritus from previous edits. I can't make sense of it, so I'm not sure what concept it is supposed to introduce, so I can't suggest a better wording. Maybe just remove it?

More importantly, is there such a thing as "Normal coordinates"? The normal is a (calculable) property of the vertex/edge/face, not a distinct entity. Maybe fig.4 should show only the blue arrows, as the red and green ones aren't relevant to any process in the rendering pipeline [are they?] -- normal is a 1D concept by definition, and only need to be 1D for the various purposes they are used (in the rendering pipeline); showing them as coordinate crosses is somewhat confusing, if not misleading.

Maybe the last section should be entitled "Normals", if the concept really needs to be introduced here at all(?) -- I suspect this section is/was/tried-to-be about explaining hidden surface removal w.r.t. surface normal direction relative to the viewport plane. (Quite a few years since I studied 3D CG under Alan Watt, so maybe memory-fade has resulted in me talking utter nonsense here.) Zoinks (talk) 17:34, 26 October 2010 (UTC)

Personnally my problem is with "The normal of a point is the average of normals of the adjacent faces". My conclusion is that what you meant is : "The normal of a point is the average of normals of the adjacent 'points' " (Zigomar (discuss • contribs) 21:25, 20 October 2011 (UTC))


 * No, I think the original wording is correct. Finding the normal of a planar face could be done by taking the cross product of two edges. The normal of a point (points have no direction) would actually refer to any vector (all vectors are perpendicular to zero vector). When specifying the normal to a point for something like http://en.wikipedia.org/wiki/Gouraud_shading, you'd take the average of all adjacent faces. The vertex in this case is supposed to represent a point on a curved surface, which would have an exact normal vector if represented mathematically, but the digital representation means it can only be approximated by looking at surrounding faces. That's my beginner's understanding, anyway. I don't know what's meant by "Although Blender is a 3D program, only the faces are visible.", though.