Atom

I have used BVH files from both OSU and CMU. Also CG Speed has some of those same BVH file processed to various degrees. (Choose MotionBuilderSet) You can preview BVH files using BVHacker (free). Here is a basic workflow. 1.)Decide on a BVH file. 2.) Convert to .bclip file and companion .cmd file. EXAMPLE .bat file for Windows to convert a BVH to a .bclip and .cmd companion file set. (Adjust path to your Houdini\bin folder) "C:\Program Files\Side Effects Software\Houdini 15.5.480\bin\mcbiovision.exe" -n 2 "C:\Users\Mitzumi\Documents\Mocap\cmuconvert-daz-60-75\60\60_01.bvh" "C:\Program Files\Side Effects Software\Houdini 15.5.480\bin\mcbiovision.exe" -n 2 "C:\Users\Mitzumi\Documents\Mocap\cmuconvert-daz-60-75\60\60_02.bvh" "C:\Program Files\Side Effects Software\Houdini 15.5.480\bin\mcbiovision.exe" -n 2 "C:\Users\Mitzumi\Documents\Mocap\cmuconvert-daz-60-75\60\60_03.bvh" 3.) Run the resulting .cmd file inside Houdini to re construct the BVH skeleton as a Houdini FK based skeleton. File/Run Script... 4.) Dive into the chop network, that will be built by the .cmd file, and browse to the .bclip file which will finally cause the bones to move. The .bclip drives the associated bone network. Once you have an imported .BVH file, you can re-target it to another rig using the Goldfarb technique, here.

Signal 11 is generally a bad memory chip, or excessive overclocking. Try dropping your CPU multiplier down a half step, in the bios configuration section of the motherboard. With three GPUs in your system, make sure your power supply has enough watts to support that. Or take out all but one GPU and trouble shoot as usual. Can your system pass the Prime95 test?

No, that is a limitation of Redshift. What you can do, is turn the same object that has the emission matterial into a mesh light which will give you volume contribution and samples controls. This gives you a single colored light emission. You can go one step further, if your object has a material and UVs, and bake out the map on the object and the use that map to project multiple colors from the mesh light.

You could use a switch for that. Take the result of, i@my_result from the wrangle and use it to control the switch index. Then the wrangle will determine which set of nodes end up feeding the final display flag node.

Can't you just zero that axis' velocity, inside a popwrangle? v@v.y = 0;

Another approach might be to skin the line, by placing a circular mesh around it then reference the points of the mesh inside a Gas Wrangle on the velocity update of the pyro solver. This way you can create a custom drag that reduces velocity the farther from the central line, that the smoke travels. The cage is not a collision mechanism, it merely offers a reference @P for the smoke to compare against. ap_SmokeAlongCurve.hiplc You will probably need to dial in the distance values of the fit to achieve the best look. vector p1 = point(0, "P", 0); float dis = distance(p1, @P); //Change fit range and resulting values to dial it in. // Get half as fast, the farther out it travels. @vel *= fit(dis, 0.5, 1, 1, 0.5); NOTE: Because the wrangle has no input, the point fetched, from input #0 is actually defined under the Inputs tab (which points to the mesh cage SOP) of the wrangle, this is a little different than standard SOP manipulations of input 0.

Adding a Drag Force to the end of your pyro simulation and enabling and setting a low dissipation value under the Shape tab, helps keep the smoke on the line better.

For a more grid style scatter try a node recipe like this, using pointsfromvolume.

Locate the vellum solver and set the Constraint Iterations to something higher than the default of 100. Try 400-1000.

You could try the shelf tool Blend Constraint to bind the mocap skeleton to the rig skeleton. Goldfarb explains here. https://www.sidefx.com/forum/topic/55681/#post-250676

The @height works because the HDA uses a Bind to import that attribute. The other parameters can be overridden using the @parm_ prefix.

Thanks for the setup, Karl, that works. After taking a look at your VOP network I managed to reduce it to a single line of VEX code. v@P = set(@rest.x,@P.y, @P.z); So you could swap the constraint to any axis, by shuffling the values.

You could check out this example. http://www.tokeru.com/cgwiki/index.php?title=Houdini#Voronoi_cluster_and_fracture

42million seems a little low, for final quality, especially for up close camera work. Try getting your voxel count into the 65-165 million range. (physical memory is a factor, here) I use an estimator expression on my pyro object, just create a new blank float and paste the expression into the field. This expression reviews your box size and particle separation to generate the approximation value. Here is the expression I use. ch("sizex")/ch("divsize")*ch("sizey")/ch("divsize")*ch("sizez")/ch("divsize") NOTE: The result is in scientific notation. So when you see +06 on the end that means millions, +07 means 10 million and +08 means 100 million. The final value shown here 4.28345e+07 is ~42million voxels.

Have you checked if your current simulation is exceeding your physical ram? That typically will do it. Are you overclocking anything? That can do it. Has you system passed the Prime95 test? Are all your memory chips matched in spec? Chips from different vendors can vary. If your motherboard has dual memory channels, try turning off if you don't have matched memory chip pairs.