Softbody Volume Constraint - Recommended techniques for generation #147
-
I looked into one of the soft-body volume constraint, trying to find any soft-body logic I could add to my code other than just fixed-world bound cloth. I saw that with the SoftBodyCreator, it uses cube that seem to use tetrahedron based volume constraints. Porting these over, it appears the logic uses almost a voxel-based soft-body approach as it adds the edges and tetrahedron. For aiming to use these soft-bodies, I am not yet clear on an "easy to use" way to use these. Is there a recommended way to auto-rig volumetric soft-bodies, or are some of the other soft-body features besides volume tetrahedron that are better casually adding arbitrary shaped soft-body volumes to a simulation? Outside of the volume constraint, it appears to me that the Sphere demos essentially rig things like blimps, acting as soft-shells held in form with internal pressure, although have not yet ported spheres tests. I think I could probably code a way to decompose Mesh shapes using kind of an fixed-3d-grid, essentially converting their internals to the voxel cells like the jelly-cubes, or add internal points and apply Delaunay tetrahedralization. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 11 replies
-
TBH I haven't really used the volume constraints much myself yet, so I haven't done any experimentation on what the best way to generate these would be. Creating an outer shell and using 'pressure' instead of volume constraints is the easiest (and cheapest), but will deform the shape since it will 'balloon' out. To me the Delaunay tetrahedralization seems the most promising. Note that there has been some discussion about this before here: jrouwe/JoltPhysics#789 B.t.w. the jelly cubes look very tasty, looking forward to the PR! |
Beta Was this translation helpful? Give feedback.
-
It kind of feels like cheating using physX as a tool for Jolt things, but the WASM physX library has features to pre-process models into (vertex, index, faces, tetras) - https://github.com/NVIDIA-Omniverse/PhysX/tree/main/physx/source/physxextensions/src/tet By itself, their algorithm runs quite quick, although for quality it likely prefers running another pre-process on it (remesh & simplify) to get more uniform tetras. If you do remesh/simplify, UV-mapping difficulty spikes quite a bit, and you probably will want to skin your high-res model to the low-res soft-vertex, like by driving the model vertex using nearest soft-faces. I may look into that, treat the nearest Soft tri/verts as bones, and dump the SoftVertex position into a float-3 data texture every frame and send it to the WebGL2 context to act as bones. Some workflows for conversions, although parts of the description are mapping to voxel-tetra instead of regular tetra though. I will probably see if I can make 2 or 3 models work well, possibly fully textured. The actual Answer to this question is likely:
|
Beta Was this translation helpful? Give feedback.
-
To anyone interested, here is some code that uses the PhysX simplification/remesh/ and tetrahedron creation, loaded into Jolt to create "soft mesh" based on OBJ files. I'm still working towards skinning a full mesh or GLTF to create a complex, multi-texture soft mesh https://gist.github.com/PhoenixIllusion/561e36d75471e2217a5b2a8d8f22683e See Live Example (requires your own OBJ's to load via Open OBJ): |
Beta Was this translation helpful? Give feedback.
-
As what I think is my final update for now, the following loads a textured GLTF, converts it to geometry (not clean for every GLTF, and it may require 'baking' the geometry if it is a compound geometry with instances, scales, and offsets for the child parts). It supports a scene with multiple children, assuming they all have a local transform of identity. https://gist.github.com/PhoenixIllusion/c6b0507b64c3ca4f3634e2bb0693ca61 The steps performed are: Prep the Mesh:
Create the Tetrahedron
To demonstrate the situation more easily, I have a 2d version of the logic below. Triangles are used in place of tetrahedron. At this point, I followed the logic that is done in the PhysX cooking flow. We take every vertex we want to use, and attempt to map it to a tetrahedron. I accelerated this using a hierarchal tree (AABB tree). For each vertex P in the model:
This results in one nearest tetrahedron for every vertex, then I calculate the influence that tetrahedron has on the point. This is done Barycentric coordinate function barycentricTetragon(a,b,c,d,p) {
const V = tetraVolume(a,b,c,d); // total volume of original tetrahedron
const dA = tetraVolume(p,b,c,d); // volume of tetrahedron if you used P instead of A
const dB = tetraVolume(p,a,c,d); // volume of tetrahedron if you used P instead of B
const dC = tetraVolume(p,a,b,d);
const dD = tetraVolume(p,a,b,c);
return [ dA/V, dB/V, dC/V, dD/V ]
} The below shows that P outside a tetra are mapped to the closest point on the tetra itself. The magic of barycentric coordinates is that they allow you to map any point located inside the tetrahedron using fixed weights per vertex of the 4 tetrahedron coordinates. With a barycentric coordinate for every detailed Mesh vertex, I can essentially toss out the original geometry coordinates. During runtime, when multiplied by the live-soft-vertex data of the simulation vertex of that Tetra, I resolve a location inside the tetra that should approximate my GLTF vertex location. My render loop in the Jolt simulation is now:
This does fail on simulations where the origin detailed mesh has long stretches of triangles, like a lamp-post or column or the bench, since the detail mesh possesses no subdivided vertex in the middle of the long stretch of model to render the "bend". If you manually apply a subdivide to the models yourself in a 3d model editor, it should resolve that issue. |
Beta Was this translation helpful? Give feedback.
It kind of feels like cheating using physX as a tool for Jolt things, but the WASM physX library has features to pre-process models into (vertex, index, faces, tetras) -
https://github.com/fabmax/physx-js-webidl
https://github.com/NVIDIA-Omniverse/PhysX/tree/main/physx/source/physxextensions/src/tet
https://nvidia-omniverse.github.io/PhysX/physx/5.2.1/_build/physx/latest/class_px_tet_maker.html
By itself, their algorithm runs quite quick, although for quality it likely prefers running another pre-process on it (remesh & simplify) to get more uniform tetras. If you do remesh/simplify, UV-mapping difficulty spikes quite a bit, and you probably will want to skin your high-res model to the lo…