GSoC 2019: Cloth Simulator Improvement

Hello Community!

This thread is for GSoC 2019’s Cloth Simulator Improvement project.

This project will introduce anisotropic adaptive cloth simulation which means that the simulation is independent of the mesh topology allowing for faster iteration and better collisions. Furthermore, this will give better visual results in lesser computation time. Additionally, this project would act as the base for future improvements, such as adding contact friction and dynamic tearing of cloth.

Link to the proposal can be found here. I am happy to hear your feedback and answer your questions.


I read your proposal and your background, really like it.

Lat me give you one idea, that coul be good or not, I’ll leave the judgement to you.

Instead of implementing a new type of object, which will be probably harder to maintain in the future and may confuse users, maybe you can work with a modifier, so when you add your “Cloth Object” modifier to a mesh it will behave in the way you want, and after that modifier the cloth simulation modifier can be applied, I think this may make this more future proof and easier to maintain, not just for you but for other devs, and will make easier it’s implementation in master, something I hope that happens right after you finish the Gsoc :slight_smile:

Good luck, we will be here to test your work and give you feedback!



Hey JuanGea!

Thanks for the support.

The remeshing step will be part of the current cloth modifier as an option if you need it, so you will be able to select either a fixed mesh simulation or an adaptive simulation. As I have mentioned in the proposal, the “Cloth Object” will be made only if time permits and will be useful for making garments. It does not mean that the adaptive simulation will not be available in the Cloth Modifier.

The “Cloth Object” will allow for easier defining of the stitches as it will not have a polygon based workflow, so don’t need to worry about creating loose edges every time the topology changes.


An interest of geometry made of quads are UVs.
An artist wants to paint colors and arrange several patterns on clothes of a character.

If UVs are not as adaptive as topology, result of simulation would not handle good looking fabrics.
Although physics of cloth looks great, if material is too limited and looks ugly : feature would not be used in production.

It is not obvious in your proposal. So, I ask. Are adaptive UVs included into your plans ?


I don’t think that will be a problem-- “the simulation is independent of the mesh topology” – I think this means that it is relative to the surface itself, so UV’s naturally will be preserved.

@ ish_bosamiya I get the impression that this is kind of like Marvelous Designer’s particle based simulation. Is that far off the mark? I’d be happy to offer information on my experience using MD, since this is the de facto standard in cloth simulation at the moment.


Oh! Pretty interesnting (the Cloth Object one)

I was proposing the modifier solution to keep it easier to maintain in the future, a new Object type could be harder to maintain (or maybe not, everything depends on how is programmed :slight_smile: ) but if the benefit is big enough, may be the best solution :slight_smile:



Yes, @Josephbburg is correct, the overall shape of the UV’s should not be affected.
@RonanDucluzeau you can take a look at the video made by the authors of the research paper (linked here), it shows that the UV islands are preserved, only the inner part of the islands change.

@Josephbburg MD creates a uniform mesh which is updated only if the shape of the 2D pattern changes or the density of the mesh is changed. If you were to look at the wireframe view, you will notice equally sized triangles. This project will involve updating the mesh based on how close it is to an obstacle, how creased the mesh is, and some other factors. I encourage you to take a look at the video linked above to get a better understanding of the same.
Your experience with MD will be useful when making the proposed “Cloth Object” (or a new modifier), although this will be pursued only if time permits.


Hey @JuanGea!

I understand your reasoning behind using a modifier over creating an entirely new object. I will try to figure out how it can be made into a modifier instead of a new object once I am done implementing the adaptive simulation for the current cloth modifier.

Please discuss it with your mentor and the core devs, that is just my idea but they will know if I´m right about the overhead with a new object type or not :slight_smile:

What do you think about this @brecht ?


1 Like

Thanks for linking the video, very cool! I am concerned, though, that it will be difficult to use the Surface Deform/Mesh deform modifier with the new cloth simulation. Something I like to do is create a simple “simulation” clothing object, which is flat and lo-poly, and a “render” clothing object, which has thickness and more detail. I like to put a solidify modifier on the simulation object, and bind the render object to it using Mesh Deform. Sometimes I can skip the solidify modifier, and use a surface deform modifier.

IMO this is the best way to animate cloth, since you can get the same motion as the cloth on any object, regardless of topology. Cloth simulation tends to screw up thick meshes, and often this thickness is necessary in the model.
I can’t upload a .blend here, I’ll link you it with OneDrive.

example blend

Hey! That’s a nice workflow, hadn’t thought of it. You are correct, if you were to use the remeshing option, it would not be possible to use the surface deform or the mesh deform modifiers.
I have mentioned before, the remeshing step will be an option if you want it, which means that it will not disrupt your current workflow, only enhance it wherever possible :D.

In principle this could be made compatible with the surface deform modifier. One way would be to have an option to output a fixed mesh and do only the simulation on the adaptive mesh.

Another reason I think keeping the topology constant (at least as an option) is good, that I didn’t think of earlier: many Mesh cache file formats expect objects to have the same topology in each frame.

I have done a little thinking about this… the dynamic remeshing option keeps the UV’s constant. I think it might be possible to create a binding that is relative to UV space. The modifier could do something similar to Data Transfer- each vertex would find the nearest point on the surface and record its UV coordinates. Then, instead of transfering the data, it would try to match the relative location of the vertex and the point on the surface that has that UV. Of course, this would mean overlapping UV’s in the simulation mesh would break things, and there would be the problem of calculating the displacement. I think it would work if it was measured relative to the vertex’s normals. Obviously, though, there could be a simpler solution. I think creating a fixed mesh from the simulation would be pretty straightforward using a similar method to this one.

I haven’t learned to code C yet (hopefully soon!), but I might be interested in testing some of these ideas out with Python. I’m very excited about this project! Thanks for being a part of Blender, @ ish_bosamiya :slight_smile:.

I’ve done some cloth simulation, and have observed somethign: the reaction of cloth to force fields is hard to predict, because subdividing a cloth will reduce the apparent effect of the force field. I think the cloth modifier currently calculates force field interaction strength by number the of vertices. I think instead, the force field should calculate its influence by surface area, or total mass (which would itself probably be calculated from area or volume). This way, the cloth simulation would behave the same in lo-resolution and high-resolution with the same force fields. I was using Wind when I noticed this, I’m not sure how other force fields affect cloth.



Without cache, it is difficult to test branch.
We cannot replay animation. After first playback, cloth is stuck to last frame.

Sorry for the very late reply.

Yes, this issue seems to exist for all forces, I am not sure why this is the case. Adaptive cloth simulation will not fix this, a thread needs to be started over at regarding the same.

1 Like

Sorry for the very late reply.

The caching system requires the mesh to have the same number of vertices throughout. It will need quite some change, so the current plan is to bring back caching support after dynamic remeshing is implemented, static remeshing has now been implemented :smiley:

If you are running linux, create a folder called objs in /tmp/ so “/tmp/objs/” needs to exist. It outputs objs of every frame here. You can then import this obj sequence using a script (link).

@13AUDDIN asked about how much faster the adaptive simulation would be compared to normal simulation over at the weekly reports thread.
Based on the paper, a high res plane falling onto a sphere took 65 seconds per frame where as their technique took 9 seconds per frame for similar looking results. It is not possible to give an exact number since it depends on the visual fidelity that you are aiming at, but it is same to assume that there will be improvements. It is important to understand that the remeshing technique aligns the edges with the wrinkles which means that there is no jagged look, this means you can get away with lower resolution adaptive remeshing thus speeding things up.


Can’t you leverage Alembic as the cache system? maybe it’s not optimal, or maybe it is, don’t know, just wondering since you said that the current cache system needs the same numb er of vertices to work.

1 Like

Yes it is possible, I need to do some reading on caching before I can say anything for sure, even my mentor is not so sure about the right approach to the caching system.

you can go to their discussion board maybe sone can help:!forum/alembic-discussion