- [Jeff] Welcome to the Houdini Masterclass on Vellum Cloth. I will be picking up slightly where I left off, talking about how to drape a dress for Tommy and look into some more character effects workflow questions about how to try and polish cloth to make it actually look nice. So the first thing we do is we start off with our previously draped Tommy cloth here, which I have outside of the Vellum Drape node. And what often happens is, well personally I like to keep all the constraints live, and use the constraints in succeeding simulation. A lot of people instead want to just turn it into just raw geometry and restart from scratch, so throw away any stiffness that have been set, any special attachments that have been set, and you start with the geometry over again. The downside of this is you'll bake in all of these wrinkles and curves that you see in the dress but actually often people see that as actually a bright side because it helps preserve whatever you carefully draped in the first place by adding bend angles to preserve those particular angles. It also ensures there's no energy left in the system, where maybe it had to fight a bit in order to get these triangles short enough to fit where their final positions were. By resetting the dress simulation settings, you will have a nice fresh simulation with no energy to start with. So to try and isolate that we can, we first need to actually first fuse stuff together because this was welded together as multiple different panels, so we actually have unique points, across these boundaries, which will make it annoying to try and preserve in the later stages. You can see here I actually didn't drap it very well, we've got some tangled geometry here that I should have draped better, but we'll work with what I have. The Vellum Post Process is a great way to quickly weld things together, so by default this will apply the welds and this will ensure we have only one point along the seams, but you'll notice here that we suddenly have weird normal colors there, and you'll also notice that we have the back of the dress being blue and the front being white. This is because of in the Display options, there is now an option for displaying back faced triangles, the opposite color, and that display option is on by default and actually at first I thought I wouldn't like it with cloth, 'cause cloth you often see both sides of but I found it's quite useful to know what the front side is and the back side is, but here of course, I built the cloth of a couple panels and welded them the opposite way around, so if I use a PolyDoctor, it has an option under topology to Correct Winding of Polygons to the majority. And this makes sure that we have a correctly consistently wound system we don't have the contradiction of normals, because there's just as many polygons facing one way as the other, it's just chance which one it decides will be out and it decides to make the whole dress inside out. So, a quick Reverse SOP will get us back to a good result. So I can use this as my initial conditions on a new simulation, so this simulation. When we restart a simulation like this, there's somethings to watch out for. One is to make sure there's no surprise in ID attributes still around, cause you might have used ID point attributes. If you merge a bunch of pieces of geometry together, you might end up with duplicate IDs, and that will cause confusion and problems and then sew and solve. The other thing to watch out for is, there was a pscale down when we correctly solved this in the Vellum drape world, so this actually has a pscale set to it, which was set by the Vellum Cloth nodes way up here-ish. By default, when I take the geometry and apply a new Vellum Cloth to it, it will set thickness again. If you're not careful, you might reset the thickness to the default 0.01, which might be too big for your geometry. You might need to reset it here. You can also alternatively just turn off the thickness here and I'll use whatever was coming in from the source. From this I can now run a simulation using default parameters, and if I do this with the default result, I will find I don't like the results at all. It looks pretty bad. This happens even if you like the results of the draping step. One of the big differences between the Vellum Solver and the Vellum Drape is the Vellum Drape, by default, runs at one-fifth speed, so this equivalent of doing five sub-steps, but seeing every single sub-step. Cause often you want really fast feedback so you don't have to spend the time seeing it in the correct realtime, but you want it to be stiff and converge properly. How do we find the correct settings to get this cloth to look more like cloth rather than this stretchy bag that it's doing right now? What you basically need to do is unfortunately Vellum is topologically dependent, so the amount of stretchiness you need depends on how these points are connected together, so it's not possible to say that leather has this stiffness, and linen has this stiffness, and just type in nice pre-sets. We'd really love to be able to do that, but we can't at the moment, so instead, you need to try some various wedges of different approaches to find out what settings work best. That's what I've done here. I built a quick Wedge SOP here, so this is just a control interface, which I'm using to control what the active parameters are. This lets me try a bunch of different things, changing the bend value, changing the number of iterations, changing the sub-steps, et cetera, and one of the important ones here, is actually changing the skirt width, and so these are tied into different parts, and most of them are tied into Vellum Cloth, so for example, the compression stiffness, and the stiffness, they're all controlled directly, some are in the Vellum solver, which are sub-steps, or the wind drag, or the friction amount, and some however, are actually up here, control the size of that base panel, based on it, for basically how tight that dress is at the bottom. So, rather than running the simulations locally, I've actually done these on the farm and wedged out the results, so I can play back the results directly. The first step is to try and get realistic sub-steps and iteration counts. In this cause, the default sub-step 1 in 100 is way too stretchy, and doesn't converge, and it's important to point this out because we say we use XPBD, and one of the nice things about XPBD is you don't have to worry about doing too many sub-steps or too many iterations. The cloth will not become infinitely stiff as you do more iterations. This does not however mean that it will always solve completely. If you do too few iterations, it wills stretch, or too few sub-steps. What I like about this graph is it also shows the difference between increasing sub-steps and increasing iterations. Mainly, it's quite useful, especially with cloth to probably go straight to 5 sub-steps because that is probably the same number of iterations in total, but giving the solver a chance to work on a smaller time step really helps it result the energy in a more realistic fashion. What I've used for the ensuing examples is all sub-steps 5, iteration 200. So from that, we can move on to wedging another parameter. In this case, I'm wedging the size of that skirt. Actually, when I first ran all these wedges, I didn't change the skirt size at all, and we had a lot of trouble trying to get the feet to move in a nice fashion, and the problem was that the size of the skirt at the bottom was actually almost smaller than the stride length of Tommy. This meant that Tommy was really yanking the skirt apart when he took a big, wide step forward. I mean really, I guess you could claim that we should have animated a shorter stride if you're going to wear a skirt like this, but can't tell Tommy what to do. If I make it even tighter, you can really see this come to a massive snap every time he moves forward, but if you increase the length then the skirt all of a sudden can flow and get some more interesting behavior. This is something I always found is tailoring is so important for feet and back and get the final look. It's like this. As important it is to get good numbers for your stiffness, and bends and all those things, if your incoming tailoring doesn't move properly, the simulation can't get a good result. So, we stuck with the 1.25 size skirt, and the next one is to deal with the shoulder straps. You can see they sort of float around, and this is partly because they're being lifted up from the rest of the body, so they're allowed to float around, but it also tends to be a result of the static coefficient being too low. The default is 0.5 here. If you put it down to 0, you can see they really just slide back and forth. If we increase it, we can see it starts sticking more to his body. After static, we can look at bend strength. Bend strength is what allows the individual triangles to bend with respect to each other. It's important to note there's actually two parts to the bend strength. One is the bend strength that we're doing here, another is the compression stiffness. Whenever you have a 3D network of triangles that's not planar, the triangles themselves create a certain stiffness. If you've done any engineering, you know that a triangular structure is actually a stiff structure that isn't able to bend, so if you make all those edges perfectly stiff, you can't get bend in. This is working in addition to that. You can see here obviously putting it to 0, it's very small wrinkle sizes. As we increase it, it starts having to have larger and larger areas there together. Ends up being more like a rubber map-point, going with a larger mount. So, we stuck with 0.1, which is actually the default. This is the compression that I started to allude to earlier. If we change the compression, basically it allows these triangles to collapse, but not expand, and so, this thus prevents small micro-wrinkles, because rather than having to fold over, the cloth can just compress in place. You can see here that we've got a lot of very tight crinkly detail when we have a very high compression stiffness, which causes it to create all these nuance folds in the material cause it's forced to bend rather than be able to just compress in place. Whereas, if we have the compression low, it can start to compress in place. The effect of this is it's also showing this ends up being a stiffer fabric in some sense. The next one, we tried playing with air resistance. So, Tommy's actually moving forward in this example. One important thing with cloth is to have some air field present. If you try and do a flap and flag with no air field, it just won't flap. It will be very depressing, but too much air field, of course, and he's like moving through molasses or through water, and you can see the cloth just dragging behind him as a result. The 0.1 is the default that we actually we like here. The last sequence I did was with gravity. 9.8 is of course the proper gravity for the scaled geometry, but gravity really gives you a sense of scale. It ties closely to speed, so if you change the gravity amount it will appear as if time is going faster or slower as well. One way it ends up looking like or scale as well. Things seem bigger if you make them a lower gravity. That's what it corresponds to. If we push gravity up, well probably see here we'll start getting stretching because we needed to change our sub-steps or our iterations to account for the fact that we have stronger forces in the system. So that covers how to try and get a simulation into a more interesting state by running lots of sims and starting to understand how these parameters affect each other, and see what sort of ranges work well for your particular geometry. The next one we're gonna look at will be related to this, which is the question of targeting. First I'm going to look at a simple piece of arm geometry. This is very much programmer art in this case. To start with, I'm going to clear out this paint I had run earlier. So, instead, just look at what happens if I take this bit of purple cloth and I bend it by placing it around a blue wire frame arm. We can see here we have a, it's doing what it should do as cloth, unfortunately there's a problem in terms of art direction, and I want to keep the top of this cloth in place, and so, one way you can do that is by selecting a bunch of points as pin constraints, but that's using point selection and I might not want to have a 100 percent on 100 percent off selection either. What I can do, is paint the input and so I've created here an Attribute Wrangle to set a target weight attribute. This could be any attribute I prefer, and then use a Paint SOP here to target weight. If I enter the state of this Paint SOP, I'm able to now, go in and paint the values. I'm going to actually set a weight of 1, just to pin the points along the top, like so, and then in the Vellum Cloth node, I have no pin set. Instead, use a separate Vellum Constraints node, I set this to Pin to Target. I set the type to Soft. You can see how strong it's gonna be, and I set the strength to 1e+10, but you noticed I selected all the points. So, I'm pinning every single point to the target, so that will become a ridiculously strong pin except I've also here, said the stiffness attribute should use target weight. Now the stiffness attribute does not simply multiply with the stiffness. If it did, the value of 0.1*1e+10 would be 1e+9 and still be infinitely strong stiffness. So it applies on an exponential scale when it's applied, so 0.1 will actually become very weak and 1 will be the full 1e+10. So, after this, if we run the solver, we'll see that we are indeed going to pin the top there. So, the next problem I might have, is I'm happy with the top being pinned, but I want the wrist to be pinned as well, but not strongly pinned. I want to have it still be able to move and pull up, I want it to be snapped down and keep near where it's supposed to be rather than be able to fly completely fluidly like it is in this case. To do that, I can simply paint a weaker pin here. I'll go back to Paint SOP and change my strength to 0.1, and paint in, make sure I'm only displaying this one. I'll also have to put the same ink in if it's slow. Here I'll just paint in the bottom. The next question is what it's going to target. Cause actually if I select this node here, and hit play on it, you'll see that this torus isn't actually animated, which works fine for that top, because the top was stationary, but this bottom, I don't want to pin it to this original stationary place. If I do that, and we'll do that by resetting something that was set by hand here. If I reset this to default, which is first input, and we play this result forward, we're going to see that it is indeed trying to pin there, but it's desperately trying to pin back to that original location. If I freeze it here and turn the visualization of pin to target, we can see there's a whole bunch of points there saying I need to pin back to my original location. That's just not what I want. I want to pin to this location on the arm, but I don't know where it is on the arm. So, what I can do is instead, animate the target. So, this is often the case that if you have a cloth animation for example, you usually can get a rigged cloth version of it. It's either for a preview or just because the rig can capture it anyways, you can capture and deform the cloth with your rig. So, I've simulated there here. I've done a point deform off our arm. This is just a really poorly captured animation of the sleeve, not the actual arm itself, but this is the sleeve in question. I can use this animated sleeve as the target animation rather than the first input to the Vellum Cloth. You do this the Vellum Solver or there's a choice in the Advance tab for what the target should be. Set it to a SOP path, point to this TARGET node, and now it's going to try and target that animated version rather than the static version, so that we'll correctly anticipate where we want to actually be. So, turn off the visualization of the target and we can see here, that it's not quite matching, but it's trying to match towards that because it's using a weak pin constraint. I'll turn off the display there. Unlike before, it's not free to move where ever it wants at the end. That's going to keep the sleeve where I key frame animated it to be and let the rest bounce around as it feels like. I can use this targeting idea for more than just pinning to a one to one relationship, however. We can also use it to do resolution retargeting. I'm currently just cooking three version of the simulation that's why it's running forward 36 frames right now. Okay, that's been cached, and now we're able to look at the three results. When we first go through and look at them individually, hopefully not reset the cache in the process. The first thing we have, is we have a grid at the top. Hide everything else. This is falling on to a rotating sphere, and so we run a simple Vellum Solver on that and we'll have to create fall, and rotate around, and that's wonderful, but now let's say, we like this animation, we want to run it at a higher resolution. If you just subdivide the mesh, as one way to get a high resolution, and subdivide the ball to get a high resolution version of that, and then decide, okay, I'm going to run IO Vellum Cloth, on the high res, with that high res collider, and run this result, we will indeed get a high res simulation, but the simulations gonna have different results than we had in the low rise version mainly because there is more room for it to move, you're going to get different crinkles form, you're also going to get different levels of stretchiness, or lack of stretchiness. It's gonna bend tighter around the sphere because it has more ability to bend tight around the sphere, and so you're going to get a different simulation out of it. But you might have been happy with the low res did and you just want more detail. You don't want to have a different cloth behavior. So, solution to that is, we can go and subdivide the low res version that we already simulated, we can subdivide that, and so this can become our target, and so this is sort of like a high res version of it, but we want to be sort of like this, but not quite, because we want to deviate a little bit. We time shift that to get the frame 1 version of it as a reference, and this, we can also use as our target position, just like before, and we can paint it. So here, I've painted the edges with a light 10 percent interest level. Just like before, we set a Vellum Pin to Target, set the target weight to this, and now when we run this solve, we will see we get a behavior that is similar to the low res version, but has the extra crinkles and stuff of the high res version but the position of the bottom edge is matching the low res version. I've got here a display to show all three of them together, so we can see that the low res version we're seeing similar behavior here on these edges and timing on the edges. Not exactly the same because we're allowing it to deviate a bit. We're getting basically the same set of folds, whereas in the high res, it was doing something completely different at this point. This is useful if you need to match a silhouette or match the timing of something else that you thought worked out in the low res. It is important to note that you need to feather how this high to low res goes in terms of the set in it because if you make it too strong, it will basically end up matching that subdivided version exactly, and we switch between them, it might seem we have a bend or a crinkle there, which of course, is not desired. You want to use the smooth tool to feather off how these weights increase and decrease. Now, we're looking at attachment. We can look at attaching stuff to Tommy. Okay, so here I've allowed to be seen. We have a cool superhero cape for Tommy. It's a bit cooler than what I usually get him to wear. Let's look at how I built this up. There's an interesting point about reattaching that shows up with it. First of all, I'm going to hide other geometry and just look at what I have here. I started off my drawing a curve for the general cape shape. If I template the Tommy himself, we can see here, that I tried to set the plane around the right location, and then drew a couple of circles around his head and his body. Thinking something that looked relative right. This I then resampled down to get a light weight curve equivalent, and then I want these to become single polygons, so I used Fuse, until increasing size, until they finally matched. The one in this case was pretty high of a fuse rate. Then I did some final tweaking. I did this after diffuse because then I don't have to worry about. Tweaking ahead of time might change point counts or fuse amount. Here I've got my close loops that I'm just using as my initial points. Throw another resample in to make them nicely rounded. I like how we can use the subdivision curves to do this, so there's an option here to do subdivision curves, rather than just resampling straight or interpolating. Subdivision gives these nice smooth results from my jagged programmer choices of points. One trouble though, is this will unique the points, and so after running the subdivision curve option, you're gonna get duplicate points here, somewhere around here-ish, you'll see a duplicate there, and there's one somewhere on this curve, and I want to fuse it again to make sure these are closed loops. That's because planar patch from curves, which is closed loops to be able to tell where to generate them. If I run planar patch from curves, you know it's a problem namely, I want a hole where his head is, but this doesn't seem to have done it. But if you look very carefully, you can see that planar patch from curve does properly preserve that internal boundary. There is a loop of points that represents it, but how can I separate off that inside from that outside? Well, to start with, I'm gonna go through and first just make sure I've got them all numbered. This is because I want to be able to correspond points properly. Then I switch to extract centroid, and extract centroid allows me to breakup by each piece. In this case, each index, and this basically gives each polygon it's own unique number, and then each polygon gets its own unique poin from this. This computes a dual, as it's called, very effectively, so I've got one point per primitive, and that point is in the middle of the primitive. The advantage of that, is we have a new SOP called the Winding Number SOP. This is a rather complicated SOP in some sense, but it's really useful for doing this inside out side task. Particularly, I can tell it to run in 2D, and given a curve network, which I have up here, tell me how many times that point is inside of that curve network. Given these points here, it'll compute this winding number for each of them. If I do the info guide for this, and then click on winding number, it'll color by winding number. You can see, we definitely have a difference of winding number for the ones inside and the outside. So, in this case, I can delete all the ones whose one number is greater than 1.5, and that'll immediately select out what I want from my set. Then of course, I find out, as inevitable the case, I actually have an intersect at the shoulders at this point, so I need to bump it up a little bit in order to create the valid initial cape configuration. So, all that, let's turn it into cloth, and we use the Drape SOP, and say, yep, we've got a nice initial drape here. We're happy, but one problem is, is if I disable this attachment here, instead, go straight to a solve, and we're now gonna solve this cape on a slightly different Tommy. This Tommy's falling downwards, and so the cape will quickly fall off his head. You can see it falls off his head, in the most embarrassing fashion. So, what you usually have to do with superhero capes, is you need to glue them to the actor to make sure they don't move around too much, or apply some pins to them. You don't want to do pins in this case, because he doesn't have any clothes underneath, so it would be right on his skin, and that would be very painful, so I recommend glue instead. The attach here is how we can do that. This attaches to the gray input, and I selected the points here, you can see which ones I selected by click to this, I select them right along the front here, and I gave them a lower stiffness, so like a weak 1000 stiffness there, and they're told to constraint the closest location on the primitive, so basically find where they are on the primitive, and stick themselves to that distance above the primitive. It's important to note, that if this was a distance away from the primitive, they'll preserve that, but not that distance in the normal direction. They'll still rotate around that constrained location, they don't latch themselves onto that normal location. In this case, that works. I've now got a Tommy attachment. If I move my camera with it, keep the neck intact, so it's not allowed to come fully off. So, that's great, I'm happy. I've tested this out and I will send this rig to someone else. Let's use the Vellum Pack. This will take this geometry along with all the constraints, and bring it into a single geometry. I can time shift that to make it not time dependent, so it's just living on frame one. Then let's unpack it later. Maybe we load it from disk or a totally different file or something, and I'll go down here, and I will ignore this node here. Instead, I'll just tell it to collide with this one, but this new one has a slightly different animation. This one is flying to the side, rather than down, but if I play back this, and we get a very surprising result. Namely, the neck line has not been pinned to my moving geometry to the right. It's been pinned in a totally different direction, and if I display the visualize, and display pin to target, oh, that's right, attached to geometry is what this one is, get it right one of these days, we'll see that it's actually attaching way down here. This is because the saved geometry stores the SOP it's supposed to attach to. It doesn't store that it wants to attach to the direct most input. So, it doesn't get over written when we run this new Vellum Solver. This is a good thing, cause it can use multiple Vellum attaches to attach to different things, but it can be very surprising in cases like this where you expect it to attach to my new geometry. The advantage is, is all this information is being stored as normal geometry, so if I go to the Null, and go to a geometry spreadsheet for this, we can see that there is an option on it for target path, and so I scroll to the bottom, we'll see, yes, there's all these people that are saying I need to attach to /obj/cape/transform2, and that comes from up here. They've basically stole this node name and recorded that that's what they should attach to. I don't want them to attach that anymore though, I want them to attach this node, so I choose attributes stringed at it, and this let's me just change whatever ends with transform2 with something that ends with ATTACH, and after that operation, we should see the attachment now correctly following the new geometry. So, usually, that sort of replacement can be done with an attribute string that it just update the new node names, but if you have a particular rig, you might even get away with always using the same named node, cause if you have the same path and name to it, it will just rediscover the node, and appear to without any changes, but it's important to be aware of it for the cases where it doesn't work. While looking at stuff that doesn't work, I think I should also, at this point, look into one problem that can occur, which is bouncing cloth. One of the important physical properties of cloth is that if you take a big chunk of cloth, such as this one here, and we drop it on this cube, is, it won't bounce. But here, you see it does bounce. So, this is very distressing when it happens because we naturally don't want that. If you're looking for the bounce settings in the Vellum Solver or Vellum object, for the bounce settings in the whole system. You won't find any because PBD really doesn't have bounce cause it's not able to bounce, but that's clearly a lie, when I'm seeing it bounce here. Where is this bounce coming from? This bounce is being triggered by the second order integration method, so this is a way to predict how the cloth is moving over time, and if it predicts properly, we're able to greatly reduce the number of constraints required to solve and improve the liveliness of the simulation. When it predicts poorly, we end up with exactly this sort of ridiculous bounce. What we've done in later versions, we've actually improved this, so hopefully this default setting won't bounce for you right now. But you might still end up with bounce depending on your settings. It's important to know how to fix it, if you do see it. So, the worst way to fix it is, there's an option in the Advance Integration, to go second or, first order, so if I switch it to First Order and hit play, we'll see it properly not bounce, but as I'll show in the next file, it's not something you want to just do by default, cause you lose a lot of energy and a lot of potential stretchiness. What you need to do instead, is adjust the max acceleration. Here, we have an option on the node for max acceleration, the default used to be 100, that was a bit too conservative. We've changed the default in later versions, after the first production build, and it'll default to 30, and with that, this particular case doesn't bounce. So, I can actually show the fall off amount. So, here, I'm coloring it based on whether or not fall off occurs, and if I go forward, we can see in this one particular frame it turns white. This means that the Solver has detected that the collision has resulted in more than three gravities of acceleration, and so this means that the second order prediction's going to wrong, and so it switches back to first order integration at this point, and thus avoids the bounce. But it's using the second order integration all the other times in there by getting the nice properties that we want out of second order. But I really don't want to just believe in the second order just because I say so, and I definitely don't want to just switch it to first order because you don't want to deal with occasional bounciness, so I have an example here, just to show why first verses second order's important. These are two identical pieces of cloth. The big difference is, one is at the default second order integration, and one is at the first order integration. If I hit play here, we can see quickly enough there's a difference between the two. So, to show which one's which, I'll display this one here, and we can see this is the first order. We can see it's very stretchy compared to the second order because it wasn't able to predict this sort of swinging pendulum motion that often happens with cloth, and as a result, the constraint iteration had to keep fighting to pull the points up, and isn't as effective. Here it has less work to do cause I correctly predicted it. The other thing is, this results in dampen, in other words, a loss of energy. We can see that the second order one's a lot livelier and more interesting how it's simulated, whereas this one is just more viscous and has lost more energy even though they both had the same air resistance and same other properties. Another thing we commonly face is of course, getting strange movement into our simulations. We often don't have control over what we're asked to put cloth on top of, and while we'd like it to always be nice realistic behavior, often it isn't, and we need to have ways to deal with that. In this case, I have my same dress as before and I however have a body geometry here, which has got a very fast movement associated with it, so it's going to jerk very quickly over to the right and then stop. So, to make this more obvious I have here a default Vellum Solver, except the big difference is I changed the wind drag to 10, to make the wind more apparent. So, if we play forward here, we'll see as soon as Tommy starts flying to the side, that the incredibly strong wind is something that really holds the cloth back, and we get this horrible stretching and it's a lot of work to try and edit this. This might be realistic for how quickly he is moving inside this thick atmosphere that we've set up, but it might be, you don't care what's realistic, you just want it to have the same amount of wind drag when he's still. See, like that, but when he's moving, you just want him to move less, but you want to move the same distance. So, one solution is to change the wind force dynamically. In other words, speed up the wind, to always be the same speed that Tommy's moving in. Make it relativistic to Tommy's frame of reference, is another way of looking at it. So, we can do that. We first decide what we want to make it relative to. You might have had, for example, capture deformed version of this cloth they could use as the relative frame, or sometimes the collision object, or maybe there's a camera you can use throughout the frame. Whatever it is, you can use this same technique. I start off with his body, I get a reference version of it at frame 1, and then I run extract transform. Extract transform lets you just get the rigid position that best matches. Provided the point counts and the point order stays the same, this could be a deforming geometry, and it'll still not be confused, and find the best transform that works with it. Giving the single point that you see in the center, I can use the point velocity to compute what the speed of that point is at any particular frame. So then, this point velocity, I just made a Null SOP, or I just read off the point velocity. This just lets me see it and do channel references easily. Like maybe I want to have a scaled version of this. I can go to the Vellum Solver and set my wind speed to refer to that compute wind speed and now when I display the correct solution, we'll see that the wind speed of this simulation will roughly match the speed of Tommy himself, and so we'll get no actual sudden jerk from the wind. We're still getting acceleration here because Tommy is hitting and dragging the cloth, and it has it's own inertia where it's not necessarily responding to the wind right away, but we've been able to cancel out most of the wind caused by his motion, and still get some light effect from it. You can also scale this, obviously, you don't need to use 100 percent of it, or do something like use only one dimension, like maybe, there's some Y motion that's detected but you don't want any Y in the resulting wind speed because that might cause the skirt to rise or lower, so you can just set that to zero, and ignore whatever the computed amount is. In addition to the wind speed, there's another component to this, which is the collision component. I still have Tommy actually hitting the side of that because he's actually moving quickly to the side. This might not be something you can get rid of using just wind speed type hacks. So, here, I've reduced the wind drag back to 0.1, so it's not having too much of an affect directly, and instead, what I'm going to do is look at what happens by changing the frame of reference entirely. So, first I'll switch it back to doing the raw solve, so we can see what that is, using a zero wind world. I don't have a wind force of 10 here, I have a wind drag of 0.1. This is mostly coming from the inertia of the cloth not wanting to move to the side quickly, and just the collision of the leg against the side. So, you can see we get that massive yank, jerk to the side. Alternatively, I can say I want to reframe my reference down to a new world, and I can do this by starting with whatever I'm going to use my frame of reference. Doing the same extract transform as before, which gives me this animated point, but then I can do a simple SOP solver to find out a new position over time, but this is what I'm gonna clamp with the maximum acceleration is at any particular point. I've done this with this pair of nodes here. That can be done, just cut and paste it for your own use. This is the max acceleration parameter I promoted. So, the idea of this is first I store my original position of this thing as old pause and initial pause, and inside the solver, I dive in here. I've got my previous frame, and I've got my new animated position. My new animated position, I can compare against the old true position it had and from that I can compute a velocity of that object at that time, and then I can compute an acceleration that that refers to. Then I can do a clamp of that acceleration with our actually maximum acceleration that we've got as a parameter, and then reintegrate back the velocity and the position, to create a new actual position output. What this looks like is if I look at this single point, we're going to see it now lags behind Tommy himself. It still moves with him, it just moves slower because I had to clamp that 10 acceleration. So, one acceleration. If we do 10 acceleration, it can move faster, but not move it, because I guess he has around 20 acceleration. If I unclamp the acceleration to make it very high, we're going to get something that just matches it precisely. This way I can control what's the maximum acceleration my cloth will experience from collisions using this. So, setting it back down to one means I'll still see a jerk to the side, but a very small movement to this side. Let's make this like 3, so we have only small motion. Now, I can then do apply data, and this apply data here will just subtract the difference between the two worlds from every point. This causes my collision object to move this smaller amount. Because the Vellum Solver isn't caring about velocities on the collision object, I don't have to recompute those. I can just move the points and get the right result. So, here I have a matched wind version, so like before, this is just grabbing the point velocity of that computed damped position, so the wind is in the same space as Tommy. Otherwise, it's got the same motion. Here we're going to see it move, but it's going to move only a small amount because of the clamped acceleration. We can see here, in gray, that's the actual collision geometry, which is of course moving a lot faster, but the blue is the collision geometry which the Vellum Solver is seeing, which moves slowly, letting us get this slight push to the side, but not the huge push we'd get if we moved the official distance. I can do the opposite of the add delta to remove the delta, and I do this to my resulting Vellum object, once he quickly flies off to the side, now it's been put back in the correct space, and so I'm seeing what I should see in the end. Now, of course at this point, all the velocities that Vellum computed will be wrong because they were done in this earlier space. It's important to do a point velocity to recompute the actual velocities from how it actually moved in the end, because that will change. Continuing this idea of getting bad initial geometry, quite often you might get stuff like this, where you've got a piece of cloth and a collision object, but the cloth is already collide in the collision object in your first frame. If I animate this, well see that Vellum will basically trap those points inside, because it doesn't know that they're on the wrong side. You'll end up getting stuck inside, and it's not able to actually pull it out. Ideally of course, you could push this out through some operation and get on the correct side. Maybe you've got a SDF and can push it out from that, but alternatively what you can also do is do this approach. I can group the points that are inside, in this case by using an inside test, and then disable external collision value set. Once set originally to a value of 1, and this is what's usually done if you don't want points to collide with external objects, so I put a virtual hole in my cloth here, and if I run this, we should see the cloth is now able to slide out. One problem though is you can see that even though it slid out, it gets to fall back in again. We've sort of got this primitive hole in our object that we don't want. We want those to be opened up when they get resolved. Now, fortunately Vellum has a way to automatically resolve external collisions that are now correct. What we need to do is tell it disable external of 2. 2 tells it that this is an automated disable, and so as soon as these points become untangled it will re-enable them again. So, in this case, as soon as they're free up, you can see that they turn off and that way when it falls back down, there's no longer a hole in my cloth. As soon as it gets pulled out, it works. Similar to that idea is this one where we have basically a rock in a hard place. We've got a piece of cloth and we have a sphere and a torus and we have a torus come down and crush the cloth and go right though, and then leave again, and so when it crushes the cloth, Vellum is smart enough, yea, to mark those points as disabled, and they weren't able to handle external collisions properly so they're now turned off, but there's nothing currently restoring them to the correct side of this collision, and so they stay on the wrong side and just sort of float there, and we don't get them resolved over time. What you can do in cases like this is double up the collisions. This sphere is currently added as a static object, but it was created using the static object tool, so it has both a VDB and a non-VDB collision associated with it, and by default, the collisions is set to use Solver default, and for Vellum this means to basically use surface collisions, but here I could just cut and paste this node twice, and this new copy of it is also set to volume sample from the VDB, but I change it to use volume collision, so this'll force it to use volume collisions for this one. So, if I use both, we basically can have the surface collisions of the sphere, properly keep all these sharp points, but the SDF collisions can ensure we can restore the correct size. If we run this forward, we'll see the torus crushes it, they turn yellow, but when they come back up again, most of them are able to be restored and end up on the correct side. The downside of this of course is you have to build an SDF every frame, which is very annoying if you have animated characters, but it might be important. You can thus have the surface collisions handle basically all the sharp fingers and other bits that SDFs can't handle while the low res SDF can keep stuff outside where necessary. So, in this case, this is the arm that we've seen earlier, except I've decided to up the ante and add a few more layers of cloth around it. I've got quite a few layers of cloth here, and I'm going to disable this by default here, so you can see what happens with no, and reset this, so this is now back to pretty much default values for this operation. So hit Play. We're going to see the red circles here where our self intersections fail, and see if we start to have a bunch right where it hit here, it couldn't resolve them. And similarly at the back, it starts failing a lot, very quickly. It's seeing the other color poke through, which is not desired. So the first rule to resolve this sort of problem is to have more post collision passes. In particular, the rough rule of thumb is three plus the number of layers, so, here I can switch to eight passes, and these extra passes are a lot cheaper than you expect them to be. They're a lot cheaper than full collision passes are cause they're only applied to the points they're actually failing the collision, but it helps the system better resolve these things that might need multiple passes to get to. See here, the back is doing much better than it was before, and now it's just the front, but it's still failing more than I would like. The next level is to give the Solver a hint, and so the problem is it acts as an unbiased system where each of these layers is trying to get out of the way of the other layers, but really there's a certain order it must be resolved in. The layer on the top, if it doesn't move out of the way, the one's underneath have nothing they can do, so it's important that it's made lighter than the ones underneath, so that that knows it should move out of the way more than they should. But you don't have to make it too light because obviously then, it'll become just a one-way interaction where you just simulate one layer, then simulate a layer on top, and a layer on top of that. So you can get a combination between the two worlds using the Layer Shock ability. To enable this, all you have to do is have a point attribute called layer, which is an integer, and the higher the layer number is, the lighter it will be, but the lightness is only dependent on the difference of the layers, so not the main attribute difference, but just one being bigger than the other. So, if I have layer2 and layer5, layer5 will act to be four times lighter, because a layer shock of four. If I have layer2 and layer100, it will still be only four times lighter. I'll add back this copynum attribute, which creates a layer attribute, and so with this, hopefully I will get this self collision failures as it's able to resolve them in order. In this corner here, I'll still get a fair bit cause it gets very crinkled up here. But hopefully, the outer layer ends up resetting correctly at the end. Particularly, you can see the outer arm is kept the same and succeeded, as has this leading edge. So for this example we're gonna look at another problem that can come in with your incoming animation. To motivate this, I'm going to start with this geometry here. This is a simulation that we've theoretically been given. It's a walk cycle, but there's something wrong with the walk cycle, namely this arm is going, not only is the thumb cutting right through the thigh, but this arm up here, the flab of the arm is hitting right against the chest and this leaves absolutely no space for cloth to be. There's no hope for a cloth solver here, and we'll have to start disabling stuff. Vellum will try its best, but it's way happier in the world if you can put a gap in there somehow. Ideally you could send it back to the rigging department and they would invent someway that makes it all gap free, or send it back to animators and ask them not to be gap free, but you might not have that luxury, and you need to just somehow break open this part. So, what I've done here, is I've isolated just part of this geometry, just to make things faster, and then I went and decided to, just like before, to create a pin attribute, and I painted the pin attribute. The idea here is I want all these red areas to be preserved exactly, and the green is where I'm allowing it to have some give. So, I don't particularly care about the position of those points. It's important to note the position of these points are not your final render points. This is just going to drive the collision geometry of the Vellum Cloth solve. The actual render geometry will be the original geometry. Any flex or whatnot that I've got in this will not show up in that. So, having selected those ones, I can then go and makes some Vellum constraints, so I'm gonna switch back to frame 1 here, and we make a cloth setup of the whole thing, and I set soft pins, set to match to animation's important here. I set this for everything whose pin value's strictly less than 1. This avoids creating pins for all these purely red points. I do this because I have a stiffness of only 10,000 I'm using, and so I'm varying basically stiffness of this area using that falloff idea. Then for the hard pins, I set everything that has a pin of one, that was painted full red, to be a hard constraint. So, first off, I'm just drawing this with a soft match animation. Just as a didactic example, so let's see what happens when we solve this version. The idea here is the strong pin constraints will thus be exactly enforced because I got a one E 10 strength, but the soft ones will be able to flap around and get out of the way. This is the key point here. Let's see, we're starting to get the collision resolved. All right, so if I dive in here, we should see, there we go, good. I was afraid it wasn't showing what I wanted to point out. As the hand came in here, it hit the really strong pin constraints, who deformed out of the way, which is what we want. However, you can see it also dragged those hard pin constraints over. This is because one E
10 isn't enough infinity and so these points are still able to move, and in particular, collisions tend to trump the actual pin constraints themselves. So, if you want something perfectly pinned despite collisions, you have to do more than just set a very high value on a soft pin, you want to actually set a hard pin. I'm going to go back and reset it now, and we're going to do it with an actual hard pin constraint. I'm going to do it as permanent in this case cause I don't want to reactivate it. It's more efficient to do it permanently, but again, we'll make sure we have match to animation turned on, so now when I hit play. So now when we zoom in, hopefully we'll see more of a sensible behavior. We don't have any motion on the other points. Now we still have that hand getting trapped on there, which is not good because we're getting a really bogus collision geometry. This is again, due to sub-steps being too aggressively low, so if I rerun the simulation with let's say five sub-steps, notice it's slower, but it's not quite five times slower, which is always nice. As the arm comes in, we should get a better collision geometry this time. As you can see here, it slid out of the way, thus leaving a gap for any potential pants to fit. Really in some ways I just want to chop off the hands in this case. I mean, more practical is probably what I did over with the inner arm, where it leaves a gap between the torso and the inner arm, allowing the shirt to fold over in there, and obey both sets of constraints without having to disable. So, thank you very much for joining me for this Masterclass on cloth and I look forward to seeing what cool things can be done with Vellum, so thank you very much.
