Support for Collision.hitPosition Leveraging Sybren's Collsion callback physics code #44051

New Issue

Jacob Merrill · 2015-03-20T01:28:08+01:00

Jacob Merrill commented

2015-03-20 01:28:08 +01:00

Proposal - Add Collision.hitPosition

Abstract -
Currently the ray sensor has

Ray.hitPosition

We have the new contact point callbacks, and the points are visible in the physics view mode in the game.

if this code could be leveraged to add collision.hitPosition

this would be easier for most to get the hang of, then a callback, as well as match the existing API.

Ps. While in this area, if it would also be possible to investigate collision.hitImpulse
to list the force of impact as a vector using the collision sensor?

with the two systems you could localize damage to a actor, using python.

Car hit bumper with collision.hitImpulse.magnitude

also some things are damaged when forces are not in line with a axis.

Proposal - Add Collision.hitPosition Abstract - Currently the ray sensor has Ray.hitPosition We have the new contact point callbacks, and the points are visible in the physics view mode in the game. if this code could be leveraged to add collision.hitPosition this would be easier for most to get the hang of, then a callback, as well as match the existing API. Ps. While in this area, if it would also be possible to investigate collision.hitImpulse to list the force of impact as a vector using the collision sensor? with the two systems you could localize damage to a actor, using python. Car hit bumper with collision.hitImpulse.magnitude also some things are damaged when forces are not in line with a axis.

Jacob Merrill commented

2015-03-20 01:28:08 +01:00

Changed status to: 'Open'

Sybren A. Stüvel was assigned by Jacob Merrill

2015-03-20 01:28:08 +01:00

Jacob Merrill commented

2015-03-20 01:28:08 +01:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2015-05-04 05:41:57 +02:00

Side note, could this also add .hitPosition to Near and radar sensors since they use collision anyway?

Sergey Sharybin commented

2015-05-18 14:17:19 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2015-05-18 14:17:46 +02:00

Added subscribers: @Moguri, @hg1, @brita, @dfelinto

Angus Hollands commented

2015-05-24 23:57:20 +02:00

Added subscriber: @AngusHollands-4

Angus Hollands commented

2015-05-24 23:57:20 +02:00

I'm not sure if we should support feature request without any reference or acknowledgement of the code base for fear of simply overloading ourselves with everyone's personal requests. Any ideas?

Jacob Merrill commented

2015-05-25 02:12:15 +02:00

I suppose it would be better if users were to put all feature requests in a bottle, and imbide it rectally?

Angus Hollands commented

2015-05-25 03:10:07 +02:00

No, I think that would be unhealthy ;)
There is already some discussion in addition this code to the logic bricks. However, I personally noticed that the information available isn't intuitive. Bullet creates contact points for intersections, and determines their impulse based on a number of factors, which doesn't seem to agree with substeps. Essentially it doesn't seem easy to determine the hit force, or impulse over a collision so that we can compare collision strength - Its not reliable. Furthermore, we only return one contact point at the moment, when in reality there are 2n points (one for each body).
Of of these things stand in the way of getting this done, however we currently have rather larger issues to deal with (just see panzergame's commits on materials).

No, I think that would be unhealthy ;) There is already some discussion in addition this code to the logic bricks. However, I personally noticed that the information available isn't intuitive. Bullet creates contact points for intersections, and determines their impulse based on a number of factors, which doesn't seem to agree with substeps. Essentially it doesn't seem easy to determine the hit force, or impulse over a collision so that we can compare collision strength - Its not reliable. Furthermore, we only return one contact point at the moment, when in reality there are 2n points (one for each body). Of of these things stand in the way of getting this done, however we currently have rather larger issues to deal with (just see panzergame's commits on materials).

Jacob Merrill commented

2015-05-25 03:26:10 +02:00

where can I browse commits?

how would I go about gathering the impulse over time and then using the frame time to correct?

or is it impossible at the moment?

where can I browse commits? how would I go about gathering the impulse over time and then using the frame time to correct? or is it impossible at the moment?

Angus Hollands commented

2015-05-26 22:24:54 +02:00

Commits can be browsed by cloning the git repository and browsing the commit logs, or here https://www.miikahweb.com/en/blender/git-logs/

Bullet generates collision contact points in something called a collision manifold. These contacts have appliedImpulse values that can be read. The total impulse is the vector sum of these impulses, using the normal for each contact to generate a vector (normal * impulse).

Impulse = average force * time, so you have to divide the total impulse by the lifetime of the contact, but this isn't necessarily very clear, because a collision is happening over a long period of time, sometimes. Hence, it's best to take the sum the impulse over the time the collision is happening until it stops, then use that time value or something. Unfortunately, this isn't very clear in Bullet at the moment.

Commits can be browsed by cloning the git repository and browsing the commit logs, or here https://www.miikahweb.com/en/blender/git-logs/ Bullet generates collision contact points in something called a collision manifold. These contacts have appliedImpulse values that can be read. The total impulse is the **vector** sum of these impulses, using the normal for each contact to generate a vector (normal * impulse). Impulse = average force * time, so you have to divide the total impulse by the lifetime of the contact, but this isn't necessarily very clear, because a collision is happening over a long period of time, sometimes. Hence, it's best to take the sum the impulse over the time the collision is happening until it stops, then use that time value or something. Unfortunately, this isn't very clear in Bullet at the moment.

Sybren A. Stüvel commented

2016-01-25 14:22:30 +01:00

No need to rely on a 3rd party site, our commits can also be browsed at https://developer.blender.org/diffusion/B/history/master/

@JacobMerrill-1 wrote:
Proposal - Add Collision.hitPosition

What Collision class are you referring to? Do you mean bpy.types.CollisionSensor?

this would be easier for most to get the hang of, then a callback, as well as match the existing API.

The callbacks are part of the "existing API" now, so we can't really change that. We could extend the collision sensor to include such a property. A problem with this is that the property can only be read at every logic tick, and not at every physics tick, which is why I didn't implement this in the first place.

No need to rely on a 3rd party site, our commits can also be browsed at https://developer.blender.org/diffusion/B/history/master/ > @JacobMerrill-1 wrote: > Proposal - Add Collision.hitPosition What Collision class are you referring to? Do you mean [bpy.types.CollisionSensor](https://www.blender.org/api/blender_python_api_2_76_9/bpy.types.CollisionSensor.html)? > this would be easier for most to get the hang of, then a callback, as well as match the existing API. The callbacks are part of the "existing API" now, so we can't really change that. We could extend the collision sensor to include such a property. A problem with this is that the property can only be read at every logic tick, and not at every physics tick, which is why I didn't implement this in the first place.

Sybren A. Stüvel removed their assignment 2017-02-02 15:43:23 +01:00

Satish Goda commented

2017-08-23 11:31:46 +02:00

Added subscriber: @satishgoda1