Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Posts posted by Atom

  1. The only way I have been able to experience OpenCL speed up is by following the rules listed here:

    That post is for smoke, but it applies to flip and other OpenCL accelerations as well.

    Turn off the cache, don't continuously emit, and write your result directly to a disk file. Each time you break one of those rules, the CPU comes into play and the GPU advantage drops lower. Updating the viewport every frame pretty much eliminates the OpenCL gains. The most I have been able to get out of flip was about a 35% utilization on my GPU, which I monitored using MSI Afterburner.

    Try the example file at the link. It's fun to see how quickly you can simulate smoke  on your GPU.

  2. More than likely, your simulation is too complex to fit inside your graphics card. It doesn't take much to break the 11GB boundary and you're not even getting all that if you are using the same card for display, or have other applications open. One thing that will kill OpenCL is continuous emission into a scene, without a sink to remove anything. Try disabling caching on the dopnetwork, and write the result of your simulation directly to disk. Having to update the viewport every frame also diminishes the gains obtained by OpenCL.

    Particle separation alone is not enough to determine the size of your simulation. It is the box size of your domain that is divided by the particle separation that determines ram usage. If your box size grows over time, your memory footprint will grow.

    Try looking into the new sparse solver. Even though it is CPU based, in some situations it can outperform OpenCL.



  3. A few of things.

    On the gasupres node make sure you set the Fluid Type to Smoke, not Pyro.

    Also, you have to drop down an attribute wrangle between the lores and the upres node to create a detail attribute named @timescale. When this attribute is missing the time scale defaults to 0, which is no motion. Set it to 1.0 to test, but try other values to speed up or slow down the upres.

    On the output of the lores dopnet, you need to add temperature and vel fields which get forwarded to the upres network. Without those, the upres simulation won't work.


  4. AFAIK, the standard vellum setup does not accept animated input, so @age is simply the frame number. You can assign an @id to the primitives and the solver will pass it through. Then you could post-sim process using a for loop to operate on each piece.

    Here is Matt's setup with that modification.



  5. The safest way is to check that the value you fetch is valid before you attempt to evaluate the parameter.

    node = hou.node('/obj/autosaver1')
    if node != None:
    	# Success in obtaining a reference to the node.
    	p = node.parm("my_parm")
    	if p != None:
    		# Success in obtaining a reference to parm.
    		my_value = p.eval()
    		print "parm not found"
    	print "node not found"


    • Like 1

  6. I have started using .VDB instead of .bgeo.sc for all my volume work. Just write directly to .VDB. Give it a try. If you are at maximum ram, and the convert node throws you over the limit, increase your divsize by a little to gain back the memory that you lost.

  7. Check out Fencer's localized drag setup. You could place a tube around the portion of the tornado you want to affect and alter the code in the drag node to use the distance from the points of the cone to affect how strongly the drag takes place.

    For instance, up to distance 1 from the center, no drag will be applied, then more farther away. Anything after distance 3 will get 50% drag.

    vector p1 = point(0, "P", 0);
    float dis = distance(p1, @P);
    @vel *= fit(dis, 1, 3, 1, 0.5);

    This also let's you crank up the velocity a bit on the source node.


    • Thanks 1

  8. I worked on a tornado of photos a couple of years back. I ended up making two sparse tornadoes exactly on top of one another, but spinning at different speeds. It helped the final look. You might be able to accomplish that with a Retime of the original if you already have it cached out.

    Adding debris spinning around might be nice if it applies to your scene.

    Your setup looks pretty good overall.

    • Like 1

  9. I put together a short video on how to make smoke fall into a hole. There is also a setup at the end that shows how to generate a fake @heat field using the VDB Diagnostics node.


    • Like 1
    • Thanks 1