Reading in an OBJ sequence in Maya.. w/o importing

This will be a quick little update. Everyone knows each 3D package has their strengths and weaknesses. Like Maya is super flexible but horrible with simulations, and Houdini is amazing with simulations but you can pretty much forget about UV's and keyframe character animation of anything more than 2 bones. So artists end up transferring assets from one package to another one. For instance, sending an obj sequence from Houdini to Maya can become a horrendous task. Houdini reads and writes files without saving them in its own memory or scene files which boosts its performance. In the mean while Maya needs each obj file to be absorbed into its memory and scene file which can easily bump the size of a scene to GBs. Here is a little 2 liner for you to make Maya read those obj files per frame and not absorb them:

string $frame = ( "/path/to/the/obj/sequence/" + `currentTime -query` + ".obj" ); file -loadReference "sphereRN" -type "OBJ" -options "mo=0" $frame;

This assumes that the name of the Reference is sphereRN and the obj sequence is not padded with zeroes. Below is a sample, you will have to open the expression editor, find the expression and edit the path to your extracted folder.


This is long over due.

Turns out this method will fail when used with batch render as pointed out by Jacob Niedzwiecki.

Simply put, root of the problem is that the currentTime function cannot query the frame number during a batch or command line render. When set by the expression editor to be evaluated always, currentTime looks at the GUI time slider for input.

Thanks to Jacob for pointing this error out :) and also for finding a very elegant and simple solution for it as well. What I had in mind for a fix was overly complicated.

What follows is his solution to the problem. But first a little explanation on why this solution actually works.

Maya allows for scripts to run before render jobs, before frames, after frames, and after render jobs. These can be set at the Render Globals window. Parameter names are Pre render MEL, Pre render frame MEL, and so on. These parameters are MEL scripts that are set to run at specified times during a render or a batch render or a command line render.

When the same script is set to be evaluated always by the expression editor and also as a Pre render frame MEL script, it will update both the viewport and the renderer with the correct file name for the frame.

So to iterate again, the solution is to copy and paste the exact same script to Pre render frame MEL parameter in the Render Globals window.

Camp fire

I was doing some flame tests with Houdini before I get some real footage with a mustang in the race track for the ghost rider project... so this is what I came up with, and I know the final comp doesn't look good because I just slapped the flame on top of the instanced lights render and uploaded it but all of them together takes quite long to render and all I had at the time was an old laptop.

Anyhow, the flame effect itself is very simple. First I used a small sphere to spawn the particles which are pushed up by a simple force node with some turbulence, and some noise. It also pushes the particles that get away from the central y axis of the origin by -$TX and -$TZ parameters. They were also colored in the POP level to provide colors for the instanced lights but I ended up using the second other, bigger flame sim for it.

After I was happy with POP I copied it to metaballs and then connected them to an isooffset node. Once calibrated isooffset can convert the POP simulation which is lightning fast and the metaball copy functions into pretty much what DOP simulations would come up with, only much faster. Once done and cached to disk, I attached the basic flame shader on the simulation, add a camera, and finally render with normal micropolygonal rendering.

After the first inner flame, I increased the volume of the particle source sphere, calibrated the forces to match, copied the POP over to the metaballs, added isooffset, and cached. Once its done added the same shader again and rendered from the same camera.

Two flames comped together.

Now its time to model some woods and a wavy surface to have some sublime shadows from the approx. 350 raytrace lights i will instance (painful).

For the surface I used the softbody simulation in POPs and collided it with some other objects, froze it and exported it as a single bgeo file. Then I imported the bgeo back and put some rectangular prisms with the wood shaders on top of it.

Now, the killer function here is the instancepoint(), it calculates per particle per frame so when I add it to the point light (which is the ONLY light node in the scene by the way) which was to be instanced, every instance of the point light got the color attribute of the exact particle it was instancing per frame. Per frame meaning that the color of the particles change over time and that is transfered to the instanced lights as well.

Before I started the render I had to decrease the number of particles, so re-spawned the second set of particles, only this time with less birth attributes. This one takes a lot to render 10 hours+ for 240 frames on a core2duo 2.4ghz machine.

Houdini crowd sim

I thought I posted this before, apparently I didn't.

It is a crowd sim driven entirely by Houdini POP networks. The run cycle was some mocap fbx I found online (model is mia from Motion Builder), but I had to edit it a little to fit in here.

Using the interact node in the POP network I made the particles avoid each other. Softlimit nodes to avoid the boxes. And a simple collusion node to slide on the surface of the grid.

Particles are divided in to five random groups each with different orders to avoid or follow another member of another group. They also have speed limits so they don't go off the grid.

I also added a proximity node that adds a nearest distance attribute to each particle which is basically the distance from the nearest particle. I am driving the colors of the particles with that, red is close, blue is far.

Now I am working on a way to transfer that color to the instanced geometry. I thought the point(../../xxx/,instancepoint(),"Cd",y) would pick up the color but it seems a little buggy. After the color modification is complete I'll add a feature that will change the speed of the run cycle to fit the actual speed of the particle, and maybe add a walk cycle in there if I can manage that too. Once the scene is complete, I'll clean up the *.hip file.

download crowdsim.hip

To be continued...

Flaming 2 seater

These are stills from the last shot I am working on. There is a particle system that spawns the sprites for the flame and a copy of it with much less particles that instance the point lights to light up the scene.

This is tricky because there is a bug in Houdini 9.5 that messes up the scene permanently if an environment light is added to the scene when there are instanced point lights present.

Sprites are procedural, and they get their colors from the POP color node. Same as the lights. To get the colors instanced to the point light I had to use an instancepoint() command on the point lights color node. ie: point("../flame_instance/switch1",instancepoint(),"Cd",0)

Smoke Ship Continued I

This is a different take on the smoke ship project. I dropped renderman, and particle systems to simplify the pipeline.

I brought the softbody simulation back in which was already cached on the disk before and hooked it up to an isooffset node under SOP level. Since isooffset doesn't require any DOP or POP simulation to work, it runs as fast as hard disk can read the cache files.

Some basic volume smoke shaders, depth map shadows, and HDR light does the trick.

The shot is still not where I want it to be, but some 2d compositing work can get it in the ballpark easily.