07-04-2022, 04:22 PM
Help Problem with surface collision
|
07-04-2022, 06:18 PM
(This post was last modified: 07-04-2022, 06:20 PM by josemendez.)
(07-04-2022, 04:22 PM)snowtv Wrote: Is it possible for you to elaborate a bit more? Yes, enabling surface collisions requires to calculate simplices (minimal convex shapes) for the mesh used to generate the cloth. This is done when you press the “Generate” button on your blueprint: as part of blueprint generation, simplices are calculated and stored. When cloth is torn, mesh topology changes and as a result, simplex connectivity does too. This is the reason why surface collisions are not currently supported for tearable cloth.
07-04-2022, 08:33 PM
(07-04-2022, 06:18 PM)josemendez Wrote: Yes, enabling surface collisions requires to calculate simplices (minimal convex shapes) for the mesh used to generate the cloth. This is done when you press the “Generate” button on your blueprint: as part of blueprint generation, simplices are calculated and stored. It sounds like it is possible to do this in the future? If I want to try to implement it, where should I look into?
08-04-2022, 08:39 AM
(This post was last modified: 08-04-2022, 08:39 AM by josemendez.)
(07-04-2022, 08:33 PM)snowtv Wrote: It sounds like it is possible to do this in the future? If I want to try to implement it, where should I look into? Yes, it should definitely be possible to do. I already got it added on our internal roadmap, though it's hard to say when it will be available. If you want to try and do it yourself in the meantime, you should look into: - ObiTearableClothBlueprint.cs: you'll need to write triangle simplices into the blueprint, you can check ObiClothBlueprint.cs as reference. - ObiTearableCloth.cs: particle indices referenced by the simplices should be updated when cloth is torn, then set the solver's dirtySimplices flag to true so that simplices are rebuilt at the start of the next frame.
13-04-2022, 03:32 PM
(08-04-2022, 08:39 AM)josemendez Wrote: Yes, it should definitely be possible to do. I already got it added on our internal roadmap, though it's hard to say when it will be available. Great! I tried to tweak the solver configurations and the cloth blueprint particle properties and got a pretty good result without enabling surface collision. The main thing that makes the most difference I think is the particle radius parameter. However, I noticed that the auto-generation is giving each particle a different radius value (I'm assuming based on the distancing between the surrounding particles), but there is not an easy way to increase the radius uniformly. I plan to take a look at the code and see if I can modify particle radius by multiplying them with a magnitude, but just in case it gonna take me too long to figure that out, if you can point to where I can look into, that'd be great help. Thanks for the previous helps as well!
15-04-2022, 09:13 AM
Yes, initial particle radius and mass are calculated using the average area of incident triangles. This prevents having huge particles in regions with small triangles, or small particles is zones with large triangles.
In-editor there’s no way to scale the radius of all particles by an exact value (you can paint radius using the brush tool, but not as precise). You can get the blueprint and then iterate trough all values in the blueprint.principalRadii array, multiplying them by a value. Do this either in an editor script or, if you’re creating the blueprint at runtime, do it after calling Generate() but before assigning the blueprint to an actor. Kind regards,
18-04-2022, 04:15 PM
(15-04-2022, 09:13 AM)josemendez Wrote: Yes, initial particle radius and mass are calculated using the average area of incident triangles. This prevents having huge particles in regions with small triangles, or small particles is zones with large triangles. Thanks! I went into the blueprint script and added a parameter during the generation process so the radius calculation would multiply by this parameter. It satisfies my current needs. |
« Next Oldest | Next Newest »
|