Examples: Simplify WebGPU Cloth Simulation with a re-usable class.#32964
Examples: Simplify WebGPU Cloth Simulation with a re-usable class.#32964bandinopla wants to merge 10 commits intomrdoob:devfrom
Conversation
examples/webgpu_compute_cloth.html
Outdated
|
|
||
| import { OrbitControls } from 'three/addons/controls/OrbitControls.js'; | ||
| import { UltraHDRLoader } from 'three/addons/loaders/UltraHDRLoader.js'; | ||
| import { ClothSimulator } from 'three/addons/objects/ClothSimulator.js'; |
There was a problem hiding this comment.
Better to place this module in three/addons/misc/ directory.
There was a problem hiding this comment.
Isn't a cloth the same as a water sim? Similar, I mean... three/addons/objects has 4 classes related to water. Why cloth should be in misc? It is an object, a cloth object. A mesh. It sounds like it should be in objects and looks like misc is more for things that are not literal objects in the scene, more like calculation managers.
|
I'm not sure if this refactoring is appropriate. |
|
World be great to have this as a reusable component indeed. |
what is the "lots of use case specific code " you see that makes it not reusable? can I get a few examples? I'm failing to see it. |
What is the current failure to do so in the current code? I'm scratching my head on this one. I'm seeing a BufferGeometry mesh with a position and normal nodes. I can instantiate more than 1, each having their own settings... em I missing something? |
|
E.g. what if users want other colliders than a sphere like box or capsule? The mesh's material type ( |
That goes beyond the scope of the implementation of the original example that uses spheres to ease the calculations using distances only. I could argue that many other classes in the code base could also be faced against those same type of questions. The "what ifs" are very generous and fit in most holes. Any other issue besides that? I'm trying to learn from the masters. |
examples/jsm/misc/ClothSimulator.js
Outdated
| * @param {Vector3} position Position of the sphere | ||
| * @param {number} [radius] Optional new radius | ||
| */ | ||
| setSphereCollider( index, position, radius ) { |
There was a problem hiding this comment.
This method should accept an instance of THREE.Sphere.
There was a problem hiding this comment.
that would be overkill since the "colliders" are just used to get their position and radius in the computeVertexForces and calculate a push direction force.
There was a problem hiding this comment.
Added the possibility of either THREE.Sphere or the usual Vector3+radius combo. Still think it is overkill I will doubt myself on this one and just do it since it does make it look more "Three-like".
| * Create visualization meshes for sphere colliders | ||
| * @returns Array of meshes that can be added to the scene | ||
| */ | ||
| createSphereVisualizers() { |
There was a problem hiding this comment.
Maybe createSphereHelper()?
The actual visualization of the collider is app specific and should not be done by this component, imo.
There was a problem hiding this comment.
The use of that method is for when the need to "visualize the spheres" arises. They are not really "helpers" since they don't do anything like a gizmo would more than just visualize. "Helper" is secondary to "Visualize" since the main goal is to "Visualize". In my humble opinion a "helper" is an object that helps you "do" something.
I could make it so the |
…NodeMaterial. Defaults to a MeshPhysicalNodeMaterial
… the options or if it doesnt already have a colorNode
…PerSecond to compute
…nd showing the simplicity in added another instance
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
3 participants
Encapsulated the functionality into a new object
ClothSimulatorso that the cloth functionality can be easily used by other users.