I, 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...

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 i...

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...

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...

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...

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 ...

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 .

Here is a setup that does snapping wires... Wires are pre-cut and the cuts get constrained together, in DOPs a sop solver removes points from the constraint groups based on how much the edge length is stretched. The tricky part about this is that the groups have to correspond exactly so that the edges get constrained together properly... In SOPs before the sim, each line gets cut in two with a carve SOP. One side of each cut is put into a group, and the other side in another group. I use these groups in the constraint in DOPs to constrain the cuts together. Also, the points in side 1 of the cuts has a 'partnerPoint' attribute which stores the point number of the point on the other side of the cut. This is so that the groups can be rebuilt later. In DOPs there is a SOP solver to remove points from the groups. For one side of the cut, the edge length is compared to the rest edge length, if it is longer than a threshold the point is removed from the group. The second g...

In this one I have changed to adding up all of the impacts rather than the mixing that was going on with the attribute transfer in the last one. It is just a vopsop which loops through the impact points and adds up the deformation. One problem I was having was when I deformed the object, the centre of mass was in the wrong spot. I couldn't figure out a good way to modify that in DOPs... so i ended up moving it in the sop solver, to get it centred again. Another problem was that the object wouldn't be in contact with the ground after it was deformed, so it would end up in mid air with no velocity.. so I added a move attribute in the sop solver, then in DOPs I used a modify data node to move the rbds. The problem with this is that for one step of the sim it would be hanging out in mid air, and then snap to the ground. I ended up just adding the move to P in SOPs after the simulation.... not great because the object isn't solved at that position. At least it doesn't sn...

Simple setup that uses a SOP solver and deforms the geo at points of impact. The impact data is already available in the SOP solver, the normal is the impact direction and there is a pscale attribute for the magnitude of the impact. In this setup I just used attributeTransfer to get the impact data onto the mesh, then a vopsop to deform the mesh. There is a minimum impact so that resting objects don't get deformed. Also I divide the impact magnitude by the mass... the heavy box was denting itself from just resting there. Houdini - Impact deformation for RBDs from Sam Hancock on Vimeo . Might be better to have an additive effect for getting the impact data onto the mesh, rather than the averaging that goes on with the attribute transfer ... might try it later. Also going to try getting some volume preservation going on! .hip is here ! (H11)

More paper stuff! Updated it, now using a SOP solver to modify the velocity. The last one was a field force which wasn't great. Also this one projects the velocity vector onto the surface rather than just applying an opposing force like I was doing before. The velocity ends up perpendicular to the normal, with this: cross( nV, cross( nV, nN ) ). That is mixed with the original velocity to get more or less of the effect ... In the linked .hip file there is a VIS_PROJECTION null that you can view to see what I mean... Houdini - New cloth paper thingy! from Sam Hancock on Vimeo . You can get the hip file from here (H11)

Haven't posted in a long time, easing back into it with something I was playing with about a year ago ... it uses the same wind resistance stuff that I was using earlier. Going to update it in the next few days with a much better way of doing it with a SOP solver! Houdini - Cloth paper thingy from Sam Hancock on Vimeo . Each piece of cloth is simmed individually, a wedge ROP is used to write out a geo sequence for each piece and they are brought back in using a file SOP and a copy SOP. The pieces don't collide .. but it doesn't matter so much with these .....

Just another random thing. Houdini - Wire solver worms from Sam Hancock on Vimeo . This starts as some vertcal lines in SOPs that are animating upwards. The 'constraintoanimation' attribute is switched to 0 when the points go above the ground plane. This goes into the wire solver and thats about it .... hipnc is here.

I have a lot of half finished things floating around, here is one of them... Been seeing the dijkstra algorithm around a bit lately, so I had a go at implementing it in Houdini. http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm Most of it is in python. ~2000 points and it cooks in about 1.2s so it isn't super slow... Could probably be faster if I made it A* instead, but I have nothing to use it for so, meh! hipnc is here. you will need the otl here too

Just playing around with the wire solver and deforming wires onto wires... rendered as tube primitives, 2 area lights and an env light, took about an hour to render 2K :/ hipnc is here

Just messing about with the shader ... Did a few things like darkening the paint where it is worn, darkening the reflection, adding displacements to the steel etc. ......

Just playing around with shaders - curvature and occlusion in SOPs to make a wear shader. In SOPs, made a little curvature vopsop. It is a vopsop to do curvature since the curvature SOP doesn't give a normalised result. Inside the vopsop, the neighbors of a point are looped through and the dot product of the direction to a neighbor and N is averaged for all neighbors. I shamelessly copied the idea from Dan: And some occlusion in SOPs, done in SOPs so that it only needs to be done once for all frames This is mashed a bit to get the result I want: Mult the two together: This is to represent where the surface is likely to get worn or chipped. I started with the default reflective shader and added a displacement shader that gets the wear attribute, mults it with noise, then that goes through a contrast function to give a sharp edge. That 'matte' is exported to the surface shader to control a few things in there like reflections, colour etc. hipnc file i...

Was throwing together a wood shader and came across a happy accident :D

Fixed a few things with the particle motion blur stuff. Mostly it was just to get rid of an issue where you could see the particles when rendered zipping back to 0,0,0 when they died. I changed the popnet so that the particles always die when the camera shutter is closed... I think this was because the surface shader is only evaluated once, so when a particle died (alpha set to 0) the surface shader wasn't used again so the alpha wasn't updated from the sim... The only problem with the fix is that you can't have any particles that live for less than the shutter time... This is useful for sparks (you can see some particles colliding in the image above), I also made a little point cloud shader that is also useful for sparks :D Houdini - particle deformation blur and point cloud lighting from Sam Hancock on Vimeo . The shader on the spheres and ground plane just loop through the particles and does diffuse, attenuation and shadows. A single frame took about 6.5 ...

Was trying to find a clean solution to rendering particles with multi segment motion blur, found a way that is quite quick... A bunch of points are created at 0,0,0. The number of points is equal to the largest ID at the end of the particle sim. A VOP SOP loops through the particle sim and tries to find a particle with the same ID as the current point number. The position is copied onto the point, and a matchedPt attribute is created that stores the point number of the particle in the sim. This is so that the point() expression can be used later to copy attributes from the sim. The point count is constant so deformation blur will work with this setup. The alpha is set to hide the points when the particle dies and before it is born, with 1 frame buffer at either end of the particles life so that you don't see it streaking back to 0,0,0. That could be set to a 1 frame / oversamples buffer, I just haven't tried that yet... Oversampling of the popnet is 30 and geo time sa...