I, Houdini

Wire to RBD feedback in DOPs

2011-10-29T16:07:00.000-07:00

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 uses to copy the point force data for each constrained point ...

hip file here

Wire to RBD feedback forces from Sam Hancock on Vimeo.

Snapping Wires

2011-10-29T04:15:00.000-07:00

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 group is rebuilt using the first (now modified) group and the partnerPoint attribute.

The hipnc file is here

Snapping wires from Sam Hancock on Vimeo.

Deforming RBDs again!

2011-07-16T02:22:00.000-07:00

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 snap into position... To make this less obvious I have done a few substeps on the dopnet.

Also added some displacements to add detail to the deformation. I had no idea how to do that for a while but I found a way which is pretty good. In the sop solver i have recorded the impact direction and impact amount, this gets accumulated. After the simulation I also added a compression attribute by comparing the rest edge length to the current edge length. In the shader I am getting P for the noise by doing ( rest + (impactDir * impactAmount)) so the noise compresses radially around the impact point, this is multed by the compression attribute. This worked better than I expected!

anyway, here is the video:

and the .hip file is here!

Deforming RBDs

2011-07-09T07:30:00.000-07:00

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)

New paper sim

2011-06-11T05:28:00.000-07:00

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)

More old cloth wind resistance stuff.

2011-06-09T07:37:00.000-07:00

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

Wormie wire solver things.

2010-02-06T17:58:00.000-08:00

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.

Dijkstra pathfinding with python.

2010-02-05T02:59:00.000-08:00

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

Wire solver and wire deformer.

2009-09-05T05:55:00.001-07:00

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

Wear Shader #2

2009-08-26T04:20:00.000-07:00

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

Wear Shader

2009-08-25T03:20:00.000-07:00

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 is here

took about 16 minutes to render that 720P frame (just a HDRI and PBR).

Here it is with the contrast centre animated in the shader:

Random #1

2009-08-24T06:37:00.000-07:00

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

Particle motion blur again and some point cloud lighting

2009-08-16T06:45:00.000-07:00

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 minutes to render on my laptop ( Core 2 Duo 2.5GHz ) compared to about 1.5 hours for the equivalent PBR render.

hipnc is here.

Multi segement motion blur with particles

2009-08-04T09:03:00.000-07:00

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 samples is 5 for the render. I wish popnets would interpolate between oversamples .... cache node might do it but I don't think so...

hipnc is here - created with build 10.0.346

Growth and L-Systems

2009-06-16T07:05:00.000-07:00

Have been reading about l-systems, mostly papers from here. Trying to get segment growth working as described in the growth functions section (1.9) of The Algorithmic Beauty of Plants. I don't understand a lot of it but I think I got the basic idea :D. It was really confusing after a certain point when reading about l-systems, they started making a lot more sense when I actually started trying to implement stuff!

The important part is that F is getting rewritten. The g parameter is incremented each time to act as an age attribute, so g is the linear growth, and then length is set by using g in a funky smooth step type function thingy ((-2*g^3)+(3*g^2)) to get a kinda sigmoidal growth.

The b variable is used to control the speed of the growth.

The rest is just for controlling the branching so that the l-system came to some kind of end state. Like the m parameter in A(m) which decays over generations so that it stops getting replaced eventually.

The generation parameter is just set to $F so that every frame is another full generation.

This is the same l-system without rewriting F:

hipnc is here.

Cloth self shadowing

2009-06-01T06:00:00.000-07:00

This is why Houdini is awesome, one node ignored and changed the bias on the ray SOP, and self shadowing just works :D

It probably needs a wind location specified so I can timeshift the occluding objects depending on the distance from the wind 'emitter'. meh.

hipnc is here

Cloth wind shadowing

2009-05-31T07:17:00.000-07:00

More cloth!

Got some wind shadowing working using the same technique as the wind resistance thing, just with a ray SOP to block the wind.

Currently the wind gets blocked by any other objects in the dopnet. Might add self shadowing next!

This is with wind resistance from earlier, just adds some damping.

hipnc is here.

Cloth and wind resistance

2009-05-29T20:36:00.000-07:00

Normally a cloth like this:

would just fall and retain this exact shape... I put together a little force using the field force DOP and a little sopnet to get a basic simulation of wind resistance as it falls.

The force is applied along the normal, opposing the velocity. It is also scaled by velocity.

Here is an example:

Blue is the point normal, green is the velocity and red is the force to be applied.

This is far from correct but it works alright in practice.

This cloth is 2m x 1m and low density (less than a kg total I think)

hipnc file is here!

PBR fun

2009-05-28T09:07:00.000-07:00

Just playing around with PBR, also was reading about linear colour space so I was also experimenting with doing a sRGB > linear coversion to the textures -- before .rat creation as the mipping is wrong in sRGB. A 2.2 gamma is applied when viewing the render in mplay and also applied when saving a .jpg. I understand it all a little bit better now, that workflow seems to work alright.

Just used the Galileo's Tomb HDRI from http://www.debevec.org/ with no other lights.

hipnc file is here

Growing Objects

2009-05-26T03:00:00.000-07:00

I saw this post over at odforce and have been playing with growing objects in a dynamic way ...

It is basically just points scattered in the volume of an object, then a SOP solver is used to increase a points pscale if it is colliding with another point. Metaballs are copied onto the points, converted to polys, then cookied with the original geo (not in the video above though...)

This is the source geo and with the scattered points:

Some attributes are added for the sim:

The pscale attribute is set to 0 except for one which is set to maxSize to start the sim going. Roughness starts at 1 and decays when a point has stopped growing, this later is fed into the shader to increase the cone angle on the reflections and refractions...

These points get loaded into a DOP network and then into this SOP solver:

The pointCloudSop is a little VEX script that tests for collisions between points:

#pragma hint filename oppath
#pragma hint pscale hidden
#pragma hint maxSize hidden
sop
pointCloudSop(string filename="/obj/geo1/PC";
float pscale = 1;
float radius = 1;
float maxSize = 1;)
{
if ( pscale <>
{
string file = concat("op:", filename);

float isColliding = 0;

int numpoints = npoints(0)+10;

int pointcloud = pcopen(file, "P", P, radius, numpoints);

while(pciterate(pointcloud))
{
float dist;
float otherPscale;

pcimport(pointcloud, "point.distance", dist);
pcimport(pointcloud, "pscale", otherPscale);

if ((pscale + otherPscale) > dist) isColliding += 1;

}

addattribute("isColliding",isColliding);
}

}

vopsop1 adds growRate to pscale if it is colliding, vopsop2 just maintains roughness if the point is growing and decays it otherwise.

After that, the rest of the SOP network just copies metaballs onto the points. I was using the cookie SOP to get the intersection between the original mesh and the metaballs but the cookie sop was a bit unreliable :/

hipnc file is here