Get vertex normal from Editable Poly

#7

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

#8

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

#9

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.

#10

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 :wink:

Light

#11

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.

#12 
(
	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

#13

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

#14

I have tested it on a plane object and got those results. I think it is valid for the test.

Light

#15

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

#16

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?

#17

Well that is exactly what I was saying! Read my posts again dude, you are too much

#18

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…

#19

I moved to Canada, but the question here is: what it is to you?

Light

#20

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.

#21

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

#22

Well it has not happened often but it’s kind of hard not to post in threads you do since you spam every other thread in the maxforum about your tools. I guess you are upset about yesterday when I posted that PolyBoost too will have a tool that Orionflame will have, and that the PolyBoost tool eliminates the need for cleanup afterwards. I guess you think that made you look bad. Well tough luck, I even gave you a hint on how you could solve the problem, something wich I really didn’t need to do.

Btw where is DentonvanZan or any of the other aliases you’ve used to bash PolyBoost and praise yourself and your tools? Would you like to answer this question?

Getting ready for thread closure…

#23

Knock it off guys.

#24

Seriously guys, you two need to sort out your issue with each other. This has been going on between you for how long now? You’re both great coders, and this sort of fighting is pointless.

I only came in here becasue I got the shock of my life seeing Leigh in a maxscript thread! I thought she’d converted to programming!:surprised

#25

I guess I find it hard to treat Light nicely after what he has done in the past but I’m going to try not to bother from now on.:shrug:

CML

#26

Go do the new maxscript challenge to get your mind off it! :slight_smile: