Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Posts posted by Pazuzu

  1. Hi,

    You have many options, one of the them is to just post-sample the smoke density to adjust your particles, for example using the density sampled data to mod you pscale, color or alpha; Or you can sample dynamically the smoke density at the advection stage to for example trigger a custom age to decay your particle attributes. its all up your needs!

    I hope this helps you!



    • Like 2

  2. On 12/17/2017 at 2:29 AM, Jesper Rahlff said:

    Greetings to the best forum on the web :)

    I am struggling a little with wrapping my head around the xyzdist() and primuv() functions in vex.

    I have attached a scene file that holds a dopnet with some points created on frame 1. I would like those points to stick to the geometry coming into the second input on the dopnet.

    any suggestions to how this could be done is appreciated. I am in particular interested in the usage of the xyzdist() and primuv() solution, however other methods is also encouraged!

    should there be some people that wanted to "show off" a little vop magic that is cool too.

    looking to learn so hit me with everything you got.


    All in all a simple task but good fun.


    Thanks for playing :)


    particles_on surface.hiplc

    This method uses the function you want to learn about it! And the nice thing is that is very simple to implement. Of course you need also to implement the goal using forces or modifying directly the position to attract to the surface plus this, and because we are saving the delta, all points will always stick to the rest sampled position.



    particles_on surface_aeb.hiplc


    • Like 1

  3. If you want better collision behavior, you have two options. By default the smoke/pyro solver uses the Multigrid projection method with just one iteration; This method is very fast but not good to deal with collisions, so try to increase the iterations, that can help a little bit. The second option is to change the projection method to PCG, its slower than multigrid, but gives a much better collision behavior!

    You can find this option on the Advance/Projection tabs in the solver.

    I hope this helps you!


  4. 4 hours ago, michaelb-01 said:

    Hi @Pazuzu, how do you think H16's new surface tension compares to your technique?

    Hi Michael!

    The implementation is very different. My technique is more a bunch of hacks than a "Physical Based Solution", mainly to deal with the FLIP/PIC limitations for small scale sims, like packing, volume loss, etc. Another main difference is that mine is particle based (I use also fields, but the forces are apply at particle level), the new ST that comes with H16 is volume based, it behaves very nicely, but if you need very small details you need to increase volume res and also timesteps, loosing the main benefits of the FLIP/PIC method, the speed.

    I hope that this answer your question!



  5. 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.

    • Like 2

  6. (a) This method uses volume based and point based collisions (collision detection). The results are much better at the cost of speed in some cases with huge colliders; Regards velocity this method has 3 modes to automatically compute your collision velocity, "Rigid", "Point" and "Volume". (Look at the Gas Build Collision Mask DOP node for more info)

    (b) This method uses the standard pic approach to take into account colliders into the system as sdf representations; But at particle level the collision is just a test to see if a particle is inside, if is it, it will take it closer to the isocontour of the collision sdf. For the collision velocity you must compute it yourself.

    Both are very useful methods. For example when you have large scale sims, the (a) can be a pain of slow with high rez collisions, because the solver has to recompute the collisionmask even if you sample the collision volume from sops, and that can take a lot of time. With (b) method there is no need to compute the collisionmask out of a collision relationship, so it will be faster but you can loose some nice collision behavior, it will be more basic in few words.



    • Like 3

  7. Hey Alvaro,

    Here is a bit over-complicated setup using a vector field to define the id masks, but you can use also scalar fields directly. In this setup I'm using the id masks ( aka source A, sourceB ) to affect dissipation and turbulence for each source, please look into those "shapers" in the pyro solver.

    I hope this helps you!




    • Like 3

  8. 10 hours ago, nigelgardiner said:

    Hi There

    So I've got a Flip fluid simulation which involves an emitter pouring into the glass.

    Everything is as it should be until the emitter stops, (planned) at which point the volume of the flip fluid immediately begins to collapse until it is roughly quarter of the volume it achieved at it's maximum volume.

    A total of 1.7mil particles with a particle separation of 0.004 are emitted and I still have 1.7mil particles and the end of the sim so I'm not losing particles.

    I have reseeding off.

    I've tried increasing the number of solver sub steps but that hasn't helped.

    I've tried increasing the number of particles also no difference.

    I'm going to try turning reseeding back on and see if that helps but i don't understand why it would be needed if volume is sustained until the emitter stops.

    Any advice?





    Unfortunately that's one of the limitations of the FLIP method, the volume loss. As Andrew said a particle separation can help to cont-rarest the volume loss on the system. You can try also to apply some drag forces as soon as the fluid start to settle with some speed or pressure conditions, but that can kill a bit the nice momentum.

    For this kind of FX I really miss SPH, but its so slow; So in my case I come around to this problem using a mix between PBD and FLIP/PIC in my microtension tools, this way the volume loss is less noticeable, but still not as good as the SPH method, I really hope that SESI update some of the SPH microsolvers some day!.

    I hope that this helps you!



  9. On 6/30/2017 at 2:34 AM, cupoftea said:

    or let me ask differently:
    i checked your file and think i understand, but since it is "static" (non-simulatued, since no solver), i have no idea what would it look like when simulated?

    thanks a lot again


    Yes, its just a static mask, because the field is overridden on every timestep as the relationship is active, but you can use that mask to source into a dynamic field (Density, Divergence, Temperature, Fuel, etc).



  10. If you want to find even more details of the amazing surfacepressure implementation in the FLIP solver, look at the second edition of the "Fluid Simulation For Computer Graphics" book!! Is amazing!!! :) 



    • Like 2

  11. 56 minutes ago, cupoftea said:

    so the smokeobject (right input) uses green sphere object (left input) as a density source, and the green "gasbuildrealtionshipmask__sourc

    The Smoke object is just the container of data (In DOPs is very important that you have a container where all the data will be for DOPs to process) that contains all the necessary fields that the smoke/pyro solver will use to make the sim evolve by the DOPs engine.

    56 minutes ago, cupoftea said:

    if right, what object or field does the "gasbuildrealtionshipmask__source" use as a mask?  it says "mask field source" and "reference field density". but how can the source at the same time be the source for density and mask for density

    In the file you will find two main colors to identify the relationship type, there are two in this case, a source relationship (green) and a sink relationship (red). So all the colored nodes makes each relationship works, for example for the source one, you need a merge DOP that will define the type or relationship as a source, then you need the object to generate the mask from (sphere) and finally the microsolver that will generate the mask field for your relationship (gasbuildrelationship__source). 

    Regards the "reference field density", is a parameter of the node to generate the mask as a "fog" field, by default the node creates SDF representations.



  12. This microsolver helps you to define a field mask using standard DOPs relationships (using the merge DOP for example). You can define for example a source object mask to emit fuel or density using just relationships, so if you have many objects and connect those besides the smoke solver with a merge using source relationship mode, the gasbuildrelationshipmask will create a field representing the objects as a fog or SDF representation. Attached is an example file (one hip is better that a thousand words :) )




    • Like 3