Skip to main content

Posts

More drawing with a wacom in Houdini

I have been improving the wacom python panel I posted about last time -- to try to solve the issues with the number of nodes I would end up with, also the file size of the .hip files were too large. In the last version, I was saving the curve data as a string on the SOP node, but this made for large files sizes. I was also using the parms on the SOP node to configure a bunch of things for the line (like the duplication, taper and width settings.) which caused me to have to create too many nodes when I wanted to vary the settings. I am now using the "geometry data" parm type on the SOP node to save the curve data. I am storing all of the configuration (duplication, tapering, width etc) in primitive data and have moved the settings to the python panel interface, rather than the SOP interface. This means that I don't have to create a new node to have different settings for a curve. I needed to add a selection tool, curve tool, and a freehand tool to the opython inter
Recent posts

Drawing with a wacom in Houdini

It's been ages since I posted last, I haven't been doing much Houdini at home in the last few years. I got an Indie licence to make some content for other things I am doing, so I will be doing more in Houdini now -- and whenever I find something that is a bit interesting or might be useful for someone I will try to post it. Recently I was looking for a solution for drawing curves with a wacom, and retain the pressure data  and curves so that it can be procedurally animated after it has been drawn. I was trying to find ways to recreate/trace consteallation drawings from the 1661 book Uranometria ( http://skytonight.org/Bayer-1661 ) The goal was to get clean curves that could be procedurally animated after they had been drawn, and also to get an image that is not obscured by the stars that you can see in the above snap. I was trying to use inkscape, which is great for drawing with but I had no idea how I could get any data out of it, and it seemed to make solid shapes in

Worm locomotion with FEM

I have always wanted to do a dynamic locomotion setup, I have tried in the past with wire and sop solver with .... interesting results ;) With FEM in Houdini 13, the rest attribute is stored on vertices which allows a tetra to change its rest state independently of the surrounding tetras. With this, parts can be expanded and shrunk to get a muscle type action. I have started with a worm since it is quite simple, the contractions and expansions move back along the worm in a wave, opposing the travel direction. It took quite a bit of tweaking to get him moving at all. One major element of a real worm's action that's missing is the little hairs that grip the ground. I couldn't find a way to change the friction per point so I have gone a bit hacky and multed down v wherever I didn't want the worm to move. I would love to hear if there is a per point friction control! Here is the video Houdini 13 FEM Worm locomotion from Sam Hancock on Vimeo . ...and the .hip is

Cloth tear geometry and shading detail

Been adding geo detail to the torn cloth and shading the additional geo. Shading sure is fun! :) Thickness added to the cloth geo Extrude sides are extruded out again  The second extrusion is done twice, once for the U direction, and once for the V direction. Polyframe is used to get the UV gradient to extrude along, vopsops are used to move the extrudeFront points after extrusion as you can't control the extrusion per point with just a polyExtrude node... The extrusion is done twice so that the two different surfaces represent the opposing thread directions. since my geometry (and therefore tears) are in line with the U and V direction, the effect is not obvious in this case. The extra geo after shading The .hip file below has a slightly newer shader than in the video and the image above, I removed the part of the shader that created the soft ramp for the alpha edge and used just the thread noise instead; it now looks more like: Slightly newer shader than

Some SOPs edges and poly line business

Every time I go to extract the border from a mesh I always end up using some strange combo of Group unshared edges, delete and dissolve, I came across a good way of getting unshared edges that I haven't thought of before, and now it seems really obvious ... using the polycap node to trace the border and then deleting all of the source prims, works like a charm! I have also usually had trouble with splitting up a line into multiple primitives, here is a way to create a primitive per edge. This example only works if every point has 2 neighbours but could easily be modified with a copy SOP to allow a dynamic amount of neighbours. (instead of 2 vopsops and a merge to duplicate the points). It works like this: The point number is stored in an attribute to create a unique number for each point The whole mesh goes into 2 streams to duplicate every point. For the first set of points, each point gets the point number of the first neighbour and applies a cantor func

Sop solver cloth tearing

Finally back to doing some Houdini at home! woo! I was going to do some cloth shading but got sidetracked and started playing around with some cloth tearing instead. I went back to H12.5 as 13 wasn't working for fracturing ... or I was missing something obvious! The idea is to cusp edges perpendicular to edges that are stretched beyond the threshold: For each point (currently A ), each neighbor is tested to see if it is stretched beyond its rest length. In the diagram edge B is stretched. The neighbors are looped through again to find edges that are most perpendicular the edge B (which is C and one of D and E ) . Those points are added to the "toCusp" Group. The group is promoted to and edge group and the edgeCusp break the edges. There are a bunch of other tests as well: If some neighbors have already been split, it will use a lower tear threshold so that tears tend to propagate. The average direction of the torn edges need to be perpendicular within a

Wire to RBD feedback in DOPs

Normally if a wire is constrained to an RBD, the rbd isn't affected by the wire at all. Which is annoying ... but I had an idea to get it to work. the wire solver can store the internal forces on the geometry. In DOPs I made a point force, the position is set to the position of the constraint and the force is the wire's internal (linear) force. I have put a sopnet in the dopnet to get the wire and the constrained point so I can reference them in the point force. It could be simpler with a python expression to get the position and force directly without going through the sopnet, but this is just a little test... For multiple attachment points, I think a copy data node could be used to copy the point force data for each constrained point ... hip file here Wire to RBD feedback forces from Sam Hancock on Vimeo .