Skybar

So I'm not crazy then Thanks Thomas! That looks cool btw!

I haven't used vellum much and I'm trying to simulate a tree with curves - but I'm having trouble making the curves stiff. The solution seems to be to increase the Substeps and/or Constraint Iterations on the vellum solver, but doing that it gets quite slow very fast. In the test here I don't have that many points but it plays at just 10 fps. Comparing with the wire solver, where it's easy to get the stiffness without slowing down too much. In the test I get it stiffer than vellum and it still plays at 25 fps. Am I missing something or does anyone have any ideas? wirevellum.hip

It's pretty straight forward, like Dominik said: mattextopoint.hipnc

You can also enable "Override Crease Weight Attribute" and drag the slider

Try changing the Algorithm on the Subdivide SOP. Use the Houdini or Mantra one, not OpenSubdiv.

Yes you are right. Creating Clip A -> Clip B only allows it to go from A to B, but not B to A. So you need to set up Clip B -> Clip A too.

Create a sticky note. Right-click and "Set Text Size" and "Hide Background".

You could use the Trigger CHOP for this VexTriggeredAnimation_1.hipnc

If you look at the top it says: #include <xnoise.h> #include <interpolate.h> These are files on disk with additional functions, like the noise or 'fitTo01'. They're located in Houdini 18.0.287/houdini/ocl/include. I don't think you can sample other geometry with volumesample or point clouds with opencl, you have to specify everything you want to use in the kernel under the Bindings tab.

If you look at the transition graph, there is no connection between "idle_3" and "idle_to_walk" - so that transition is not possible. Thats why it doesnt work. To get the best results I would turn off "Compute Transition Graph" on the Agent Clip Transition Graph SOP, and set up all the transitions manually (clicking the + for Extra Transitions).

https://www.sidefx.com/forum/topic/53471/

Remove the lights from "Candidate Lights" on the OpenGL ROP.

For a square it's quite simple. Measure the perimeter and divide it by the number of edges (4) to get the length of each edge. Or measure the area and take the root of that. It's not as simple for a rectangle, there you could instead use Convert Line SOP. It will convert the edges to a line and give you the length in "restlength".

Add some lights. Just rendering with the headlight essentially removes all shadows and therefor all details.

1. The blast node is just grabbing a point attribute and blasting away all points that doesnt have that number. So if my point has choose = 1, it will keep the packed geo that has ptnum =1. The spare input is necessary when you need to reference another node in a compiled block. You cant reference other nodes through expressions like you normally would, but a spare input acts like another input to the node. So in this case I can fetch a point attribute from another node without breaking the compile. 2. Compiled blocks especially helps with foreach blocks, because on the last node of the foreach you can check the checkbox ”multithread when compiled” - which makes the whole thing multithreaded. Not all nodes are able to be compiled, and sometimes you have to do things like the spare input-thing. But especially for cases like this its blazing fast for copystamping stuff. Theres a masterclass for compiled blocks that explains it pretty good i think if you search for it! Sorry im on the phone but hopefully it makes sense!