Feedback Wanted: Cloth Improvement Plans

Unity Engine
,
1

Hi All,

I am working on improving Unity’s cloth system and as part of this would like to gather people’s thoughts on cloth authoring workflow and features.

As part of Cloth Improvements requirements capture, I have looked at nine different authoring packages, and they all tend to fall in one of two groups:

1. Basic cloth authoring and tweaking given a pre made cloth mesh.
as seen in APEX, Modo, Maya, Syflex, Shroud, Havok

  • Cloth is created using a given triangle mesh, that is rigged with animation bones.
  • Cloth constraint values are set and tweaked by painting them onto the mesh with a brush.

We should begin our cloth improvements by implementing a brush based approach like this.With the added ability to paint on the cloth whilst it is being simulated in the editor view.

Quick, easy to use and generally all that is needed for a lot of cloth scenarios.
We should include:

  • Plenty of examples of usage.
  • Tutorials.
  • Documentation.
  • Testing.

Whilst early adopters are using this and giving us feedback we can look at the internal side of cloth and work on:

  • LOD’ing.
  • Self collision.
  • Cloth-cloth collision.
  • Adding additional collider types.
  • Generating colliders from a mechanim avatar.

2. Advanced, garment making style approach.
as seen in 3ds Max, Marvellous Designer, Optitex

  • Taken from packages used to design real clothing, a sophisticated “Garment making” approach that allows users to assemble clothing from smaller pieces that are “stitched” together.
  • Using a series of custom user interface tools, often with lots of extra helpers to make the process as simple as possible. ( Marvellous Designer is the state of the art for this approach )
  • Much more sophisticated than the first approach, probably overkill for a lot of cases, particularly for low end platforms.

However as time goes on and technology becomes more powerful, this will ultimately be the way people author cloth.

This could be a long term improvement to the cloth that we will need some new runtime tech for welding/stitching verts.

We can work out exactly what we require editor/runtime wise as we implement the first set of improvements.

Initial requirements capture/task breakdown.

UI/Workflow improvements

  • Brush based constraint painting. ( I have started looking at the terrain editing tools for this, as they already have the brush like tech we need )
  • Live cloth tweaking in editor.
  • Combine these into a free asset store package for early adopters, or create a custom build, to be decided. Evaluate the best option.
  • Create plenty of examples of usage.
  • Create tutorials.
  • Documentation ( remove old out of date docs and write new ones ).
  • Testing ( make sure we have the right testing framework for cloth )

Runtime tech side improvements

  • LOD’ing.
  • Self collision.
  • Cloth-cloth collision.
  • Adding additional collider types.
  • Generating colliders from a mechanim avatar.

Garment making tech

  • Garment making UI.
  • Garment making Runtime - stitching/welding tech.
  • Plenty of examples of usage.
  • Create tutorials.
  • Documentation.
  • Testing.

Please let me know what you think about this, thanks!

4 Likes
2

I love what Marvellous Designer does, but I assume for most games you need an extra baking phase to use the produce clothing assets? Designing in Marvellous is then analogous to sculpting a high poly version, after which you bake all the detailed creases to a retopologized version of the mesh.

That said, if you think something similar to Marvellous could be used to both author cloth content and simulate it at realtime with other things going on, go for it.

As for my specific use-case: I’d like to use simulated cloth in Volo Airsport, but due to the high velocities the characters have I have not been able to find a stable setup in the past.

1 Like
3

hi @Tinus ,
A comment regarding the Airsport cloth:
Have you experimented with scaling down the .worldVelocityScale or .worldAccelerationScale and use the .externalAcceleration to get the wind direction you want? You (should) just need enough force to inflate the “sails”. In my mind you can then apply an ocean-ripple like vertex shader on the “sail” mesh to get the really fast moving turbulence.

1 Like
4

I liked that the old cloth with the right pressure settings could be used as soft bodies. Any chance of bringing that functionality back?

2 Likes
5

I actually used cloth only a few times for testing. My impression was:

  1. very huge performance impact
  2. very vulnerable to fast rotations (then the cloth mesh was twisted and couldn’t free itself anymore)
  3. not much influence on it via code (don’t know if that really matters, I’m a programmer, not an artist, so this was more for me to check what I can do with it via code).

My main target platform is mobile, so I guess cloth is not the feature I should use, but I wanted to share my experience with it.

1 Like
6

My only comment would be on delivery, rather than a custom asset or special build, it should follow the UI pattern and be listed on OSS (as much as is feasible)

1 Like
7

InteractiveCloth is not coming any time soon, I’m afraid. PhysX 3 removed the module we used for InteractiveCloth in PhysX 2, and I’ve not heard them working on returning the module back.

On the other hand, InteractiveCloth was even more expensive than a regular Cloth in terms of performance. If, in theory, InteractiveCloth returns back with the same performance, and pretty much the same issues, would you consider using it again?

1 Like
8

Absolutely, it was a nice component to experiment with. It might not be the best solution for (character) cloth, but it could be used very creatively.

1 Like
9

Improve Performance!
As a goal,

https://vimeo.com/135195613

1 Like
10

Can you share a real-world scene with us where you think the performance is below expectations? That can help a lot to put the right questions in front of our contacts at Nvidia.

11

Thank you for wanting to work more on the Cloth system.
I have a lot of things to mention here, and it’s hard to know where to start, so I’m going to dive right in.

The most important feature that I would like to see added to the system is the possibility of driving a mesh with a simulated cloth. I see this as the single most important feature of any cloth system. The lack of such a feature forces us to write a lot of different wrap scripts and vertex-parent-constraint scripts to work around the issue.
You almost always want to have a simplified single-sided cloth mesh (unless you are simulating a sack, but that’s not possible without self collision anyway), and you almost always want to have a more complex render mesh with thickness. We’re now forced to use our own wrap system written in c# which I’m sure is not as optimized as something you could create over at Unity.

This leads us to the next issue, the fact that querying the vertices of the cloth in any of the available updates gives us the position of the vertices before they have been modified that frame. Which means that all deformers and constraints we write to drive things with the cloth mesh lags one frame behind.
And while on the topic of querying; being able to query the vertex normals instead of having to recalculate them on our own would be great.

Furthermore, the expected behaviour of stretching stiffness 0-1 and bending stiffness 0-1 would be: That on 0 it would be able to stretch in to infinty and bend in whatever way it want, and on 1 it would not stretch at all and not bend at all. That is currently not the case.
Having these two attributes as globals for the whole cloth system is also very limiting, it would help a lot if we could paint these on the cloth and therefore specify different settings on different parts of the cloth.

Box colliders would be appreciated.

Being able to specify a ground-plane would be appreciated and help alot, even though a box collider would serve the same purpose. We currently have to move a ginormous capsule collider around with the character to have the cloth collide with the ground when the character enters ragdoll.

Self collision would be very appreciated.

Having a visual representation of the length of MaxDistance and SurfacePenetration per vertex (and being able to toggle it on and off!) would help alot when designing cloth behaviour.

I think that’s all for now. Thanks for listening.

1 Like
12

Hi,

We use cloth on almost all our characters in our game so we have some feedback for you.

  1. Non-allocating vertices queries
    Quering vertices right now allocates a new array with vertices every frame, this triggers a lot of garbage collects. In 5.3 you add non-allocating physics queries which is great and that would be perfect for this case too.

  2. Reset cloth method
    It would be great with a Reset() method on cloth which resets it to it’s default pose. Right now we have to disable it and then enable it the frame after.

  3. Simulate cloth method
    When pooling our characters there is a lot of deactivating and activating going on. When we active a character we set the correct state on it. Position, rotation and animation etc so it can be visible in the right state that frame. Right now we reset the cloth to it’s default pose. That means the cloth wont be in it’s relaxed state until a few frames later. What I propose is a method that will simulate the cloth and relax it for us in one frame. Much like what ParticleSystem.Simulate does. Maybe something like this: SimululateCloth(float solveCount).

  4. Callback when cloth is finished solving
    Like Gabriel(Cal0n) said when querying the vertices of the cloth it’s always one frame behind because the cloth solves after LateUpdate. We use this to make a transform follow the surface of the cloth and it works good the problem is it’s one frame behind (and it’s allocating). If we had a callback like OnClothSolved or something we could use to move the transform it would help a lot.

Thanks for listening!

1 Like
13

Hey Cal0n,

Thanks for your thoughts! Initial work will be on improving the UI and authoring/tweaking of cloth. So visual representation of the length of MaxDistance and SurfacePenetration per vertex (and being able to toggle it on and off!) will be included in this.

After this further improvements such as new colliders and self collision. As for driving a mesh with a simulated cloth, this could be considered for later on.

Could you elaborate more on what you would require from this?

Thanks!

14

Hey temps,

Thanks for your feedback! I should be able to address these in the further cloth improvement work which will also include self-collision and cloth-cloth collision.

1 Like
15

Can I get a re-initialize hook for when a skinned mesh gets vertexes updated at runtime?

Right now it keeps the old vertex list.

1 Like
16

Hi Sean.
This is what I would expect such a wrap to do:

  • The green plane is the cloth.

  • The blue strange looking object is the driven mesh.

  • The vertices of the blue object is smoothly transformed according to the vertices of the green object.

2384803--162344--wrapExample.png
2384803--162344--wrapExample.png1178×1294 335 KB

Ideally such a system would be setup by simply providing a target (driven) mesh to the cloth component without having to worry about fallof-settings, distance-thresholds etc.

2384803--162338--wrapExample.png
2384803--162338--wrapExample.png1178×1294 336 KB

2 Likes
17

I do not have much of a feedback to give since I haven’t used the cloth component as much.
But I have encountered a problem which I’m not sure if it is a bug or this is how it should work and I made a thread here

If I remove the cloth component but keep the skinned mesh there is no performance issue, but disabling it acts the same way as if it was enabled.

1 Like
18

Hey Void24,

I will look into this as part of the improvement work.

19

Thanks Cal0n! I will look into this further for you.

2 Likes
20

Hey Timescar,

This issue is known and being looked at, we should get a fix for this soon.

Thanks!

1 Like