Atom

That's interesting. I was poking around inside of pdb_constraint.h today to try and find out why OpenCL has all of a sudden quit working on the GPU. I got a message that about variables not being defined as double precision. I wonder if some type of compile switch has been janked on these recent Houdini builds? (using H18.5.532)

Under Edit/Preferences/Miscellaneous, try switching from GPU to CPU for OpenCL. I have the same problem, even older vellum projects no longer work. My guess is video driver updates have altered the way Houdini perceives my GPU hardware.

Try promoting the Cd attribute from point or primitive to vertex and export again. Also kick out an alembic from Cinema4D and import it into Houdini. Try sending attributes the other way to see what is expected..?

As mentioned in the master class, changing the bullet substeps from 10 to a larger number does not necessarily produces better results. Your "things" should not fall through the ground even at the default settings. Review your collision meshes first.

Also, if you are just instancing spheres, try leveraging Redshifts render as particles instead. No geometry needed. I don't think Redshift uses a special attribute. I always used @instance and that seemed to work. If you do have a .rs file (which is recommended) then use @instancefile to target it on the disk, but don't specify both attributes. Here some code from one of my instancers. string subnet = chs("../subnet_source"); // Numbered variants inside subnet. int max = chi("../item_max"); // Variant count. float rnd_seed = ch("../rnd_seed"); // Select random item int item_num = int(fit01(rand(@ptnum+rnd_seed),1,max)); s@instance =sprintf("%s%02d",subnet,item_num); // Apply random rotations float randRot_Y = fit01(rand(@ptnum + rnd_seed+3),0,360); @orient = quaternion(maketransform(@N,@up)); vector4 rotate_Y = quaternion(radians(randRot_Y),{0,1,0}); @orient = qmultiply(@orient, rotate_Y); // Apply random size f@pscale = fit01(rand(@ptnum+rnd_seed+10),0.75,3.0)*ch("../size_mult");

I'm not aware of any drawback for increasing the TDR delay, so you might as well give it a try. What do the logs say? Are you sure it is your graphics card? One simple test is to leave the Materials icon for the 3D viewport OFF (save as viewport default D-KEY). This will prevent additional features from being applied, features your card might not have. Maybe force a chkdsk on the drive where you have installed Houdini?

You'd think a light would be unified by now, but it's not. So you have two brightness controls on the same Redshift light. Contribution scale is like intensity for polygons, only contribution scale is used to illuminate volumes.

On the FLIPSolver, under Volume Motion, sub tab Collision, try reducing the Velocity scale down to 0.1. Also lower the magnitude of any supplied velocity.

Here is a basic chops driven sample hold. For redshift light instances, you can control the brightness by supplying an additional attribute along with the s@instance. //s@instance = "/ob/rslight_spot_SOURCE"; v@light_color = set (rand(@ptnum),rand(@ptnum+801),rand(@ptnum-311)); ap_chop_hold_lag_drives_light.hiplc ap_rs_colored_instance_light_circle.hiplc

I think you can extend it like this... ($F>30) && ($F<40)

Here is the resulting HIP using the import settings I posted with Houdini 18.5.408. FBX standard importing directly into the /obj network, not a subnet. The only change I made after import was to the Icon Scale of the camera. ap_camera_import_problem.hiplc

These import settings seem to work for me.

Select a node and right-click on the bottom or top connector. Choose a node from the list and press enter. This will "auto-wire" the new node to the selected input. Another auto-wire feature to select a node, choose a new one from the list using SHIFT-ENTER. This will auto connect the new node. You could create a hot-key mapping to a custom shelf tool that will "auto-wire" a selection. The hard part is knowing which nodes to connect first? Is selection set order determined by mouse box lasso? (top to bottom or bottom to top?)

Thanks for the replies, everyone. I also received help on Discord which provided the simplest solution. Calculate the collision object using Ray Intersect instead of providing a Volume Sample. For some reason this just fixes it..?

I have a working viscosity simulation. When I replace the tube with a hollow cube, all fluid motion stops on contact with the collision surface? I have set friction to zero, but that does not seem to be the issue. The collision object looks valid. Does anyone know how to make FLIP work in this case? I expected the fluid to continue to ooze out and around the collision object. How are we supposed to make our Cadbury egg simulation? ap_flip_viscosity_by_attribute_inside.hiplc