johner

You shouldn't need to create any of the constraint primitive attributes outside of the ones created by a VellumConstraints SOP, which are all either internal to the solver, or output attributes (like stress). The VellumSolver detects changes to the constraint geometry topology (i.e. when new constraint are added), and performs a series of operations to update the constraints, including creating those attributes. There's an example of creating custom constraint primitives here, which shows the attributes you generally would need to create: https://vimeo.com/340544320#t=2h8m30s

Yes, you want the Vellum Rest Blend DOP, which you can point at an external SOP that animates your rest geometry. It will update the rest state of a specific set of constraints based on the input Rest geometry. With 17.5 there is a help example for Vellum Rest Blend SOP that shows some uses of it. Attached is an example of lengthening hair curves over time. Note the rest topology has to match the original geometry, i.e. you can't add points, but you can transform them in various ways. grow_hair.hip

Yes, Houdini 16 ships with a built-in Intel OpenCL CPU driver on Linux and Windows, and should fall back to in on any machine where a GPU is not present (e.g. a render farm machine). We have seen a few cases where library conflicts prevent it from loading, but you should see "Unable to load HFS OpenCL driver" if that's the case. Usually you can do: $ hgpuinfo -l [*HFS OpenCL Platform*] Intel(R) OpenCL Platform Vendor Intel(R) Corporation Platform Version OpenCL 1.2 LINUX OpenCL Device Intel(R) Xeon(R) CPU X5650 @ 2.67GHz OpenCL Type CPU Device Version OpenCL 1.2 (Build 57) Frequency 2670 MHz Compute Units 24 Device Address Bits 64 Global Memory 24102 MB Max Allocation 6025 MB Global Cache 256 KB Max Constant Args 480 Max Constant Size 128 KB Local Mem Size 32 KB 2D Image Support 16384x16384 3D Image Support 2048x2048x2048 ..... That HFS driver should always be first, so that if you do HOUDINI_OCL_DEVICETYPE=CPU it will be the device chosen. Also: $ hconfig -h HOUDINI_USE_HFS_OCL HOUDINI_USE_HFS_OCL Set to its default value of 1, this variable tells Houdini to load the built-in CPU OpenCL driver that is shipped in $HFS (64-bit Windows and Linux only). This built-in CPU device can be selected using the regular OpenCL device specifications, e.g. HOUDINI_OCL_DEVICETYPE=CPU. Houdini will also fall back to using this driver if the usual OpenCL device selection process fails, making it safer to submit OpenCL jobs to a renderfarm that has no GPUs. Set this variable to 2 to disable this fallback mechanism, or 0 to disable the built-in device completely. On OSX this variable has no effect.

IMO the most impressive use of Volume FFT is here: If you download the code you'll find a bunch of .hip files that do smoke simulation via FFT as per the paper.

Hi Yunus, Just a minor point, for your VolumeWrangle approach you can just do: sum += volumeindex(0, "density", set(@ix-1, @iy, @iz)); which will skip the position calc and linear interpolation and be more similar to the OpenCL code (though still way slower!)

Try decreasing the Erosion Scale on the ParticleFluidSurface node:

There's an existing RFE to add this functionality to ParticleFluidSurface::2.0. Skybar's suggestion is good, but if you want extra control you can create the extra "stretched" particles yourself before sending them into the asset. More info: The following VEX code is very close to what the original speed stretching does. You can paste this into an AttribWrangle then press the little button to the right of the text box to auto-create the spare parameters. I found the following values worked fairly well. Stretch Scale: 1/96 (or 1/48) Max Stretch: 1 Min Size: 0.4 Particle Density: 2 float stretchscale = chf("stretch_scale"); float maxstretch = chf("max_stretch"); float minsize = chf("min_size"); float particledensity = chf("particle_density"); vector stretchvec = -v@v * stretchscale; float len = length(stretchvec); if (len > maxstretch) stretchvec *= (maxstretch / len); float radius = @pscale; vector origpos = @P; int nparticles = int(particledensity * len / radius) - 1; if (!nparticles) return; for (int i=1; i <= nparticles; i++) { float duplicatepos = float(i) / float(nparticles); float duplicatepscale = lerp(radius, radius * minsize, duplicatepos); int newpt = addpoint(geoself(), @ptnum); setpointattrib(geoself(), "P", newpt, origpos + duplicatepos * stretchvec); setpointattrib(geoself(), "pscale", newpt, duplicatepscale); } If you're using the Spherical surfacing Method, you'll need to unlock the ParticleFluidSurface asset and change the Minimum Radius in Voxels on the vdbfromparticles1 node to something smaller like 0.25 to handle the smaller radius sizes for the stretched particles. For Average Position this is not required.

Sadly it's almost certainly due to your GasSurfaceTension node. I only tried the .zip file above, but with surface tension disabled it's completely stable. The GasSurfaceTension node adds an explicit force on the fluid and is fairly unstable at high Surface Tension values and low substeps. The workarounds are generally to use a lower Surface Tension setting (0.1 was still stable in your test file) or use more FLIP Min Substeps if you really need the high Surface Tension.

Are you using the Scatter option on the Particle Fluid Tank SOP? Those extra surface particles can help create a smoother surface to start. Another option is to use APIC (Swirly Kernel) which cuts down on surface noise. Or use APIC and run 20-30 frames until the fluid settles down, write those particles to disk, then use them as the initial state for a regular (possibly Splashy Kernel) FLIP sim.

The usual way is to handle the displacement yourself using the "restdisplace" output of OceanEvaluate. So don't feed your geometry into the OceanEvaluate, only leave the spectrum connected to the second input. Then on the volumes tab enable Rest Displacement. That will output three 2d volumes containing the displacement vectors. Finally use an AttribWrangle to do the displacement. Plug your geometry to be deformed into the first input and the OceanEvaluate into the second. The displacement is a one-liner: @P += volumesamplev(1, "restdisplace", @P); In that code you can scale the amount of displacement however you like.

Most likely in the Resample Input option on VDB From ParticleFluidSurface. The issue also goes away if use a higher Renorm Accuracy on the Dilate node, which maybe should be an option on the ParticleFluidSurface node, or possibly we should just default to it internally. Would you mind submitting a bug? This issue has been fixed recently: Wednesday, February 3, 2016 Houdini 15.0.376: Fix refresh problems when interrupting the cooking of various VDB filtering nodes. This also fixes the refresh problems of the Particle Fluid Surface SOP, which internally used these VDB nodes.

Assuming you're using the Bullet RBD solver, you likely need to turn off Enable Sleeping on the RBD Object | Collisions | Bullet Data tab. (Once the object slows down enough to float, it goes to sleep!)

The new surfacing node is an asset named ParticleFluidSurface::2.0, which means it's allowed to break backwards compatibility and only share a name with the previous node, the new one being fully VDB based. Any old files will still pull in ParticleFluidSurface::1.0. But it also implies that the old version of the node is deprecated, since you can't create one from the Tab menu (you have to use the opadd command). This is how node versioning works in general; just in this case we wanted to deprecate the old version and reuse that descriptive name for the new one. I can't really comment on the new functionality besides what you see in Scott's video, but there will be additional info covering it in detail after the release.

You should be in great shape with a Titan X. Recent NVIDIA OpenCL drivers give access to the full 12GB for good size pyro sims, and you don't need fast 64-bit support. As Mark said Houdini mostly uses 32-bit floats internally. You might need to switch the FLIP Viscosity solver to 32-bit if accelerating with OpenCL (a really good idea), but otherwise it's all 32-bit by default.

And here's the PowerPoint file with videos (minus the new Siggraph demo videos which are replaced with stills since they're embargoed until after gold release): https://s3.amazonaws.com/vfx/OpenVDB_in_Houdini_15_stills.pptx All the 2015 (and 2013) OpenVDB course slides are pretty interesting (and often Houdini-centric): http://www.openvdb.org/documentation/