Whatsinaname

In my sim, everything is behaving nicely, apart from the cloth reacting too strongly to the character's movements. Speaking in real-world terms, it feels like the air density was really high, almost as if it was underwater. Even small movements in the underlying animation are affecting the cloth way too much. I tried playing with the Normal Drag/Tangent Drag attributes in the Vellum Constraint, but these parameters didn't seem to have any effect at all. POP Drag on the solver also didn't affect the simulation, so I was wondering if anybody has been successfully dampening vellum behavior in the past?

Yes, that works nice and fine. I was only wondering if there is a way to make it work without localising as it does so in nCloth.

You could use targetweight on your points, which is a float variable, and animate that (see the help on grains for that matter). I tend to create a Pin to Target constraint, setting Stretch>Stiffness to Scale by Attribute and targetweight as control attribute. Also set Pin Type > Soft, Orientation Pin Type > None and activate Pin to Animation. This should allow you to control the pin strength by animating the targetweight attribute.

Did anybody have any success with vellum cloth on fast moving objects? I'm doing cloth on a character, who is free falling. It's done by an animator and speed-wise, it might be slightly overdone, but there's no way to change that. Simulating cloth on the character using Maya nCloth, I got proper results, but it was still nCloth and therefore slow and painful. I recreated the setup using vellum, but no matter how much I increase substeps, everything is exploding right away. It is working fine with a localised version, but I was wondering if there is a special trick or anything worth considering when using Vellum with fast moving objects? (Unfortunately, I cannot post the scene file)

Check if there is any Initial Data set in your FLIP object. If so, do away with it.

Doesn't look like a cloth sim to me, more like some geometry around the suitcase was turned into a volume/VDB and either the geometry or the values for the volume vdb have been animated.

What exactly is your question? Although I think the answer might be refraction.

Is it possible you are using a special character, that is neither a number nor part of the (English) alphabet anywhere in your scene (e.g. on your mantra SOP)? If so, do away with it and try again.

There aren't any presets. This video might actually help you understanding how to set up certain cloth behaviours in Vellum, though.

I think it might be a bug, I've seen something similar with FLIP a while ago. Some particle separation values seem to be causing weird behaviour, slightly changing Particle Separation usually fixes it. Try a particle separation of 0.066 and check that works.

We did this in a commercial a while ago. Use an ocean surface with displacement etc for the top and have some light refract right through it. For the murkyness below, you might get away with volumes or VDBs and some noise (like curl noise inside a Volume VOP), maybe three different depths depending on camera distance, and some particles driven by a dampned, heavy smoke sim, also a couple of layers with different noises. That should be pretty much it.

It is difficult to see what you mean without any further explanation. Can you provide us with an image or a scene file?

VDBs also tend to cause some memory leak issues. Sometimes re-starting Houdini is all you can do, so make sure to cache anything VDB related before rendering.

In the Scatter SOP, just Options > Density Attribute to fuel.

Hmm...not entirely sure if I properly understand your question. You can still use Volume Source to feed in any velocity field into your sim. Create a Source Volume, set it to Initialize > Source Fuel and do away with the fuel and temperature fields inside the Volumes tab (hit the small x), leaving you with just velocity. Make sure the "Velocity from Normals " field you created in SOPs is properly connected to this new Volume Source (SOP Path/Input) and plug the Volume Source into the third input of your pyrosolver. That should work fine.