Time Driver SOP

I have recently uploaded a useful digital asset to the Houdini Exchange. It is the Time Driver SOP. It is a useful node that lets you re-time animations, particle animations, particle fluid sims, etc. to your liking. It uses a combination of the Warp CHOP, Time Blend SOP, and the Time Shift SOP.

The Time Curve parameter is the time ratio that the animation will run. So a value of 1 is normal, 0.5 is half speed, and 2 is twice the speed, etc. You can keyframe this value as well, so you can have a fluid sim that slows down abruptly at a specific frame or gradually changes speed. Negative values will run it in reverse.

Example of the time curve. The animation will go in slow-motion
at frame 50 and then return to normal at frame 100.

You can also use a .clip or .bclip file you have exported from CHOPs or another software. Just check on the toggle.

Warning: If you merge two or more particle systems before using this node, the particles will not act as expected because the particles have overlapping IDs. So only use one particle system at a time.

It is also recommended to use .bgeo file sequences to be safe.

I used this node alot in production and it saved me loads of time in that I didn't have to try to match the timing of particles in the simulation. Instead, I just used the animations with no time warps, exported the time curve as a .clip file and used the node at the end. I was also able to tweak the timing of any particles or simulations in a flash!

You can find it in the Side Effects website's Houdini Exchange or just click Here!

Hope you find it useful.

Grassy Grass

A grass simulation using fur. The movement is driven by animating the point normals on the surface using a Perlin noise offset. The color is changed by attribute transfer of point color from a single point in the center. No dynamics were used, only SOPs.

The style of the grass was inspired by a Playstation 3 game called Flower.

Pinball Machine

Another combination of DOPs and CHOPs.

By using the Impact data that's created in a dynamics network when two objects collide, I created a graph in CHOPs that drives the size and color of the bumpers.

In the details view in DOPs, when two objects are colliding with each other, an Impact record will appear on each object involved. It will only appear on the frame where they touch, and will disappear until they interact again.

If you look at one object's Impact record, you can see object ID of the other object involved, the simulation time at which it took place, etc. The main piece of data I used in CHOPs from the record was the flags data, which is just "flagging" that the data exists and is set to a value of zero.

After bringing the raw Impact flags to CHOPs using a Dynamics CHOP, I needed to make some math adjustments and then record the graph.

Then I added a Spring CHOP to it and exported it to the bumpers' scale, ....

and in another branch use a Lag CHOP and bring it to the bumpers' color.


RBD vs ODE
I later converted all of the objects in the simulation into ODE objects for more accurate results. I then realized that when using the ODE solver, you cannot create Impact data. So later I only used the ODE solver for the pinballs and used the original RBD solver for the bumpers. So now the bumpers were able to receive Impacts.

Houdini Tetris

SOP Level

I started with a 4x2 grid, and deleting primitives to create the tetrominos in the game. Each tetromino consists of 4 primitives.

All of these geometries went to a Switch SOP. The input parameter has an expression that randomizes the input by time. The flat shapes are later extruded. This will be the source of the RBD objects in the DOP level.

DOP Level

RBD Object DOP

When bringing them into DOPs, a tetris piece needs to be "emitted" not only on the first frame, but also when the piece before it hits the ground. This is done by the expression in the Creation Frame parameter:

if($FF==1 || dophasfield("..",$OS+$SNOBJ-1,Impacts,Impacts,0,flags)==1,$F,0)

In DOPs, when an RBD object makes contact with a collision surface, there will exist Impact data called "flags". So once the current object, $SNOBJ-1, receives this flag, a new piece will be created.

Group DOP

I created two groups, one called "falling" which is the current piece, and "hit" which are the pieces at rest. The groups are detected by the Y velocity.

RBD State DOP

An RBD State DOP was used to force the velocity data to zero of the "hit" group. This will keep the pieces from bouncing and moving dynamically.

Motion DOP

In a Motion DOP, position was overridden using CHOPs. I could control the position of the falling piece using the keyboard or a game controller via CHOPs while the simulation was running.

CHOP Network

The CHOP Network records a graph while DOPs is running and can directly move the pieces in realtime. The result of the network above plugs directly into the Z position of the Motion DOP.

Resulting curve for side to side motion.

DOP Network

Afterthoughts

This was an experimental project and I learned alot about DOPs and CHOPs. I may later come back to this one to try and figure out how I can rotate the pieces without any bugs and of course enable the blocks to disappear after creating a line.

Wii Controller in Houdini

For this group project, we are planning on using Nintendo's "Wiimote" as an input device to use inside Houdini. Utilizing CHOPs, we plan on controlling geometries inside the viewport in dynamic or game simulations. Later, we want to capture and record these movements and render them out in a sequence.

List of our Materials

* A PC with Windows XP
* A Wiimote
* Kensington Bluetooth USB Adapter 2.0
* Infared Sensor Bar


Get the Bluetooth Driver

Before even thinking about Houdini, we need to get the Wiimote working on the PC. Depending on the bluetooth dongle you must use specific drivers for this thing to work. Since we are using the Kensington USB 2.0 Adapter, we must use the driver below. So before installing the drivers that are packed in with the dongle, make sure to check which driver you need to use for the Wiimote HERE.

Download the Driver Here: KensingtonBTW_4.0.1.2400.zip

Connect the Wiimote to the PC

After installing the compatible device drivers, do the following:

* Double-click the Bluetooth tray icon.
* Tell it to search for bluetooth devices
* Press and Hold the 1 and 2 buttons on the Wiimote
* It finds the Nintendo Wii Remote (Nintendo RVL-CNT-01)
* Click on the icon labeled "Nintendo RVL-CNT-01" to select it and then clicked "Next"
* Click the button labeled "Skip Pairing"
* "Use a Bluetooth enabled mouse, keyboard, or other interface device" with a "checked" checkbox
* Click Finish


Testing it Out!

After all that, I found a neat little program called WiinRemote on http://onakasuita.org/wii/. It is a Wiimote Driver that basically lets you use the Wiimote as an input device. You can map any keyboard and mouse buttons onto the Wiimote buttons and motions. You can even set up the Nunchuck attachment and use the analog as the cursor and utilize its Z and C buttons! So this is the key. Now that we have got it working on the PC, we can bring it in Houdini!

Download WiinRemote Here: WiinRemote_v2007.1.13.zip


Choosing a WiiMote Software

There are many other software packages that are capable of driving the WiiMote, so search
around or follow the links below, don't limit yourself to this one.

The two main software packages that we used were WiinRemote and GlovePIE:

Advantages of WiinRemote:
-User friendly.
-Good GUI.
-Graphed results.
-Easy to use button configuration.
-Tilt/Roll support for mouse control.
-ZERO coding involved.

Disadvantages of WiinRemote:
-Less control over output options.
-No widescreen/dual-monitor support.

Advantages of GlovePIE:
-Fully programmable.
-Ability to use scripts.
-Visible output variables.
-Configurable output value ranges.
-Widescreen support.
-Everybody likes Pie, and most people like gloves.

Disadvantages of GlovePIE:
-Terrible GUI
-Lackluster documentation
-No Graph representation (tough to
troubleshoot)
-Difficulty connecting to mouse

We ended up using WiinRemote for its easy interface and user friendliness. Now, with WiinRemote running in the background, we launch Houdini 8!


Porting to Houdini

Our basic structure is as follows. We chose to port through the Mouse CHOP, due to our limited knowledge of MIDI's and their outputs. First set the driver to control your cursor. Either pointer if you have an IR sensor, or set it to tilt and roll for axis control. Use a Mouse CHOP in the motion and audio tab. In its parameters Set Activate to While Playing.

In order to deal with the screen edges, make a Math CHOP, and multiply your input variables by your own preferences.

Connect to a Record CHOP, to capture your movements in real time. Finally, connect the Record CHOP to an Export CHOP. In the Export node you can take the X and Y coordinates to any Node variables you wish from SOPs, POPs, DOPs, etc. (Such as transformation, rotation, etc.)


Post-Mortem

In hindsight, the WiiMote was nothing more than a gimmick. We originally thought that due to its ingenuity and unique control scheme it could help revoloutionize how we interact with a three dimensional environments. Due to the current functionalty of the drivers offered for the WiiMote, it has little more functionality than a custom Mouse/Keyboard. Also due to limitations of the drivers it will only accept one keypress at a time, and does not register multiple buttons correctly on the actual remote (nunchuck/power button).

Originally we wanted to use the WiiMote in the DOPS network to control environment/object variables. Houdini however was not designed with real time dynamics simulation in mind with live inputs, and we ran into technical snags at every turn. For example. We used the WiiMote to control a plane's tilt and roll values with a ball dropped on said surface and a gravity force applied. The simulation looked as if it were working correctly until we discovered that if you changed the angle of the plane too violently the sphere would be instantly forced through said surface and we were unable to find a solution. Instead we cheated and used a particle network to recreate a simple ball maze.

Our next attempt was to use the WiiMote as a custom Interface device. We were able to map scripts and keypresses to the existing WiiMote buttons. It worked swimmingly until we tried to pan zoom or Rotate, where we discovered that multiple keypresses were not supported by the drivers we were using. Making complex interactions in Houdini nearly impossible for our purposes.


Conclusion

In conclusion, our WiiMote project was informitave but due to our limited time frame and knowledge of computer peripherals we were unable to create adequate work arounds that would make the WiiMote more usefull or innovative than the standard mouse and keyboard. Perhaps under future builds of drivers the WiiMotes usefulness in 3d environments may be much more substantial. With more knowledge, and understanding of the drivers, we could make "The Tool" for 3d scene navigation and interaction.


+ Links
WiiLi.org
List of Compatible Bluetooth Devices
WiinRemote
YouTube Video - WiiHoudinii (our inspiration)