Jason

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?

How flat can you make the UI using the color scheme files? I wonder if anyone has pushed it as far as it can go?

If you're rendering with Mantra, you might want to look into "checkpointing" -- which can help a partially rendered frame pick up from where it left off. https://www.sidefx.com/docs/houdini/props/mantra.html -- search for vm_writecheckpoint

Hi again! Definitely interesting as there are no doubt many UIs/Qt apps out there that try to help visualize git repos and perhaps you could take advantage of those. One important thing to keep in mind is that HDAs can be used for tools - low to high level operations, and also for "assets" - like rigs or even just static data inside HDA sections. The storage mechanism might be the same, but usually tools are released like code and thus managed by pipeline, and assets versions are managed by artist, often delivered by an asset management system. Perhaps you're considering this solely for tool delivery? As mentioned on chat, but this would be interesting to see if you can find a way to accommodate merging changes. All the systems I've used have to employ locks to avoid conflicts, or insist you branch or something. In a multi-user environment, conflicts could be rather frequent. Also, perhaps you could consider evaluating whether a git flow workflow would be appropriate for HDAs - or if it's just overkill.