Physics simulation for character hair

Technologicat · February 17, 2015, 3:54pm

Thanks!

Now that you mention it, I think I’ve actually read that earlier (https://www.panda3d.org/manual/index.php/Interrogate). It covered the basics pretty well, but didn’t delve into the details on how to pass parameters containing more complex data types.

(The simple example was probably somewhere in the skel/ directory, as the manual page on interrogate mentions a sample C++ extension there. That must be where I picked it up earlier.)

Ah, I see now I was confusing C-based Python extensions (involving PyObject, which allows accessing Python objects in C code) with Panda’s C++ extensions.

I was also incorrectly assuming that pretty much everything in Panda (except a few select things such as the postprocessor) is implemented on the C++ level. It seems the first task will be to check which of the classes needed for this are C++ and which are not.

The simulator does not strictly need Actor. What the code really needs to do, technically, is to traverse the children of a user-specified joint that is contained in a user-specified part of the multipart actor. The Python implementation does this by traversing the PartBundles contained in an Actor, and when it finds the correct bundle, traversing CharacterJoints. I suppose I can set up something similar in C++ once I figure out which classes are available (for which I suppose the API reference is useful).

(It would otherwise be fine to leave the whole thing in Python, but the problem is that this computation does not vectorize well, so the low-level physics needs for loops. Cython would be another option for this, but introducing a dependency on Cython may lead to packaging problems considering the distribution of projects using this simulator. Also, I think there is a potentially important efficiency gain if the function calls to update the joints are performed in C++, as there can be a large number of hair segments in the scene. I can’t see a better way to do this than to move the whole simulator into C++.)

Ah, that’s a good point.

The task manager may indeed be too high-level to be the appropriate abstraction for this. I currently don’t know the architecture of Panda well enough to make an informed choice from the other options. Is there any particular approach you would prefer in this situation? (If not, I can look at all of them, but deciding which one is best may take some time.)

EDIT: now I think I understood the PandaNode suggestion: subclass that, make cull_callback() timestep the simulation and post the updated transforms to the affected joints, and plonk this HairPhysicsNode (or whatever) into the scene graph (setting it to sort early in the cull traversal) just as if it was a ComputeNode. This seems very elegant, and should minimize the amount of additional code needed in the simulator. I think I’ll try this solution first.

rdb:

Technologicat:

The final version of the simulation will need motion information in order to implement fictitious forces arising from non-inertial motion of the Actor (see e.g. http://en.wikipedia.org/wiki/Fictitious_force#Mathematical_derivation_of_fictitious_forces).

Is there a more preferred, general way to extract this information in Panda, than using finite differences based on the last known position(s)? The simulation needs the local acceleration at each joint that is generated by the combined effect of non-inertial rigid-body motion (i.e. acceleration and rotation) and any prerecorded animation that may be simultaneously playing on the Actor (affecting the hair parent joint or its ancestors). Linear velocity may also be useful for a crude simulation of air resistance based on the local velocity plus some random noise.

Panda doesn’t really store this information, but it does store the last frame’s transform for fluid collision checking (but it would also require you to use nodePath.setFluidPos instead of nodePath.setPos). You could possibly make use of that. Otherwise, you’re on your own, and you’ll have to use a traversal that runs each frame, or transform_changed hook, or something like that (though keep in mind transform_changed only gets called when a node position changes, not that of its parents).

I see. Thanks.

I think in effect, that would do the exact same thing as the solution with custom finite differencing, the only difference (no pun intended) being where the information about the previous position is stored. Maybe the most robust and also easiest option is to use traversal at each frame, so that the simulation works the same regardless of whether the character is being moved using setPos() or setFluidPos(). The simulator must in any case compute some derived quantities from the position history, so it is logical to extract and store the positions locally.