for i in range(pointList.numPoints):
    point = pointList.getContactPoint(i)

This is rather un-Pythonic. Why use a range object and an explicit index? It's much more flexible to use generators here, and likely also more efficient. James Powell explains it really well in his talk Generators will free your mind.

Encapsulating the collision information into its own class is a good approach though.

EDIT: Maybe we shouldn't call them "points". A "point" is just a point in 3D space, and a "collision point object" contains much more information. IMO collisions would be a better name than pointList.

I agree

In D1311#26134, @Sybren A. Stüvel (sybren) wrote:

for i in range(pointList.numPoints):
    point = pointList.getContactPoint(i)

This is rather un-Pythonic. Why use a range object and an explicit index? It's much more flexible to use generators here, and likely also more efficient. James Powell explains it really well in his talk Generators will free your mind.

Encapsulating the collision information into its own class is a good approach though.

EDIT: Maybe we shouldn't call them "points". A "point" is just a point in 3D space, and a "collision point object" contains much more information. IMO collisions would be a better name than pointList.

As Sybren says, we really do not want to reintroduce a get/set API. Using a generator is likely the best idea, given that the number of contact points generated will be quite large, and only a subset are likely to be read by the user (especially if they're only provided via the callback API).

Comment inline, otherwise I further agree with sybren. Good work, though, Tristan.

Defining KX_CollisionContactPoint seems a heavy weight option.

• Why not just return a list/tuple of vectors?
• Did you measure the speed cost of using a PyList?
• Are there many cases you would only want to read a subset of the points?

Maybe am wrong, but suspect in practice - just getting a list of vectors may be OK.

I think that it's better to return a python proxy with getter instead of a tuple because we don't spend time to convert all elements and in this case we can use a lot of variables.

@Porteries Tristan (panzergame), What are the chances you would want to access only a small subset of contact points?

In my implementation (crowd simulation system) I only used the first contact point, which worked fine. I think that typically you'd use either zero, one, or all points (I don't see the use in using the first half, for example).

Has anyone solved the getImpulse issue for a callback?

with contact point ->localized to part forces in line with a object can have less damage then forces out of line with a axis,

example -> walking ragdoll falls lands on feet -> dont trigger 'Slack mode'

walking ragdoll is running and kicks a stair front -> Trip ragdoll

My method for generating a impulse does not take into account 2 equal and opposite forces

(own.worldLinV @ end oflast frame vs own.worldLinV on collision)

(getting squished between two cars still kills you)

From what I can see this is simply an array wrapper, since the list size is known of time and it allows index access (unlike generators). and this is simply a way to access the list...

tp_as_mapping is defined so python can create a basic generator on.

How is this different from a CListValue?

As i already said : CListValue required CValue items, in the case of contact point we can have 100 points, but convert all points to a CValue type will be too slow. So we convert the point only when access.

So the main difference is the type that it stores?

In this case it seems like this is more like a Python specific list type, where the parent class only defines basic access functions.

Its not a generator, its a wrapper getitem/setitem access.

rename CPythonGenerator to CPythonListWrapper seems good to you ?