Atom

Here is a basic setup. It uses a second loop to give each primitive a unique name. Inside the loop, the area for each primitive is stored as an attribute. After the loop, pscale is derived from the area. Use the ramp and the multiplier to dial in the sizes. ap_recursive_subd_001.hiplc

Try VDBFromParticles followed up by ConvertVDB to polygons. Or try ParticleFluidSurface node.

It looks like you code is working, however, you have multiple strokes so each stoke is applying the code to itself. There are some icon buttons for flipping your ramp around, which might help, but you may want to simply redraw and think about your start and end locations. There is also a free tree HDA available in the content library that you might want to use and simply ray the results onto your sphere.

At a glance, your quote characters are are wrong and on some lines they are missing. For you final $PATH variable, don't forget to add in the previous $PATH. Something like this..? PATH = "C:/ProgramData/Redshift/bin;$PATH" HOUDINI_PATH = "C:/ProgramData/Redshift/Plugins/Houdini/18.0.287;@/python2.7libs;&" HOUDINI_DEFAULT_RIB_RENDERER=prman23.3 RMANTREE="C:\Program Files\Pixar\RenderManProServer-23.3" RFHTREE="C:\Program Files\Pixar\RenderManForHoudini-23.3" RMAN_PROCEDURALPATH=$RFHTREE\18.0\openvdb;& HOUDINI_PATH=$RFHTREE\18.0;$HOUDINI_PATH;& PATH=$PATH;$RMANTREE\bin;&

I generally assumed that density should remain in the range of 0-1, but you can overdrive it. This produces that minecraft blockiness that you see in a lot of new user renders. I wouldn't worry about it too much. Just as with audio, if you normalize too much, you can flatten out your small details. With the VDB Diagnostics node I typically activate Uniform Background. This can help knock out some background noise for density values near zero, but not zero. Under General Test you can fix values in range, but I don't think that remaps them. The help card is a little lean on this node. Input is the best place to start for controlling your values. Try not to overdrive it from the start. This simple setup can allow you to play around with values by adjusting the @density value inside a Volume Wrangle.

Think of it as a clip or peak in an audio signal. Sure you can turn up the volume, but at some point you'll exceed the head room and produce a distorted signal. The same is true with density. Once you exceed the valid range, the value will be clipped and your are losing precision at that point. The most common artifact will be blockiness while rendering. It's not a show stopper. If it looks good, it is good. You may only see the artifacts when you attempt to use the exported VDB in another package. Other packages may attempt to auto-correct the bad values. By keeping them in range to begin with, you can avoid that.

Check your preferences. There is a drop down that will allow you to select your OpenCL device. The message suggests that you may have defaulted to the Intel based implementation instead of the nVidia. Also the main thing to consider is does your simulation actually fit within the ram of the video card? When I google the 2060rtx I see that it only has 6GB. That's not a lot when it comes to a simulation. Its easy to exceed that. One way to test that is to pull down the example file at this link and follow the instructions. https://www.sidefx.com/forum/topic/25234/

There is a couple of setups at this link that looks a little like your first post reference.

If you purchase 4 8gb chips now, you'll fill all the slots on the motherboard. This means when you want to add more memory, you'll basically be throwing those chips away (or repurpose them in another rig) Consider choosing 2 16gb chips to start with, then you'll have two slots available to expand with. Instead of choosing the bronze on the power supply you might want to upgrade to the gold. I know it's only a 5% difference, but over time you'll draw fewer watts from the electrical grid at a 50% load. https://www.google.com/search?client=firefox-b-d&q=80+plus+bronze

You can always add another volume source and animate the box growing in size. ap_divergence_fill_test.hipnc

You could try a VDB Smooth perhaps, but your best bet it to boost density prior to simulation rather than afterwards in the render.

That's not really a burst, that is more of a slow dissolve. Speed it up, perhaps check out some of those experiments done by the SloMo guys on youtube.

Check out Mark's presentation for the Houdini Hive 2020. Around forty minutes into the presentation he talks about how he used a raynode to project a lot of points on to a surface. https://www.sidefx.com/houdini-hive/houdini-hive-worldwide/#mf

I'm wondering what fields I need to export to VDB to get the same look that I see in the viewport (in other DCC packages). When I try to experiment with the volume visualizer, I can't reproduce the same look in the viewport? Any tips on how to match the visualizer to viewport?

I don't think I would use Python at all, it is still single threaded. It's not going to scale very well when you throw a large object count at it. To randomly offset animations you could use the Retime node. ap_rnd_retime_animation_053120.hiplc