Hello and welcome to the master class on Vellum. This will hopefully be the first in a series which will cover the different parts of the new Vellum solver in Houdini. Now, to start with, let us begin with the traditional thing for any form of cloth simulation, in linear a simple grid. I'll start with a grid, and I'll go to the Vellum shelf tool and choose to turn it into cloth. After doing so, I'll select my grid, and we now have a piece of cloth that will fall down as we expect it to do. Now this, of course, isn't very interesting, so let's take a look at what nodes were created. First, we note that it created a DOP network to house the resulting Vellum simulation in this cloth_vellum node, which is storing the output of the simulation. Meanwhile, my input grid is sitting over here as a separate object, so if I look at the output, you can see this has just merged in all my input geometry from the Vellum world, and brought it together into this vellum_io node, and interesting point here you might notice is there's actually two imports present. One is importing the geometry and one is importing the constraint geometry, and both of these were saved together when we save out to this simulation, and at the end, there's a post process we'll go into later. If we look at what happened to our original grid object, we can see that we have this Vellum constraints node added that afterwards, this Vellum constraints node generated two outputs, one gray output here that's storing the geometry, which I can display here, which is just that original set of squares, and the second storing the constraint geometry, which we can see on this output here. The idea of the constraint geometry is something that will be familiar if you've done bullet simulations in the past, namely that this is a set of rules expressing how these points need to be bound together during the simulation, so if I switch to the geometry spreadsheet, and look at the primitives here, these are the primitives of the constraint geometry. I can see that each of them has a type with it, and most of these are of type distance, so these take two points, and demand that those points stay a certain distance together, which is stored here in the rest length. If I scroll down, however, we can see there's also a bunch of bend constraints. These actually refer to four points, and say that the dihedral angle, or the angle between the two triangles defined by those four points, must be at a certain distance, and that distance, in this case, is the rest length. This length here is actually an angle, not a distance, so we have these two outputs, and they end up going together into our DOP simulation, so let's look at what happened in the DOP simulation, and we can see here we have a Vellum object. This is very similar to how POPs lays out its simulation network, so in POPs we'd have a POP object at the top, which usually is just used for general setup, and below that we'd have a POP solver, which is controlling all the global solve properties of the particles, and then, to add more particles to the scene, you'd use a POP source. In this case, we have Vellum object, and Vellum source, and Vellum solver, so we can see there's a lot of consistency to how this is laid out, so if we hit Play, we can see this, again, falls as we expect it to do. Now let's pin this class. We'll get something a little bit more interesting, and I'm going to also increase the resolution of the grid. Vellum is a hardware-accelerated system, and so it uses the GPU for a lot of its computations, and GPUs really don't like to get out of bed in the morning for anything less than 1,000 polygons, so starting with a 10-by-10 cloth is being kind of unfair to it, so on this Vellum cloth constraints, there's an option to pin points, so I can use this to pin a couple points on either side of the cloth, and now when I hit Play, we should see the cloth fall and form a bridge, because it's being held up by two points. Now, one of the neat things about the Vellum system is that it is a integrated multiphysics system, so we're able to describe more types of material than just cloth using these constraints, so another type of material I can describe is a hair, and I'm going to do that by first drawing some curves on the screen, so I'm using Draw Curve, and this gives me a plane to try and draw the curves on. The default XY isn't too useful for me, so I'll change that to ZX, and pull it up a bit so these curves won't be drawn directly on top, and now I can draw a couple interesting lines, and if I look at the point display for these, I can see I've got way too many points in some locations, and fewer in other places, and so, for Vellum, it's a point-based system, so it's very useful to resample the points to be more consistent with how I want things to work, so throw a Resample SOP on, and now I can ask these points to please become a Vellum live object, and so there is the Vellum Hair tool here on the Vellum shelf tool, and I can specify this set, and now, when I hit Play, we will have both the hair and the cloth solving, interacting together. Now, these wires are more than just distance constraints. They also have sort of bend and twist constraints in them, so the bend constraints, it's kind of obvious how those work with hair, but twist is kind of an important point, because this is sort of how we can have a torsional force in the hair, and this is what allows them to maintain sort of helixes and other sorts of interesting shapes, so this is all falling off, so let's put a ground plane in so things are holding up better, so lower that a bit so they've got a little bit to fall, but not too far. Okay, that's not nearly far enough. Okay, so that's some hair and some cloth, and so let's add some other types. Before we had test geometry, the favorite thing for us programmers was always to use toruses, and in honor of that, I'm going to bring in some toruses now, and turn them into geometry as well, so I'm gonna go over to Vellum, and I'm going to make this into a Vellum balloon. The Vellum balloon is similar to cloth, where we define a surface, cloth-like surface to it, but we also define an extra constraint, called a pressure constraint, which maintains the global volume of the balloon, so this allows us to compress in one place, as long as it expands somewhere else to account for it, so it's gonna be somewhat uncontrollable, 'cause just like a real balloon, if you squeeze it in one spot, unexpected areas expand, but it produces a very cool effect out of the box, like that, and again, over here is the DOP network which has been generated so far. You can see we have these three objects here coming in as separate Vellum sources, one for the curve, and one for the grid, and one for the balloon, and similarly, at the top level, I'll lay this out, and we can see we have our torus here. It's where we defined our balloon. It was just defined by cloth constraints for the surface, followed by this pressure constraint to preserve the interior. Now let's add another torus. This torus, however, I'm going to set up a bit differently. I'm going to turn this one into a soft body. The soft body that we generate here is a bit of a approximation of a soft body, and so let's hit play so we can see what it looks like first. You can see it's clearly a lot more rigid than the balloon was, so if I go to the second torus and look at its setup, we can see we again have a cloth which defines this surface behavior, namely the bend and distance constraints around the surface, but we also have what are called strut constraints, and these are sort of like matchsticks or chopsticks, which are basically used to hold up the interior, so these are automatically created by this tool to connect sort of opposite points without crossing over any interior surface, and they become distance constraints, which hold it apart. Unfortunately, this sort of setup can show up as artifacts in the resulting simulation, but the big advantage is this works with almost any type of geometry, unlike a tetrahedral solution, where you have to be very careful about what you put into it, we found this can work with just about anything, which makes it a lot more fun to work with, so we have these three, four actually, if I'm counting properly, and now there is one more additional type of Vellum that I can add on the shelf here, and this is called Vellum grains. This is quite appropriate, because the Vellum solver is very much a continuation of our old grains solver, which is still here on the shelf tool for those that are used to using it, so it's only logical we're also able to include grains in this system, so I'm gonna add a new box of grains to the setup. First put down a box. Let's move that down somewhere interesting. Turn it into Vellum grains, and now let's go and change the box to be a little bit bigger, and shaded view so you can actually see these, and if we hit play, one thing you'll notice right away is this is running a lot slower than it was before. This is actually not because the grains are slower. This is because what the grains tool did, when I selected Vellum grains, was immediately change my substepping. The grains solver is more sensitive, and it's less able to take large substeps in things like the cloth and the soft body solvers, so whenever you use the grain solver, we always increase our substeps to at least 5 so you have a more pleasant initial experience, but sometimes, for cloth simulations, you'll also probably have already raised it to 5, in which case this would be the normal result, so we can see here we now have a system which is combining both the grains, the soft bodies, the balloons, the hair, and the cloth, all together in one place. Now, if we look up here, I said I was finished all the examples, but there's still another example on here called Simple Cloth, and this is actually a rather exciting part of what we've done with Vellum, is we've not only built our traditional DOP tools for Vellum, but we've also built a SOP, or a geometry-level interface for it. This is something we've noticed a lot of our customers have been doing anyways, where they take a DOP simulation, and they sort of build a rig for it inside the geometry context, which allows people to work with it without having to deal with all the complexities of setting it up, and we realized let's do this and ship it with Houdini so you don't have to first reinvent the wheel every single time, and so that's what we've done with this Simple Cloth. One advantage of this, if you're a Houdini Core user, is that while these tools only exist in Houdini FX, this is a SOP-only tool, so you can find it either in the viewport, by typing in simple cloth, or, I believe, currently it's in the Characters shelf. Actually, it's not in the Characters shelf, so we've moved it somewhere else. It is in the Rigging shelf. Did I get this right? I got this right, yes. Along with the new post-based deformation tool. Now, my confusion there is because it wasn't quite clear where this belonged in the normal Core tools, but is it part of the rigging process, or is it after the rigging process? So, we've ended up putting this rigging place right now, so there it is. I'm glad I'm using a late-enough version. I'm not sending you in a wrong direction, so I'm gonna delete all this, but first I'm going to save it, because some of you will be asking me, can you please provide these files? So, I will now save this, and there we go, so hopefully I'll be able to find that file and show it to you later, so I'm going to now reset, delete everything. Actually, I'm gonna File>New, 'cause otherwise I'll probably accidentally overwrite that file, and you'll then be disappointed with me, so let us now start and try out this new Simple Cloth tool. The use of the Simple Cloth tool is basically twofold. One is for quick cloth effects, and the other is probably for applying cloth to an existing character. Now, I don't have an existing character here, so I'm going to do a quick cloth effect, in particular I'm going to put down a grid, and make myself a flag, so again, that is a pretty standard thing you want to do with cloth, so let's make this in the XY direction, here we go, and I don't particularly like such a tall flag, if we want more, if we're not in Switzerland. We want more of a 2:1 ratio, and just eyeball it there, increase our resolution appropriately, and now I want a flagpole, of course, so let's add a tube, and move this over to be our flagpole, change our radius down significantly, and lots of height, nice tall flagpole, which that means it goes, oops, it goes very far down, and that's, yeah, that's looking good. I'll make it in the polygons, add endcaps. There we go. We have a nice flagpole to go with it as well, so now let's go to the Simple Cloth tool, and the Simple Cloth tool will first ask me which object I want to turn into cloth, and this case will be the flag, and then what collision object I want. In this case I'll pick the flagpole, 'cause we don't want the cloth going through the flagpole, obviously, so this is gonna do a different setup than we had before. Previously, we ended up with a DOP network up here, but now you know that there is no DOP network. Instead, there is a new grid object cloth, which is doing our solver, but you don't see any auto-DOP network. If we dive in, we can see why is we've merged in that cloth geometry, and we've merged in the tube geometry, and we've put them both together into those cloth constraints, but now we have this chain of nodes entirely in SOPs, which is defined in our solver in applying the solver, so if I display last node here, and hit Play, we'll see the piece of cloth successfully fall down to the ground, except we don't have ground defined here, so let's add a ground plane, so it's got somewhere to fall to. This is defined in the cloth solver, in the collisions option. This is a place to put a ground plane in. Can see here I've got the wireframe showing me my various colliders that are active, and so we can turn that on, and we'll see the cloth hit the ground, as we expect. Let's add some wind, because a flag with no wind is pretty boring, and let's just blow it into the flagpole to make it more interesting, so in the forces page we've got the ability to set gravity, wind, and wind drag, so wind I'll do in -10 and see how that looks, and there we can see it's being blown back into that flagpole, so we see the flagpole is being used as a collider here. But let's make it +10, 'cause that's a more impressive flag direction. There we go, but now we wanna pin the corners, so we go to the cloth constraints, and here I can select the pin to points, and select some points to pin, like here, and hold down Shift and select these, and now when I play this, I should see the cloth, indeed, get pinned to the flagpole. Hurrah, I've got a flapping flag. Now, in this whole system here, you can see something that's relatively different than how most of our SOPs work. Usually, our SOPs are a single chain of nodes, with a single wire going between them. Those of you that have used the grooming workflow will be less surprised by this, 'cause the grooming tools have had this sort of triple chain previously, but we've started to adopt this more completely throughout Houdini and Houdini 17. You'll also see these show up in the new RBD Fracture tools for a similar reason, so the reason we did this was because we really wanted to be able to have you do all the setup for these cloth simulations inside of the SOP network, and this required you to work with two things at the same time. One is your actual geometry itself, which is your flag, for example, but the other is the set of constraints on the geometry. Now, we could put them both in the same geometry object, except then it gets very tricky to know which one to display, and which one to see, and if they have attributes in common you end up having them conflict with each other, and stuff like the geometry spreadsheet would get very complicated as you'd have all these extra attributes to deal with, constraints that don't belong for your object, and so we wanted to keep them distinct and clear. Inside the dynamics world this is pretty straightforward. In the dynamics world, we're able to have separate simulation data, so we have a geometry attached as one data, and constraint geometry as another, and we're able to keep those in two separate worlds, but inside SOPs we needed some way to have both at the same time, so what we did is we decided to have them pass down as a pair of wires. Now, after we did that, and we colored the constraints basically pink, so you know how to wire them up, we realized there was also the question of collisions, so it got very ugly to have these colliders having to show up just finally downstream at the solver level, so we end up passing down the chain, and this lets you get access to them anywhere along the chain, if you want to attach the collider or do other things, but also just really cleans up the network, and ends up with a cleaner network than you'd have otherwise, so let us now actually try something with that, so I'm going to add a Vellum Attach. Rather than pinning these points to their position in space, I'm going to actually attach them to the flagpole, so let's first get rid of those pins, and let's make sure I successfully got rid of them. I'll display the cloth solver, and we can see, yeah, we got rid of the pins. They're free now. Now let's go and add a Vellum, so if I type in Vellum here, you're going to see a whole slew of nodes, and some of them are configure nodes, things like configure balloon, configure cloth, and configure grain, and configure hair, configure soft body. These set up the initial Vellum networks, and other ones are ones to add additional constraints to it, such as glue, attach to a geometry, struts, and weld, which is down here, and then some other, some pipeline nodes that we'll go into later, like Vellum I/O, pack, post-process, et cetera, so let's now look into what the Vellum Attach to Geometry does. If I take this and put it down in my network, we can see I've got three wires I need to wire up, so if I try and wire these up myself, I'm probably going to get very bored of applying all those wires all the time, so instead, what you can do is you can drop it in place, and if you drop it in place, you'll get all three wires wired up for you right away, which is a lot less work. Likewise, shaking it off is a very free way to undo it, and when it's on there, bypass will work and properly bypass the effect. One thing you have to be careful of, though, is that if you try and freeze this node, by using this lock button, it's actually going to pop up a warning that this actually won't do what you think it's going to do, namely, only the first output is actually frozen and saved to disk, and so the constraint geometry will continue to be cocked, so that is a limitation of this setup that we wish to address in the future, but for now I better let you know about it before you find out the hard way, so Vellum attach here is currently attaching all my points to the closest point on the primitive, so you're seeing a whole bunch of white lines here, seeing that every point is being attached. I can set a max distance, and if I increase this, we can slowly control how many points end up being attached, so this would be one way to say get every points within 0.12 attached, but likewise, I can tell it to work on a specific set of points, so I'm going to switch this geometry to points, and select only the points I actually want to have attached on the corner of the flag here, and so now I've got only strings attached on those very corners, and so this new Vellum Attach here, you note one interesting thing is this is the same node type as what we used to set up the cloth, so almost all of these Vellum tools are actually the same node. They're just basically different defaults for it. There's this global constraint type that you can use to switch between, and most of them have a very similar or orthogonal interface, but we tried to get best defaults by using different tab menus, and basically set you off in the right location, but sometimes it can be very nice when you need to realize, oh, I didn't want to use attachments, I wanted to use stitching, you can switch between them relatively easily. So the attachment also has a strength on it, and so this is a stiffness of basically how strong I want these wires to be that are holding it on, and so default is 1e10, which is basically infinitely stiff, so if I play this, we're going to see the nodes are being capped right on there, and you're also noticing it's because these are basically a bunch of straight wires, they also can't compress, and so they can't get any closer to the flagpole than this, which helps result in that weird behavior, but if these were like short pieces of string or something, then you'd expect them to be able to compress quite freely, because they'd just bend. You're just not drawing them, but you wanna be able to have that show up in the simulation. This is where the compression stiffness shows up, where we can specify different stiffness for these constraints shrinking than you do for them expanding, so I put that way down, and we're going to have something where now, all of a sudden, they can get close to the surface without being penalized for that. Another thing I can do is change the rest length scale down, and so this would basically change the initial distance to 0, causing them to immediately be snapped to the flagpole, so they basically have no give on how far they're allowed to be from the surface. Alternatively, I can just turn down the stiffness considerably, and then have something which actually can be pulled out, and as you can see here, I can barely pull it out against gravity, eventually reaches a sort of equilibrium. Got a very strange effect, because we've got these invisible wires. Wire removal has been done, obviously, on this effect. Now, I'd like to now look at this pipeline a little bit, because we tried to set up in this chain here, our idea of how to do a pipeline for this solve, so you have your actual solver node itself, and this is where you do all your configuration for your solver settings, your substeps, constraint iterations, and so forth, but after that, we have this Vellum I/O node, and this is part of a group of nodes we've had before. There's a DOP I/O, for example, which we've often used for pyro simulations and flip simulations, and this is performing a similar goal, namely it allows me to specify a file cache on disk, and save it out to the disk. I can point to this node with an HQ render node to put some down on the farm, to have something saved on the farm, but how it saves it to disk is by Packed Geometry and Constraints, and this is a, so it's gonna save a single file per frame, but that file's gonna consist of two packed primitives inside of it. One will have all my geometry in the gray input, and one will have all of my constraint information in the pink input, and this is important because the constraint information is not static. It's been updated by the solver, so as the thing gets stretched and so forth, all those stretches, and all that information's being stored on those constraints, and I save them to disk, then when I reload it from disk afterwards, I'll have access to all that information, which is invaluable, 'cause you want to investigate how this thing is behaving, and if you want to investigate it, you don't want to have to always do it live on your system. You really wanna be able to send stuff to the farm whenever possible, so this, then, brings up the final node, which is this post-process node, and the post process does some things like applying welds, and smoothing, and stuff like subdivision, because often cloth can get away with a nice round subdivision to make a nicer result, so we try to just put all this together. Likewise, extrude by thickness, so you can actually see the right thickness of the cloth, and get a polyextruded result, but of interest here is this visualize option, and in this I can do stuff like show the attach-to-geometry constraints, so you can see here now where those attachments are. Now, I don't have wire removal anymore, but I didn't need to use a post-process for this. This was also available up here on the cloth solver, so if I went to the cloth solver, and went to visualize tab, there is an option for attaching to geometry, so I can see it here without having done the post process. However, if I've run it on the farm, I don't have access to this. I only have access to the output of this node. That's what I have in the visualize options here as well. It's very important. The other big choice is this false color mode down here, and this is a way to throw a false-color visualization on the thing as a whole. In this case, I'm looking at the stretch stress, and I can control where the cutoff is for that, and this lets me see, over time, where the actual stress is going in the system, and how it's being dissipated by the solve process. This is particularly useful when you start doing effects, but it can also be used for when investigating why things are going wrong, or you're seeing some jitter or something, you can see where there's still stress in the system it's trying to solve. Likewise, the stretch distance, and this is showing how far things have stretched beyond their correct values, so the red areas here were not properly solved. This is supposed to be infinitely strong cloth, so it should be all blue if we let it solve forever, but we didn't, so we end up with these errors in the system, that we can see. Similarly, stretch ratio is kind of a nice one, because stretch distance depends on what your entire system is, so as finer topology, or distances get less, but that's just 'cause they're smaller, but ratio lets you know how much actual stretching is going on, so we're actually getting a fair bit of stretch on this cloth right now. If I turn this up, we can find the sort of cutoff point's around 15%. If I wanted to cut that stress down, there's two main ways of doing that. One is to constrain iterations, which gives more time for the solver to try and find out what the correct result is. Another is to do substeps. Now, if you take more substeps, there's less action that's happened for the solver to correct for, so it's better able to respond to it. My first suggestion is probably to always increase substeps if you're trying to go for more quality, probably to at least 5, and this will slow things down, but will allow you to then get a significant reduction in the resulting stretch stress. The other big thing to always look for, when one is setting up one of these cloth simulations is thickness, and this is because we have to pick some amount of thickness for the cloth, and unfortunately we have no idea what your scene scale is. Some people will have 1 Houdini unit to be a centimeter, some people a meter, and some people probably a kilometer, and so we can't really get very good defaults. It's a ongoing problem we're trying to solve, but in the meantime we've set our default thickness to, basically, 0.01, and this seems to be relatively good, but if I go to the post process, or to the cloth solver. Let's go to the cloth solver, and turn on visualization of thickness, we can see a bunch of green spheres here, and these are telling me how thick the solver currently thinks the cloth is, and it's very good to always take a look at this before you start your simulation, to make sure you haven't accidentally made them really huge or really unexpectedly small. If you make them too big, the cloth solver will run very slowly, because it will keep trying to think things are intersecting when they don't need to be. It can also start getting spikes and strange jitters, because things that are overlapped, that start to separate, it will try and push apart, and it'll get these impossible constraints to solve that make it very unhappy, but if it's too small, on the other hand, you can start getting more errors in the collision handling, because basically it has to be a lot more precise with trying to keep triangles apart. It's got no buffer room to sort of work with. It's always best to have a little bit of play for it, so if I increase our thickness, we can see what happens if I make it too thick, so I'm gonna go up here to the cloth constraints, and make these 0.4, 0.04 I mean, and now we can see that all these circles are overlapping, and if this was just run naively, this would actually explode, like in the old grain simulation they'd all start flying apart 'cause they were too close together on frame 1. However, what we do in Vellum is, the very first thing we do is we check for any overlaps, and we shrink all of the P scales so the initial geometry doesn't have an overlap, and this is very useful when you get really bad geometry given to you. I mean, this grid is beautiful. It's all equally spaced everywhere, but often you'll find, maybe around the collar some modeler decided to put a whole bunch of points adjacent to each other, and you haven't cleaned that up, but you don't want the solver just to blow up 'cause some points are beside each other, so instead we shrink those points to basically a 0 P scale, and that's what's used for the solve going forward, so here, this solve will work, and it's just it's gonna run slower than it needs to because it still has to use those original scales to see if the points have spread out to that distance, so you might get some artifacts from it, but at least you're able to get going and get a result sooner, but ideally this is meant to only apply to extraordinary points, not to every point in your geometry. If everything is turning cyan, like this, you should probably just reduce your P scale globally to a more sensible value, so that is a flag, and I thought I'd mention this is a continuation of our grains project, and one of the things we showed with the grains project, many, many years ago, was a searching demo, which a lot of people thought was very interesting, or very disturbing, I don't know which, but I'll try and recreate that now, but first I will quickly save this one so that we have a flag example to ship with you with this example file. Okay, so what I'm going to do now is try and recreate a example that we showed with Houdini 14, I believe, which was the pig with a whole bunch of pieces of bacon falling on top of it, so I'm gonna start off with the pig head here, and I'm gonna get some bacon, so I'll use the COP network, and can set this method to volume slice, so let's dive in here and do a File COP, and every copy of Houdini ships with bacon.jpg, so there we go, and now I need to trace this, so I wanna just get the outline of this image, so I'll use the Trace SOP, and the Trace SOP lets me point to a COP, so grab that COP path, and if I display this, we're probably going to find out there's very few points got, because it has a very small threshold, so let's find a good point to threshold it at, (grunts), likely around here, and this is pretty good for the main outline, but you notice there's all these little fligs, these little holes in here that are all yucky, and I wanna delete all those holes, and I'm a lazy person, so I wanna delete that automatically. I don't wanna select everything, so I'm going to use a measure SOP, and compute the area of every polygon here, and so if I go to the geometry spreadsheet, we're going to see we have this area, and if I sort it by area we can see we've got two giant polygons of like 0.15, and 0.15, and everything else is tiny and small, so I delete all the small ones, so I can do a blast, and what we can do in blast, when we say we delete by primitives, is for the group we can put an ad hoc group in, and so this is when you type something zero in, but you could also use the type a reference to an attribute, and so in this case I can refer to area, and say it must be greater than 0.1, @area>0.1 and this will delete everything that is large, so delete non-selected, and I'll delete everything that's small, so there we go, our pieces of bacon. Next, these have way too many points in it, so I'm just gonna resample them down a bit. Let me just choose a, oops, get that good length here, so it's high enough we see something interesting, but not too high. Might be a little bit too high. There we go, and now I want to turn this into a tetrahedr, I mean, not a tetrahedral, a triangular mesh for the Vellum solver, and we have some new tools called planar patch and planar patch from curves in Houdini 17, and planar patch from curves, in particular, is what I'm going to look at right now, because this takes a set of curves, and tries to turn it into a single 2D mesh, and so if I try this, we'll see it has successfully filled my mesh, but in this case I'm like, I don't wanna keep my original. Please resample the original. There we go, and now, the interior edge is 0.1, which is kind of too big, so I can cut that down a bit, and I'll have a slightly higher resolution pieces of cloth. Now, what I want to do is, of course, have these actually look like bacon, so let's use UV quick shade, and what I can do is I can go back to this original trace, right back here, and tell it to please add a point texture, and that way it'll store a point texture pointing to those original positions in space, and that way this UV quick shade can use that when I tell it to use bacon.jpg, and so this should now give me textured pieces of bacon. Unfortunately, or fortunately as the case may be, in Houdini 17 we default to showing the backsides of polygons with a blue tint, especially in SOPs. If I go up to the object level, you'll note that you don't see this effect, but if you're in the modeling level we do this, and this, I thought I wouldn't like this when it first came out, because I usually work with one-sided, I mean two-sided objects like this, but in fact, it actually proved quite useful, 'cause I could see when cloth was the wrong way around, and so forth, but if you don't like that effect, it's in the display options. There is an option in here to turn that off, so let's reorient this, because I'm not happy with the current location of it, so I'm going to template my pig, so I can see where it lives, and let's move this bacon to be on top of the pig, so it'll fall down to it, and it's kind of small. Let's make this a more impressive size bacon. There we go, and now we want to turn this into cloth and have it fall and collide with the pig. I'm gonna do this with Vellum configure cloth, and now I bring the pig into the extra input here, and then I can do Vellum solver, and now, if I hit play, we should see the bacon successfully fall on top of the pig. Yay. Probably needed to make it a bit stickier there, because bacon doesn't slide quite that frictionless along the surface, so on the solver options there's, under forces, the static threshold. Pushing this up to 10 usually makes things very sticky, so now we can have the bacon actually stick in place. Now, two pieces of bacon are interesting, but I kind of want a continuous stream of bacon, and this is where we can start getting into the difference between this Vellum solver and SOPs, and what we have in terms of Vellum solver in DOPs. So this SOP-based workflow, you notice the forces only has a couple of forces living here, and you might wanna do something different. You might wanna have wind that's animated over time, I mean, over space, I mean, time you can obviously animate here, additional forces and gravity, or you might wanna have more collision, static collision objects than just the ground plane, so if I dive in to the Vellum solver SOP, we can find ourselves in this internal network, and this internal network is a DOP network, so it's important to note this will only work with Houdini FX. This will not work in Houdini Core, but what I can do is add in here things like POP forces, and then apply new forces to my bacon, so if I apply a strong noise force, I can start the bacon twirling about, so let's make it really strong, so it's more obvious. There we go. It's actually being lifted up by the wind now, but this is not just with forces. This can also allow you to adjust constraints, so I can do stuff like the Vellum Constraint Property, and this lets me update constraint geometry, so I can do stuff like the rest length scale, which would be the length of all of them, and I'm gonna decide to let's grow up this bacon over time, so I'm gonna freeze on frame 1, and then on another frame, like over 19. Let's make this 1.3, and then this should slowly scale up the bacon and make it bigger over time, so it's now 30% bigger then it was when it went down. I can do a lot of neat effects that way, but I wanted to do now is try and have bacon emitted continuously over time, and this is something rather hard to do in this Vellum solver setup, because I don't have any way to inject new geometry every frame, so I'm going to delete all this. Instead, I'm gonna use the bacon as just a source, and bring the pig head in as a separate object, and so now I'll go to the Vellum cloth tool, and select the bacon, and I get a cloth, and then I'm also going to select this pig head to be a surface collider, so the surface collider, if you go to the collisions tab we have surface collider, and deforming object, and static object, which can be kind of confusing of which one you should use if you wanna get a collision with your DOP simulation. The static object, as the name suggests, is best when something is not changing or deforming at all, so it actually would work fine in this case. Deforming object is useful for flip and pyro. We have a deforming object, but you need to have the volume representation of it over time, and this sets up the code so you're able to cache out a VDB, and have that wired up properly to the active DOPs. In the case of Vellum, we don't care about the SDF representation. We only need the surface representation, and that's where this lightweight surface collider is useful, so this gives you deforming geometry, which doesn't have any VDBs set up for it, so I'm just gonna use a surface collider. Even though this is not deforming, it'll be just as fast, and set that up to the pig, and we'll now have the bacon fall on the pig if I set that up properly, and it's also important now to point out another difference between the DOP setup and the SOP setup. If you looked very carefully, you'd notice this bacon is falling faster than the bacon we had when we set it up in SOPs, and if I dive in, we can sort of see why: namely, that there's a gravity node here, because we tend to get a default gravity every time we do a DOP simulation, but there is no wind force. There's no default wind, and without that, basically it's going to fall slower, so I can put down a POP wind, or a POP drag, and then restore that behavior. Another thing to notice is that this Vellum source here has got a stream on it just like normal POPs do, so if I had those multiple physics example, and put the POP wind along one of the particular chains, that wind would only apply to that one object, not to all the objects, so in this case, I'm gonna only apply it to the pig head. I only have one pig, I mean, pig head. Did I rename that to pig head? Yes, I did, because of course I put down test geometry pig head, so this I very confusing right now, so I'm gonna rename this to bacon, and hopefully it's much more pedalogically accurate thing, so let's rename this to bacon. There we go, so now this wind will only apply to the bacon in question, and I'll match the default Vellum solver SOP, which uses an air resistance of 0.1, and so we'll now have a much closer behavior between the two, where it falls a little bit slower. Now, I want more than one piece of bacon, though, so what I can actually do with the Vellum source is there's an option here for emission type. The default is just to emit once whenever it gets activated, but I can also choose continuous emission, or to instance in a cloud of points, and so here I want continuous, and I don't want every frame, so I've gotta do some magic expression here to control when I want it to do, so I can do $SF%10==1, so this is taking the simulation frame, and every 10th simulation frame will basically emit a new piece of bacon, so we can see here we get a new piece of bacon every 10 frames, as predicted. Only trouble is these are all facing the exact same way, and of course I've got too much friction on it, so let's go here and increase the friction, and let's also twist the bacon over time, so the bacon is being sourced from here, so whatever status it has on the 10th frame is what is gonna be emitted, so I just need to put a animated transform, and I'll be able to then get a different result for each emission, so I'm gonna rotate it about, which axis is it? The y-axis, 360 times random of the current time, and now each time it emits it should get a random direction. You'll notice here there's a slight pause every time a new piece of bacon gets applied. This is because the constraint networks need to be resorted and re-isolated. We call this graph coloring, which is required before the GPU can solve it quickly, and we don't do this every frame. We only have to do it if there's a topology change. We do definitely see that little hiccup when you have a topology change, which is why, of course, we try and cache as much as possible, so thank you for sticking with me for this. I'll be having these files, of course, attached to this recording as well, and I hope you enjoy Vellum as much as we've enjoyed making it, so have fun, and I look forward to seeing what you create with this.
