E.Normal

[xplane80]

What is e.normal now because I'm confused? It's not what it should be. so what is it!

[Paradigm 29]

It seems to be that when you use a laser to find the normal of an object that the side of the object that you are hitting with the laser affects the normal of the object. Therefore, you're going to have to get used to it and make some work-arounds until they fix it. It's still useable, but be prepared to bend over backwards first.

[xplane80]

ok thanks anyway. I was just trying to make a Probe uses lasers but I couldn't get e.normal to work

[KarateBrot]

It's explained here
http://en.wikipedia.org/wiki/Surface_normal

so if you have an event and you call e.normal it will give you the normal vector. in algodoo the normal is in the wrong direction sometimes. you maybe can correct this by reloading the scene and it should work. if it's still in the wrong direction you have to use "(-1)*e.normal" instead of "e.normal" and it will work.

[Joel]

Could you please explain when the normal is wrong? I have tried to reproduce the flaw you are describing without success. Step by step instructions to how you got the bug would help a lot.

[admin]

The thing here is that that the surface normal indeed can be defined in two different ways, either relative to the first body or relative to the second body, and there is no real physical difference since contact forces in the end will be correct anyway since they have the corresponding definition.

This is usually very consistent, but it could happen that sometimes Algodoo reallocates its memory and changes order of bodies, and then the definition of e.normal might flip. My guess is that the flipping can occur when you save a scene to file and then reopen it again. Does it also happen at other times?

This should never affect any of the simulations, but I can imagine that it affects scripting (in fact, it can affect the simulation somewhat since changing order of bodies will give differences in the solver, and thus in the 4th or 5th decimal of forces, and that will indeed give some small differences). Perhaps you can use the direction of the normal contact force instead of e.normal in your script? (to be honest, I have to check if that is possible since I haven't used thyme for a while).

[standardtoaster]

The thing here is that that the surface normal indeed can be defined in two different ways, either relative to the first body or relative to the second body, and there is no real physical difference since contact forces in the end will be correct anyway since they have the corresponding definition.

This is usually very consistent, but it could happen that sometimes Algodoo reallocates its memory and changes order of bodies, and then the definition of e.normal might flip. My guess is that the flipping can occur when you save a scene to file and then reopen it again. Does it also happen at other times?

This should never affect any of the simulations, but I can imagine that it affects scripting (in fact, it can affect the simulation somewhat since changing order of bodies will give differences in the solver, and thus in the 4th or 5th decimal of forces, and that will indeed give some small differences). Perhaps you can use the direction of the normal contact force instead of e.normal in your script? (to be honest, I have to check if that is possible since I haven't used thyme for a while).

That's good to know. BTW I fixed you spelling mistake.

[KarateBrot]

there is no real physical difference since contact forces in the end will be correct anyway since they have the corresponding definition.

there is a difference with the direction of e.normal sometimes. for example if something gets values about its angle and reacts on this angles. with the wrong e.normal it reacts wrong because the angles are shifted about 180°.

if you want to watch/work on scenes in algodoo that were made in phun everything is screwed up if it's a different direction.