Yuanfei Lei

Hi guys, I'm looking for how to achieve a wing shape vel like Mason's project on vimeo: https://vimeo.com/123026523. [vimeo.com] Would you mind to show me a clue? Thanks!

zachlewis
Off the top of my head, I know there's an FXPHD Destruction course - HOU205, I think - that does an excellent job with this kind of thing. I think it'll run you a hundred bucks or so, but I'd say it's worth it.

One way you could add those little debris rockets is to fracture some geometry in SOPs, art-direct their initial velocities (more on that in a sec), bring them in as fractured rbd objects (inheriting velocity from point attributes!), and then in a secondary sim (or the same sim, whatever you want), you can use the deforming debris geometry with the billowy smoke shelf tool… should work like a charm.

To art-direct those debris velocities, one way is to take your pre-fractured geometry, add an IsoOffset / Scatter SOP to get a nice random distribution of points throughout the volume, and plug the Scatter into the first input of a Point Wrangle SOP, and then additionally branch off an Edit SOP from your scatter SOP, plugging the Edit SOP output into the second input of that same Point Wrangle SOP.

The idea is to use the Edit to transform your scattered points in the direction you want your debris to go - eg, up and out a little - relative to where the initial static points are, in order to create an initial velocity for those points; and then we attribtransfer the point velocities over to the fractured geometry.

Because you have the same number of points going into both inputs of the Point Wrangle, you can subtract the position of @OpInput1's points from @OpInput2 (the edited points), and bind the output to velocity point attribute (if you're using an OpenGL, non-H11 viewport, there's a “Display Point Velocities” button on the right side of the viewport; otherwise, you'll have to press “D” on the viewport and set up a custom “v” attribute."

Anyway, your code for the Point Wrangle could look something like this:
@v = (point(@OpInput2,“P”,@ptnum) - point(@OpInput1,“P”,@ptnum));
@v *= 10;


Broken down:
- @ptnum refers to the current point number being iterated over, exactly like the $PT variable used in hscript expressions - the idea being, the Point Wrangle, just like VOPs in general, applies this same operation to all points in the input stream (unless otherwise limited to a specified group).
- Using the Point VEX function, you're looking up the “P” attribute of point number @ptnum from @OpInput2, the second input, and you're subtracting from that the “P” attribute of point number @ptnum from the first input.
- Since both point functions return a vector, it's a simple matter of vector subtraction - and you can bind this directly to the first input stream as the vector attribute “v.”
- Normally, if you want to create a new attribute, you need to cast the attribute as a certain type - vector, float, matrix, etc - while you're defining it. So, you could write “v@v = …” to create a vector attribute called “v” - but “v” happens to be a special-case pre-defined vector attribute (just like @ptnum is a pre-defined integer attribute), since SideFX predicted that these would be commonly-used attributes. See the Point Wrangle documentation for more information. Bottom line, we can use @v = … because it's intrinsically defined for us, but if we wanted to bind the output to an attribute named “foo,” we'd have to cast it as v@foo = … (because vector subtraction yields a vector output).
- I'm then scaling the entire operation by 10, which you'll have to season to taste, once you see how things behave in DOPs. The sexier thing to do would be to set up a spare float parameter on the Point Wrangle called, say, “scale,” and reference that in the code with “`ch(”scale“)`” - mind the backticks, which instruct the compiler to evaluate the expression first - and you'll get a nice slider to scale your velocities. Just set the default value to something other than zero. Or don't. It's your debris.


Right, so, coming out of this, you should have velocities assigned to the points you scattered over your pre-fractured geometry - and you can interactively direct these velocities with the Edit SOP (click on it in the node graph, press Enter in the viewport, and you'll have transform handles; and if you right-click on the selection tool in the viewport - the arrow - you can select “lasso selection”, which might be easier to use than the default “box selection”). This will become vital later on, when you're running your RBD sim and you want to fine-tune the direction each piece of debris launches off toward. That's the kind of control Houdini boasts over other packages.

But you're not quite done yet. Before you go into DOPs, you want to transfer the velocity point attribute “v” over to the original fractured geometry with an AttributeTransfer SOP. And *then* you should be good to go with the fractured RBD shelf tool. Again, make sure you select “Inherit Velocity from Point Velocity” in the RBD Fracture object.

In case you're wondering why we're going through the trouble of scattering over the pre-fractured geometry to set our point velocities, and then transferring the velocity attribute over to the fractured geometry, the reason is two-fold:
1) While we could have used placed the actual fractured geometry in primitive group selection mode to direct our initial velocities, even if we rotated the pieces, we still wouldn't get a whole lot of angular velocity, making for a duller simulation. Same goes for if we had just used the scatter node that serves to dictate the centroids of the voronoi fracture node - you'd only be getting a singular direction. By using a secondary scatter based on the original geometry, the scattered points naturally will *not* align perfectly to the fractured geo's topology, which means there's more room for variability for each point on each piece of fractured geo.
2) By divorcing the points used for setting up the velocity from the topology of the fractured geometry, you're free to change the number of fractured pieces generated by your voronoi fracture without being forced to go back and re-setup your velocities every time you make a change to how your fractures are set up; you're free to experiment with other fracturing techniques, or to do a lower-res sim for testing, or even reuse your directed velocities setup for large-piece and small-piece debris setups in the same sim… however you'd like.


I've included a little example. There are many things you could do to push it further - clustering, for instance, would help with the detail (you'll notice I disabled the “resize bounding box” entirely - playing with that would help too) - but this should get you started.

Very impressive! Thanks a lot!