TransformStat::get_mat() returns singular matrix on macOS about panda3d HOT 5 CLOSED

After further testing, it seems it could be a reference count issue, when directly retrieving the transform matrix, the received matrix is singular :

print(self.instance.get_net_transform().get_mat())

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

But if i store the net transform state in a temporary variable, the matrix is fine :

transform = self.instance.get_net_transform()
print(transform.get_mat())

2.38188 5.41052 -2.34575 0
-5.89714 2.18533 -0.947458 0
6.36e-09 2.52986 5.83519 0
-24.9978 4.72253 -1.26191e-06 1

from panda3d.

Is this with the transform cache disabled?

The problem is that TransformState accessors return a const reference to the fields therein, which is bound to the lifetime of the TransformState, which may go out of scope. This is a general issue in the Python API at the moment.

(A related issue was with MouseWatcher::get_mouse(), which used to return a reference to a Point2 that would "magically update" when the mouse moved, causing a lot of user confusion. This was finally changed in 76b9df0.)

Possible ways to solve this include:

1. Interrogate always makes a copy of any const reference return value.
2. We add some clever mechanism to interrogate so that a reference to the TransformState is stored on the returned PyObject, so it is kept alive.
3. We change the return value to an LMatrix4 copy, just for this one method.

I think 3 means we're just going to see this issue pop up somewhere else soon.

While 2 is clever, interrogate can't strictly speaking know for sure what the lifetime of a return value is meant to be bound to, without . We could add a special keyword to add to a method that tells Interrogate to do this, but it sounds difficult.

I'd be inclined to go with option 1, even though this could break existing code. We'll have to analyze whether there are cases where this doesn't make sense, but generally, I think this is what Python users expect.

from panda3d.

Is this with the transform cache disabled?

Yes indeed, I forgot to mention that crucial fact

While 2 is clever, interrogate can't strictly speaking know for sure what the lifetime of a return value is meant to be bound to, without . We could add a special keyword to add to a method that tells Interrogate to do this, but it sounds difficult.

This probably sounds naive, but can't the temporary returned PyObject keep a reference to the TransformState and automatically release that reference when it is garbage collected by the Python engine ?

from panda3d.

That's what I suggested with 2, but how does interrogate know that the returned reference is supposed to be bound to the lifetime of the TransformState, and not bound to the lifetime of some other object? It would need to look into the method and see that it's returning a member rather than a member of something else. Or we would need to tag the method with some special keyword.

Or, maybe we just assume this is the case, and accept that it's not a perfect solution? Still, I feel that having objects being able to arbitrarily preserve the lifetime of other objects could also cause unintuitive behaviour for users, perhaps even memory leaks and reference cycles (in the case of classes like NodePath).

from panda3d.

I pushed an interim fix that makes interrogate think that these methods return temporaries, so that it is forced to make a copy. This is not breaking compatibility for this specific case since TransformStates are immutable anyway.

We still need a good fix for the general case.

from panda3d.