Testing

[kivig2]

Hello,
thank you and ZOZO for making this amazing project public!

I am currently doing tests to try switching to ZOZO's ppf contact solver from Blenders internal cloth for an animation movie. So far its awesome! A few observations/considerations or perhaps something I just didn't find or understand:

• Is there a simulation start frame setting hiding somewhere? If not, we can probably find a workaround with exporting for time-shifting or look into the code. For animation, the starting frame is often in thousands, which is a long pause to process :)

• I might have misunderstood something, but it seems that Capture Deformation captures all animation not just the time range that is to be simulated, which should produce a lot of unnecessary data, unless manually trimmed.

• Capture Deformation asks the mesh not to have Subdivision/Mirror before deformation. Those often produce a constant polygon count and are useful to have before deformations, especially for cloth. Could it be a warning of potential problems instead of an error?

• I'm surprised that baking into shape-keys doesn't crash Blender. For long animations it probably will and is hard to timeline manage. We probably will export the final simulations to USD/ABC as Blender plays large mesh animations nicely from those and can time manage them. Edit: Never mind - I had a wrong impression on Contact Solver caching from a Youtube video. It is there :)

• Perhaps an utopian feature: For Blender internal cloth I resort to a lot of vertex weight layers done by weight painting and blended/animated through Geometry Nodes, to control things like cloth bending resistance, stiffness shrinking/expansion, pinning etc. to enforce stability and shape. It seems this is mostly not necessary, because your solver is just so stable. But for artistic purposes it would be a fantastic feature to have the computed vertex weight layers captured with mesh and being able to connect them as material setting multipliers. In theory, would something like that be possible just from the addon or would it require changes in the solver?

[ryichando]

Thank you for posting! I will compile my answer on Monday, Japan time.

[ryichando]

Hi, thanks for the detailed feedback.

Caveat first: the solver is still proof-of-concept, not as matured as Blender's built-in physics. I wouldn't recommend a full production switch yet, keep it experimental alongside your current cloth setup.

• Start frame: Correct, it's fixed to frame 1. I'll file a feature request for an arbitrary start frame.
• Capture Deformation range: It's smarter than it looks. It captures from the starting frame to the last keyframe driving the deformation, or, for keyframe-less procedural setups (e.g. Geometry Nodes on Scene Time), up to the solver's frame count. So it should already trim to where motion ends. If you're seeing more, please share the setup.
• Subdivision/Mirror: This is a technical limitation on our side. The capture uses PC2, which needs a fixed vertex count and ordering, so topology-changing modifiers break it.
• USD/ABC export: Not available yet. I'll file a feature request.
• Per-vertex weight layers: Tracked here: [Feature] Weight Paint–Driven Material Distribution #54.

[kivig2]

Hi, thank you for your reply and for the warning. Experimental it might be, but much more stable and somewhat more controllable even without vertex groups, not to mention way faster than Blender's built-in!

• Start frame: Awesome! Thank you very much!
• Capture Deformation range: that sounds great for minimizing the amount of data where it is needed, but the reason for the comment was having character and collision animations of many thousands of frames, where the simulation (especially when testing materials) is needed only for a thousand or so. Even if the data will be stored in a very efficient way, those are still thousands of frames that will not be used in each relevant simulation and the process of export itself will take a very long time. Currently we will probably duplicate the character collision proxy for each shot and cut their animations outside of needed range.
• Subdivision/Mirror: Yes, that is how I understood it and why I asked if it could be a warning instead of an error? So the user knows it may not work and why, but could still try finding solutions, like vertex-order-preserving custom subdivision via Geometry Nodes etc. Though I had the impression that Subdivision/Mirror can keep constant vertex ordering between frames under certain settings already.
• USD/ABC export: Thank you!
• Per-vertex weight layers: in our case we don't need something so complex as simulation type blending. Its more about being able to influence material parameters during simulation by adjusting vertex weights (like [Feature] Animated Weight Painting Support for Parameters #48 , sorry I didn't find it when wrote the initial comment), or even if not that - just being able to define them with static vertex weights is a big feature on its own already. But it is understandable, that it's far from simple in any case, and amazingly, the solver seems to produce great results even without it.