Hi xcx, you will need to get the facenormals of the surrounding faces and average them by adding them all together, then dividing by the number of faces and then normalize the result. As far as I know there is no direct way to get it, but you can easialy make this into a function. Beware though that some vertices might not have any faces. In that case I believe the normal will be aligned to the objects transform.
CML
Tryed that one, but normals seems to be wrong. Anyway your idea sounds working so problem is propably in my code. So here goes.
vertnormal = 0.0
-- Get vertex selection from first object at selection array
verts = getVertSelection selection[1]
-- Get all faces where first vertex in selection array is accosied with.
faces = polyop.getFacesUsingVert selection[1] (verts as array)[1]
-- Convert bit array to array
faces = faces as array
-- Loop all faces what are accosied with vertex
for i in 1 to (faces.count) do
(
-- Add face normals to vertex normal
vertnormal = vertnormal + (polyop.getFaceNormal selection[1] faces[i])
)
-- Divied vertex normal with count of faces
vertnormal = vertnormal / (faces.count)
-- Normalize
vertnormal = normalize vertnormal
Any bugs or did I make something wrong?Antti,
Try this:
(
local sel = selection[1]
local vertFaces = polyOp.getFacesUsingVert sel (polyOp.getVertSelection sel as array)[1]
local tNormal = [0,0,0]; for i in vertFaces do tNormal += polyOp.getFaceNormal sel i
tNormal / vertFaces.numberSet
)
Light
A few things I’d like to add to lights example:
When you use polyOp.getFaceNormal sel i you will get the normal in the objects local coordinate system wich is at least not what I usually want. To get it in world coordinates instead write polyOp.getFaceNormal sel i node:sel .
Also the normal you get from the example is pointing in the right direction but it’s not normalized(length=1) so I suggest you normalize it afterwards too to make it a “true” normal. This is important if you as an example want to move the vert 10 units along the normal you can say newpos = vertpos + (thenormal *10) , but only if the the normal is normalized.
cheers,
CML
Rivendale,
I think there is no point in telling that the returned normal is in local coordinates since it solves his problem obviously.
FYI polyOp.getFaceNormal ALWAYS returns a normalized vector.
Light
Light - I’m sure he has no problem with getting more info, maybe he wants to compare the normal to the view or something. That would seem to work…until he rotates his object. Things like this is good to know imho.
FYI polyOp.getFaceNormal ALWAYS returns a normalized vector.
yes it does, but after you add them up and divide you will NOT get a normalized normal. If he tried to move with a unnormalized normal it would seem to work but the results would not be accurate.
I always used the returned vector without normalizing and never encountered a problem regarding accuracy.
It is OK if you want to give more info, but please don’t post after every message I post regarding my message as if you have to. I feel like being chased 
Light
Erm ok…I suggest you try it and check the resulting vector, then normalize it to see if it’s different. I didn’t mean to make you look bad or anything.
edit: Just to explain. In my example with moving the vertex, if the vector had not been normalized it would not move the vert 10 units but maybe 8.5, 9.3 something like that since the length of the normal would not be 1. That might seem to work when you look at it but it’s not accurate.
(
local sel = selection[1]
local vertFaces = polyOp.getFacesUsingVert sel (polyOp.getVertSelection sel as array)[1]
local tNormal = [0,0,0]; for i in vertFaces do tNormal += polyOp.getFaceNormal sel i
tNormal / vertFaces.numberSet == normalize (tNormal / vertFaces.numberSet)
)
true
OK
Light
Make a box, select one of the corner vertices and run that code again. If you’re on the same planet as me that should return false.
CML
I have tested it on a plane object and got those results. I think it is valid for the test.
Light
Here is the result of testing with a box:
(
local sel = selection[1]
local vertFaces = polyOp.getFacesUsingVert sel (polyOp.getVertSelection sel as array)[1]
local tNormal = [0,0,0]; for i in vertFaces do tNormal += polyOp.getFaceNormal sel i
local t01 = tNormal / vertFaces.numberSet
local t02 = normalize (tNormal / vertFaces.numberSet)
format "My vector: %, Your vector: %
" t01 t02
)
My vector: [0.333333,-0.333333,0.333333], Your vector: [0.57735,-0.57735,0.57735]
OK
Both vectors’ direction are THE SAME, the only difference is their magnitude. So if you are making any operation using these normals, there shouldn’t be any problem unless it is related to magnitude.
Light
The reason it works on a plane is that all the faces of the vert is pointing in the same direction. Anything else than that will return false. Good luck to you.
Btw- were you not from another country a while back?
Guys, don’t tell me I need to close this thread because of some stupid function called normalize? If you can’t agree on the subject, leave it be…
Well Martijn, sorry for the bickering. I’m trying to help the initial poster or anybody else who is interested in getting a vertex normal.
Light- That normal you are getting without normalization is not usable in mathematical functions like dot product,cross product, calculating matrices or any stuff like that. Can’t you see I’m trying to help? I guess your not going to admit you could learn anything from me though since you view me as the competition.
Well Rivendale, judging from your messages it is obvious you don’t intend to teach me something in the first place as can be seen with your previous messages that follow mines by commenting on them.
Maybe you are proofreading my messages, but let me say “No thanks!”
Light