Jump to content

johner

Members
  • Content count

    314
  • Joined

  • Last visited

  • Days Won

    11

johner last won the day on February 15 2016

johner had the most liked content!

Community Reputation

82 Excellent

About johner

  • Rank
    Illusionist

Personal Information

  • Name
    John
  • Location
    Austin, TX

Recent Profile Visitors

10,541 profile views
  1. 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.
  2. Volume FFT Usage?

    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.
  3. Volume Convolution: VEX & C++ vs OpenCL

    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!)
  4. FLIP Mesh Artifacts - Need some tips

    Try decreasing the Erosion Scale on the ParticleFluidSurface node:
  5. 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.
  6. Velocity Flickering in Viscous Fluid

    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.
  7. FLIP - Awaken by Geometry

    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.
  8. Ocean Evaluate Mask

    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.
  9. vdb from particles error

    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.
  10. RBD Stop Problem (FLIP)

    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!)
  11. 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.
  12. Titan X and 64bit OpenCl computation

    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.
  13. Houdini 15 Sneak Peek

    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/
  14. Grain Sim with Collision Geo that has changing topology

    You might try assigning the point number to an id attribute on each point of your collision geometry before any simulation. Then unlock the Collision Source SOP ("Allow Editing of Contents") and look for the compute_velocity node and turn on Match by Attribute. It's possible that parameter should be promoted to the top-level of Collision Source.
  15. Gas Particle Neighbour Update?

    That microsolver is used in the old SPH fluids to maintain a list of neighbor particles within a search radius. These days you're better off just using pcfind and storing the results in array attributes. So using a POP or Geometry Wrangle: // next two variables could be parameters int maxn = 100; float scale = 2.5; float searchrad = f@pscale * scale; // find nearby particles int n[] = pcfind(0, "P", @P, searchrad, maxn + 1); // remove this particle from list removevalue(neighbors, @ptnum); i[]@neighbors = n; On the Inputs tab set Input 1 to Myself or Myself (no reads of Outputs), the latter being faster. You can then loop through that array to do various neighbor-lookup type things. The POP Grains solver does lots of this if you want to look inside.
×