Solitude

Typically you wouldn't actually attempt to simulate the actual rebar -- you would use the existing constraint types AS rebar. You want to make it look like it's being held together by rebar by using a combo of friction - springs - conetwist - whatever... then add rebar geometry in later, as a visual, by just attaching it to the rbds. Getting the geometry clean enough to be all convex hulls would be incredibly hard to do automatically, and likley very slow with some kind of convex decomposition tool. Also, simming as concave geo is likely to be extremely slow and unstable.

Try putting a material on both the inside and outside, as well as a normals sop on both.

I recently did a shot where I simmed the high res geo as convex hulls for one part, which was fine, but then for another I simmed with voronoi pieces, and then used a very high res boolean mesh attached to the nearest voronoi piece post sim (both done as packed prims). It saved a lot of time and hassle worrying about small pieces or oddly shaped ones that would explode. It was also faster to recut the voronoi when I needed to adjust where something was breaking than it was to re cut the mesh too. I basically over-did the boolean part of it so I never had to worry about having enough detail, and not having any overlapping shapes in the sim helped.

"We implemented our lighting grid hierarchy inside the SideFX Houdini software using its VEX language. All explosion images are generated with the SideFX Mantra renderer using its ray tracer for the volume data". ...wonder if they will ever release the implementation.

Jeff mentions it in that thread posted above, and he talked about it on the beta forums. Otherwise this is the only real mention I know of: http://www.sidefx.com/docs/houdini16.0/news/16/dynamics "Built-in Intel OpenCL driver with CPU fallback for simulation on the farm."

Houdini 16 comes with the Intel opencl driver now.

There's supposed to be an intel opencl fallback for machines that don't have gpus. I thought it would be automatic, but try HOUDINI_OCL_DEVICETYPE=CPU as an environment variable on the farm machines and see if that fixes it. Side note though, you should probably have your stuff baked to disk if it's going to the farm, unless you're simming out the erosion and such which use opencl.

Hey guys, I just wanted to share my point cloud based texture bombing shader with you guys. It's a vex shader (for mantra) that uses a pointcloud to drive texture bombing (stamping/projecting) onto an object. It allows you to seamlessly blend images over any 3d surface with no uv seams pretty quickly and easily, after which you can bake it for use with other render engines or a game engine. I've made it free for indie use (the otls were made with indie) on my site here: http://fx-td.com/?page_id=544 Detailed description, quick start guide, and example images are on the page linked. I do hope to make the time to record a video for it soon after h16 comes out (still need to test it in 16, but I don't anticipate any issues). Hope you find it useful!

Do you have any collision objects in your whitewater sim dopnet?

LOL I'm pretty sure everybody has been asking for it back (the plastic deformation) ever since they took it out in 13 (?) or was it 12.5..?

I had recently sliced up a sim into 4 parts -- on a single machine it was 24 gigs or so, on the 4 machines it was about 12 gigs each. I only had a single collision volume and a single source. Do you have anything extra complex going on?

Try that menu (hit D in the viewport) but go to Effects -> Transparency. Make sure it's enabled.

Clustered sims (a type of distributed simulation) are for when you do want the sims to run independently on a renderfarm and not look at each other. You need a script to iterate an env variable that changes something in your scene. This would switch the cluster the computer runs -- you could save out a hip file for each one of these, or the scripts should tell the farm to set a certain env variable. With pyro is usually means switching a bounding box, source, and cache file based on that env variable. I realize I am over-explaining in this next part, but figure it may be helpful for somebody else. Distritubed sims are a bit different in that they do rely on each other for information, effectively simming one big sim over multiple machines. This requires slices to be set up where there is a tiny bit of overlap a so the grids and particles can transfer data to each other. Same thing goes here you need to set env variable on the farm machine so they know what slice they should be running. A sim tracker job has to be run as well and keeps tabs on the status of each of the sim jobs as they run so they know when to fetch data from the neighboring grids. Each grid has to wait for the other grids before it can start it's next frame though. Keep in mind it may be faster to sim on one big machine than over 4 slower ones... it depends on the network overhead. It is going to be as slow as the slowest machine you sim on too. Speed is not linear as you increase machines either. I recently tested, and got some big sims (70million, and 135 million) done on 4 machines. They simmed about twice as fast as the same sim on a single machine. Ram use on each slice was about 1/2 vs the single sim too, so if you have a big sim that can't fit on your machines, distributing will help with that. There is a masterclass on this that's pretty recent... he even shows how to set up an arbitrary particle sim for distribution at the end.

Just out of habit and preference I suppose. The latest one has a lot of nice filtering and masking options. Some people like to just create it themselves or need something specific. It's pretty good now though. If you use the shelf setup you'll see that it uses particle separation for voxel size (ch reference to the flip object)

If you're in houdini 15.5 unlock the particlefluidsurface node and go inside. You'll see that it's actually using vdbfromparticlefluid and vdbfromparticles as well as many other vdb nodes.