Hello guys,

I drapped some kind of dress around a Mixamo model. It works fine but then, when I start my sim and my model starts walking, the dress doesn't collide at all. I realised it was because I edited the model and the topology is changing every frame. I mean the points of the model are changing each frame. The mesh isn't really static. I guess it happened because I inflated some body parts with VDBs and now the arms are merging with the hips as the model is walking, but I want to keep that effect.

So I thought that was the cause of my collisions problems. I tried with a normal Mixamo sequence and I didn't have any issues. So It definitely is because of the changing topology of my model.

It seems that the solution would be to convert my walking model into a collision VDB object (correct me if I am wrong) and do this in DOPS, import the drape as vellum source. But it still doesn't work
My static object in DOPS (my walking model) is set to:

- use deforming geometry
- create active object (tried both on and off)
- collisions detection set to volume (I also tried surface)
- Volume sample mode

It is not working. The cloth is kind of colliding, but intersect with my model and it is really jittery.
I have increased substeps with no change.

Any clues??

Thanks a lot

Here is my problem!

Can you post your file?

mrCatfish
Can you post your file?

Here you go mr Catfish. I couldn't reduce the file to the limit of 16Mo because of the different caches so here's a link to the zip file.

https://drive.google.com/file/d/1D5cAVRb-LeXRhehd8R_13DFU-4_s03_F/view?usp=sharing [drive.google.com]

Thank you very much

clear SOP Path parameter on /obj/catwalk/dopnet1/catwalk node
it's feeding your broken geo to the static object and confusing the solve with incorrect velocities, hence causing the popping

without it you are left only with volume collisions which will work fine, but keep in mind that vellum collides only with points against volumes so you may need to make your cloth denser to avoid thin volumes like hands passing through

EDIT: you can further improve your solve by sticking constant topology inside of your volume to resolve fast motion collisions, the volume collisions will take it from there and push points out of the volume, otherwise you may miss fast movements as with volumes you will not get continuous tracking

or ideally you would transfer correct velocities to the remeshed geo before caching to abc, assuming you started with constant topo model you can transfer from, then you would have changing topo but with correct velocities that can help predicting the collision movement, instead of causing popping like the incorrect ones

tamte
clear SOP Path parameter on /obj/catwalk/dopnet1/catwalk node
it's feeding your broken geo to the static object and confusing the solve with incorrect velocities, hence causing the popping

thanks that improved a lot.

tamte
without it you are left only with volume collisions which will work fine, but keep in mind that vellum collides only with points against volumes so you may need to make your cloth denser to avoid thin volumes like hands passing through

Yes, I still have the tip of the arms (no fingers, so not that thin) passing through. How can I make it denser? I subdivided the mesh of the dress further but no improvements.

EDIT1: I tried to thicken it before feeding through the vellum cloth, no change either.I bumped the thickness to the maximum possible, same, no change. Did you mean something different?

EDIT2: So thickening the cloth before improves a lot. I had to increase substeps to 4, constraints iterations to 20 to prevent the arm from going through. My only problem is that the cloth has an ugly seam due to the thickening now, and the vellum post process doesn't fix it well. Also, thickening the cloth makes it less wrinkled.

tamte
EDIT: you can further improve your solve by sticking constant topology inside of your volume to resolve fast motion collisions, the volume collisions will take it from there and push points out of the volume, otherwise you may miss fast movements as with volumes you will not get continuous tracking

How can I do this?!!!

tamte
or ideally you would transfer correct velocities to the remeshed geo before caching to abc, assuming you started with constant topo model you can transfer from, then you would have changing topo but with correct velocities that can help predicting the collision movement, instead of causing popping like the incorrect ones

not sure I can do this as I did start with a normal Mixamo sequence but I completely changed the shape of the model with VDBs, and now arms and legs are merging with the rest of the body as it is walking. Which is something I'd like to keep

Thanks a lot for the directions you gave me, I'll try to figure it out

Not sure if you've seen this vid, but it will take a lot of mystery out of vellum. Here is a link where it's queued to the correct place and the developer explains how volume and surface collisions work: https://youtu.be/4nC-L19400I?t=2464 [youtu.be]

mrCatfish
Not sure if you've seen this vid, but it will take a lot of mystery out of vellum. Here is a link where it's queued to the correct place and the developer explains how volume and surface collisions work: https://youtu.be/4nC-L19400I?t=2464 [youtu.be]

Yes, I did, a little while ago. Thanks for sending this. I tried to do exactly the same as he is doing but that didn't work. He seems to be saying that things get tricky with animated mesh. I tried with and without the SOP path as Tamte said. I still have a piece of arm popping out.

EDIT: he is saying in the video that a lower res VDB works better, indeed, the cloth works perfectly well with a lower res VDB of my character. But lower res means no more arms in my case hahaha!

So in the end, so far, it works better by thickening the cloth before feeding it in the vellum cloth. But it changes completely the look and behaviour. I will try to understand the other stuff Tamte suggested.

Cheers

So increasing the offset surface of my static object (the VDB) to 0.006, substeps to 7 and constraint iterations to 10 seem to work now, even with the cloth not being thickened beforehand.

So in the end, I made it, but things are reeeeaaallly slooowwwww, but I am satisfied to have made it work.

If anyone can give me some clues regarding another way of doing it like Tamte suggested where I would 'stick constant topology inside of the volume to resolve fast motion collisions', that would be awesome.

Learnt a lot today! Gonna buy me a lockdown beer. Happy weekend and thank you

anbt
If anyone can give me some clues regarding another way of doing it like Tamte suggested where I would 'stick constant topology inside of the volume to resolve fast motion collisions', that would be awesome.

you'd do it in your previous network, where you are taking constant topology character and making into this VDB one

even if you have just take this character meshed in tpose, preferably lower res and skin it with original FBX bones to make it match as close as possible, but have constant topo

then compute v on that character
you can also transfer that v to your remeshed version with changing topo

and in your vellum include both, the volume version with v will already be better at predicting movement and additional constant topo collider will prevent sharp objects piercing through since vellum will be able to use poly colisions

great thanks, I will try this.

In regards to your changing typology, I'd also consider freezing the model on frame one with a Time Shift node, making your adjustments to the model in that state, then using a point deform to animate your adjusted model. If you watch John Lynch's Vellum masterclass, He goes over the Positional Based Dynamics logic that vellum uses, on a typical simulation, you have a starting position and a predicted position, and vellum just checks the space between the two to determine if a collision happens or not. The VDB stuff in Jeff Lait's is specifically in regards to points being brute forced into other colliders, and so the points can find their way back out of the collider geometry once that no longer happening. If you can keep to surface colliders and just address your topology issues, you'll come out with a much faster sim. I know I'm late to the party, but I figure I'd add my two cents in case other people come across this thread in the future.