Pyro Clustering Tutorial

[trzanko]

In this tutorial we will go over how to set up optimized pyro clustering with oriented DOP containers in Houdini given a piece of geometry moving through a scene. This process will lower simulation time and be more efficient when saving to disk because there are fewer voxels. 

Link to Tutorial -> https://gum.co/TqUNR

We first go over how to get things set up quick and easy and in the second half of the tutorial we make further optimizations using VEX. We'll look at how to rewrite cluster points to do exactly what we need it to, which includes rewriting the resample sop using VEX.

An intermediate tutorial for those looking to speed up their pyro workflow and learn some VEX.

Includes the scene file!

Hope to see everyone leveraging these optimizations in the future and squeezing in those extra few iterations before deadline!

You can reach me at trzankofx@gmail.com for questions or comments.

Edited January 27, 2018 by trzanko

[prtmsh]

gr8!!!

[Guest tar]

Cool stuffs! Out of interest, when using multiple smokeDop domains there are many density and vel fields exported into Sops. What is the most efficient method to flatten those all together into just density and the vel fields? 

Edited August 28, 2017 by tar

[trzanko]

7 hours ago, marty said:

Cool stuffs! Out of interest, when using multiple smokeDop domains there are many density and vel fields exported into Sops. What is the most efficient method to flatten those all together into just density and the vel fields? 

Are you asking how to flatten all the containers into a singular container/field? They're already just density and vel fields, but you're right there is a vel and density per container.  

I don't see the benefit of flattening all the volumes into a singular container or field as this field would have to encompass all the clusters and itself be very large. If it's because you want to avoid the doubling up of overlapping velocities/densities when rendering or using this sim as a vel source for another sim, you can create a volume that represents the amount of containers overlapping a given position and multiply the densities/velocities by the reciprocal of the amount of containers overlapping that location. 

Hope that answers your question!

[trzanko]

Happy to announce part 2 of my pyro clustering tutorial!

Link to tutorial -> gum.co/lAcVQ

In this tutorial we will go over how to set up oriented forces on an oriented cluster simulation, this will ensure that initial, internal and external forces work as expected.

We'll create a simulation that uses animated initial forces, external particle forces and internal microsolvers to influence a rotated cluster simulation. Learn how to create temporary fields in DOPs, apply transformations to a field and integrate them with a simulation.

Make sure to watch part 1 or download the digital asset as we'll need the digital asset we created in that tutorial in this one.

An intermediate tutorial for those looking to optimize their pyro simulations and learn some VEX.

Includes the scene file!

Hope to see everyone using rotated cluster simulations in the future!

Link to Part 1 tutorial and digital asset -> gum.co/TqUNR

You can reach me at trzankofx@gmail.com for questions or comments.  

[Guest tar]

58 minutes ago, trzanko said:

I don't see the benefit of flattening all the volumes into a singular container or field as this field would have to encompass all the clusters and itself be very large. 

Perhaps turning it into a VDB, then merging would take care of the inefficiencies of the large sparse volume?

Overall it's use would be for tidiness. Haven't thought all use cases through as multiple domains are somewhat new and not sure how compatible they are with all ops down the line. i.e. Redshift doesn't  seem to be able to handle merged volumes so I need munge them into a single container. 

Thanks for the great work!

[Pazuzu]

21 hours ago, marty said:

Perhaps turning it into a VDB, then merging would take care of the inefficiencies of the large sparse volume?

Overall it's use would be for tidiness. Haven't thought all use cases through as multiple domains are somewhat new and not sure how compatible they are with all ops down the line. i.e. Redshift doesn't  seem to be able to handle merged volumes so I need munge them into a single container. 

Thanks for the great work!

Yes, I usually, flatten everything using vdb, and for the velocity fields, just use a max operation, you will have at the end a vdb combine for every field class in a for each loop.

[animatrix]

1 hour ago, Pazuzu said:

Yes, I usually, flatten everything using vdb, and for the velocity fields, just use a max operation, you will have at the end a vdb combine for every field class in a for each loop.

You can also do this without a For Loop block using a Volume Wrangle SOP.

[fencer]

Usually use this approach to merge clusters.

vdb_merge_clusters.hip

[Guest tar]

Thanks all! Very cool. Any examples @pusat always appreciated!

 

 

Edited August 29, 2017 by tar

[Sepu]

On 8/28/2017 at 9:41 AM, marty said:

Perhaps turning it into a VDB, then merging would take care of the inefficiencies of the large sparse volume?

Overall it's use would be for tidiness. Haven't thought all use cases through as multiple domains are somewhat new and not sure how compatible they are with all ops down the line. i.e. Redshift doesn't  seem to be able to handle merged volumes so I need munge them into a single container. 

Thanks for the great work!

Hey Marty, 

Redshift does support merged volumes btw and now also support SOP Material as well in version 2.5.27 

[Houdini] Support of volume materials defined at SOP level using the shop_materialpath primitive attribute. Each volume group can have its own material.