Jason

That looks like it provides nice results, although without many options to modify behaviour.

Look into the Scatter SOP's ability to calculate a size attribute.

This looks pretty amazing, well done!

SideFX perform daily builds, which they make available for download. That's the last number in their versioning scheme - major.minor.dailybuild. You can monitor the changelog and decide to download the daily build immediately should you see something implemented on any certain day. It's wiser to wait for so-called "Production Builds" (which are tested a little more thoroughly) but the daily builds are most often healthy builds.

It'll be either in the What's New (the section you found already) or in the Changelog -- http://www.sidefx.com/changelog/

Look into using the CopyStamp methodology where you can control the variation with a Switch SOP containing the randomization method you choose. You could choose something based on @id, for sure.

That could be any number of things... you may have more luck if you post a little .hip file demonstrating the problem.

You can blend (using a little Attribute Wrangle/VOP, for example) between a smooth surface and your noisy surface using a point attribute. You can create that point attribute in a million ways, and so, again, using an Attribute VOP to create it using a Ramp Parameter against the u value of the curve, and make sure the value is swept onto your geo.

Yeah, if you do some heavy renders (lots of texturing, lots of geometry) with Mantra or Karma, you'll see an application that is well multithreaded and probably get to test your memory performance with more accuracy than with simulation. Mantra/Karma are "trivially multithreaded", meaning every camera ray can be thought of as a little program and uniformly executed in a separate thread in a rinse&repeat pattern. There are shared memory caches and such but those have been well tuned for multithreaded access. Simulation has gnarlier phases that often require traversing the simulation data in different ways, and some of those methods are harder/less effectively multithreaded, but still might be interesting to use as benchmarks due to that very reason. To test memory properly, however, use a dedicated benchmarking program that tests different memory access patterns. How those benchmarks apply to real-world programs is rather dependent on the program in question, of course.

Hi Johan, Not all phases of simulations are completely threaded (due to vastly different algorithms being used for each) and this would account for the not-quite-100% utilisation at all times. I don't believe the speed of your memory would not affect this, at least not in an appreciable way. There are some switches you can flip to use different algorithms that multithread more easily but that doesn't always result in faster simulations. (e.g. FLIP projection method)

This is interesting development, Vlad - would love to see where you take it!

Did you update Houdini versions? Or update a nested HDA? If you re-save your HDA it'll "forget" about those parms and the warning will go away.

Moderator here. @ashu_tosh_m please attempt to do this work for yourself instead of just asking for hip files repeatedly with no attempts to do it yourself.

You can refer to an image in COPs by use of the op:/ syntax in the texture filename field. e.g. op:/img/img1/mycop It's not as efficient as writing out a RAT file to disk but it's convenient!

They offer the use of the standard file chooser for Mac only - and I don't know why they don't offer it for Windows. There is an environment variable (see 'hconfig') or a pref - https://www.sidefx.com/docs/houdini/ref/windows/mainprefs.html Do you ever check the stack trace for the reason behind crashes? If so, do you ever report what you find?