[Dev discussion] Movment sensor

there are cases where a actor should animate, or a prop should do code checks only when moved, collision covers some cases, but not all

we need an is moving sensor, that detects momentum and change in position, with a threshold and a any axis, vs local x, y,z switch.

seems like it would be pretty easy to impliment,

Please start using [request] monikers for your threads (as the current one might give someone the impression that you are one of the BGE devs. with C++ knowledge).

Based on your past feature ideas, this one is suprisingly down to Earth and may not even be that complex to implement. Though I would add a time variable so it can also be used to sense sudden impacts from other physics objects.

if this were implemented as a sensor, would it be much more cost effective(logic and cpu) than using an always and collision sensor connected to a changed position/hitobject script(with a few lines for threshold)? just curious.

what if I move a actor with forces?

collision->ground is a thing as well (always sensor basically)

I am planning on a system, where the actors movment and actions are based on a state machine, but the animation has a infinite state machine and handles transitions, however I want to be able to leave a actor idling and then if they suddenly fall, play a fall animation, or anything where they change position, evaluate and play a anim.

I can do it now, however it’s costly to poll, always----------python

Indeed this is a reasonable request.

While it is not that difficult to detect the current velocity [via getLinearVelocity()] it is not simple to detect changes towards that value. Currently it is unnecessary complex to detect velocity changes or the forces of an impact.

I suggest such a sensor not just measure that there is a motion, but to measure the change in motion.

How about these modes:

Mode “Speed” [quite similar to the near sensor]
“Speed” float -> sensor triggers and gets positive if the speed (length of the velocity vector exceeds this value) exceeds this value
“Reset Speed” float -> sensor triggers and gets negative if the speed falls below this value

Mode “Acceleration”

“Acceleration” float -> sensor triggers and gets positive if the speed difference (relative to the previous frame) exceeds this value
“Reset Acceleration” float -> sensor triggers and gets negative if the speed difference falls below this value.

Mode “Direction”

“Angle” float -> sensor triggers and gets positive if the direction difference(relative to the previous frame) exceeds this value
“Reset Angle” float -> sensor triggers and gets negative if the direction difference falls below this value.

Mode “Impact”
I’m nor sure if something like an “Impact” mode is possible. The idea is to get the forces that point away from the previous forces.
But let me go into this a bit further.

You can’t measure an impact just on the speed. As you would not detect if the object makes a sudden 180° turn (the speed remains the same). This could be measured by comparing the “potential” position that would happen without the impact to the calculated position. I’m sure there is a formula for this.

The next issue is, what if the object is rotating. In real world the rotation could damp (or increase) the impact as it changes the velocity of the colliding faces. I do not know if Bullet can provide this information. At least it must have calculated that at some point. Otherwise the reaction on the collision would not be visible.

Just some thoughts

I want this to.To make npc’s walk realistically.

yeah, all of that makes sense monster.

Yep, it looks to me like a quite interesting request.

@Monster: modes are a good idea IMHO, but I wonder about “Impact”: why wouldn’t a collision sensor suffice in this case?

What if you are hit from 2 equal and opposite directions?

then you don’t get a change in acceleration, you need the impact data to be fed to the sensor, a ‘Knock’ sensor

Simultaneity kinda never happens…

But still, what would you then use the resulting info for, if there is no change in acceleration?

EDIT: and then, in the opposite way, if collision and no acceleration change -> been hit with two opposed forces (case of massless object is not possible).

what I’m trying to explain in the first EDIT is that IMHO all those cases can be covered using an existing Collision Sensor + a newly implemented Acceleration Change Sensor:

  1. no collision
  2. collision and acceleration change (-> force)
  3. collision but no change in acceleration (up to a certain threshold) (-> equal forces with opposite direction, or masses ratio is too big)

(not sure this second EDIT clarifies things, maybe it’s even more confused now…)

I wouldn’t know, but it seems like there should be a way to detect this with python. Is there?

sensors are like callbacks, they don’t poll,

meaning they only trigger a script when a condition becomes true.

Polling object.worldLinearVelocity every frame for every actor is a idea, but not a good one.

That’s not the reason it’s better to use a sensor. The sensors themselves still poll the state some where. It’s not that expensive to do a simple vector subtraction and length calculation. It’s better to use a sensor because it allows controllers to be used to filter the state

yes, these tasks are still done somewhere,

in bullet at the c++ level will be faster though correct?

also, the actual added impulse per collision per frame is not availible in the game engine unless we grab it from bullet correct?

(to equal and opposite physics impacts are impossible to detect currently without polling all objects involved in the collision?)

Bullet doesn’t include notifications of moved bodies (besides the motionstate), so it’s not a bullet-specific feature. It’s just as easy to compare with previous state values.

It would be faster, but not a bottleneck. Only the SCA interface provides a useful case to implement this in C++.