# HoudiniVellum

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

### Crib notes

Just some scribbling while I watch the masterclasses for the 5th time, I keep forgetting the important bits...

John Lynch Advanced Velum Workflows - Integration methods, some more under-the-hood-stuff, loads of useful theory and practice in here: https://youtu.be/NwabG-znu9Y

Integration

• 1st vs second order integration. 1st is what old grains used, vellum default is second. pbd projects where the particle will go based on its velocity, then takes short steps moving towards that goal until its ‘solved’, or you run out of iterations. 1st order integration doesn’t take into account curved motion, ie constraints, so often innacuratley predicts where the particle should go. This means 2 things, it requires more iterations to get to a good result, but its also constantly losing precision, losing energy, getting less accurate results that take more time.
• second order does a more accurate prediction of where the particle should go, meaning both less solver iterations required, and the result is more accurate. The example is a swinging rope with only gravity; 1st order loses energy and stretches, 2nd order suffers that much less.
• This can be visualise by peeking at the Ppre (P predicted), compare results.
• 5 substeps is recommended, make sure to lower constraint iterations to compensate, otherwise you’re needlessly oversolving
• in real world sims, turn on wind drag (default 0.1)
• xpbd /2nd order’s kryptonite is collisions; without being taken care of it does a bad job of predicting where things will go post bounce, and can look like bouncing/too much energy. Max accelleration can fix this, 100 is the default and possibly too high, lower to 25.

Graph coloring

• Way to split apart constraints into batches that won’t directly affect each other. Why? So they can be run in parallel on the GPU
• LIke usual GPU stuff you watch to send large batches of dumb things once, vs lots of little batches, or worse, frequent updates. Graph colour should generate as few sets as possible, and if you want to update stuff over time better to change attributes rather than be adding/deleting primitives, which require a expensive GPU update
• visual analogy is funky tartan patterns; each prim doesn’t have any neighbours with the same colour.
• default will calm to around 8 batches
• the batch color sop is clever to understand connectivity and whatnto, so more separate pieces of cloth don’t slow down as linearly as you’d expect
• hair batches even more efficiently, often batches of 4
• tet meshes graph colour worse, cos there’s more internal connections, eg 80 batches

solver iterations

• 5 substeps at 20 will get better results than 1 substep of 100 (lower velocities per substep, therefore predictions more accurate, therefore less work for solver and constraints, but will be slower)
• smoothing iterations = how to solve the unsolveable. eg you have infinite stiffness constraints, but you’ve pulled your cloth into a shape where they HAVE to stretch.
• example of cloth wtih only distance (stretch) constraints, no bend, but reduce rest length to half. The solve looks good; the solve is biased so that later graph colour batches are correct, but the first ones run are undersolved.
• smoothing iterations just averages the result and distributes evenly.
• can’t just use this by default though, as it takes a long time to converge.