Pop Source

Pop Source

Write your awesome label here.
Write your awesome label here.
Write your awesome label here.

The pop source node is responsible for bringing in geometry from SOPs and generating particles based on that imported geometry.

Drag to resize


    In Houdini, it's common practice to source in your geometry from a simulation using a dop node like the Pop Source.  The reason why Houdini does it like this is because it allows us to easily describe the behavior and attributes that we want.

    The Pop Source node is responsible for the following tasks:

        *  Determining how and when particles are spawned and killed
        *  Importing geometry from SOPs to be used for creating particles
        *  Applying various attributes to the spawned particles-  These include information about them (such as life, id, and age) along with behavior (such as initial velocity) which can be understood by the pop solver to determine the behavior of the simulation.
        *  Importing geometry from SOPs to be used for creating particles

    The confusing thing about the pop source at first is that the particles you bring in with this node do not exist within the pop source node itself.  Instead, we use "Objects" to contain the particles which are generated by the Pop Source node.  For more information on this process, visit Houdini For The New Artist II.

    For clarity sake - the word "Points" = "Particles."

Drag to resize


Emission Type:

--  Scatter onto Surfaces
    *  Scatters the desired number of points/particles onto the surface of the imported object.  

--  All Points
    *  Look at the points that are brought in from sops.  These points will be where the particles spawn at each step.

--  All Geometry
    *  Instead of just spawning points which aren't connected to anything, this setting brings in the entire SOP mesh at each step!  This includes primitives.  Additionally, all the points on that mesh are treated as particles (which have all the normal pop behaviors that you can imagine).  In practice, this option leads to some very interesting abstract effects when used in combination with pop forces.  This can also be used to bring in constraints (typically expressed as polylines) or other SOP attributes that are not stored onto points.

--  Points
    *  Look at the points that are brought in from sops. These points will be where the particles spawn at each step.  This is different from the "All Points" option because this also allows you to specify how many points/particles on the mesh are going to spawn at each step.  "All Points" does not allow you to specify how many particles/points.  If you are spawning less points than the number of points sourced in with your SOP mesh, then the solver will pick a random point locations to spawn from at each step.

Geometry Source:

--  Use Parameter Values
    *  Good for manually selecting where you want to bring in Geo and enables the "SOP" and "Use Object Transform" options.

--  SOP
    *  See above

--  Use Object Transform
    *  The "Transform" this refers to is obj level transform.  So, if you animate something at the top obj level of your network and you want that information brought in, then you'll need to be sure that this box is checked.

--  Use Dop Objects
    *  This parameter is not included in the SideFX documentation, but does the following:  It takes a DOP object (which  -remember - contains the geometry for the solver to work on) and it uses that geo as the source for particles.  Keep in mind that you only need to include the node name of the object.  It will not work if you drag the node into the "DOP Objects" parameter and create a path to the node.  You only need to specify the name of the object.  This parameter can be very useful if - lets say - you have a collision object flying through the air that needs particles spawning from it.

--  Use First, Second, Third, and Fourth Context Geometry
    *  This uses the first, second, third, and fourth input of the dop network node to source in geo.

Source Group

--  Want the solver to look at your incoming SOP geometry and go through the groups to determine where particles spawn?  Well, this lets you do that.

Group Type

--  Be sure to always specify the group type

Emission Attribute

--  This parameter doesn't do what you might think it does.  It is NOT a scale on how many particles are being spawned.  Instead, think of it like this:  The Emission Attribute determines how likely a polygon is to have points scattered onto it.  If you set the Emission Type to Scatter onto Surfaces, this attribute will work.  Otherwise it will not.  1 means that there is a 100 percent chance at each step that particles get scattered onto the surface of the polygon.  A value of 0 means that there is a 0 percent chance that particles will get scattered onto the surface of the polygon.

The next section deals with how you'd like to scatter points along the surface of an object.  I'd recommend not using relax iterations, scale radii by, and max relax radius because it slows down your simulation and it removes variation from the scattered point patterns by making everything evenly spaced apart.  It, of course, is up to you however.  

Relax Iterations

--  This parameter relates to the "Scatter" node parameters which scatter points along the surface.  As such, this option is only available if your emission type is set to Scatter Onto Surfaces.  Relax iterations will make the spacing of the scattered points more evenly distant from each other.  More iterations = more accurate distance away from each point but also slows things down.

Scale Radii By

--  When the points are spread out from each other, they take an imaginary sphere ("Radii") And if another point falls inside the radius, then it pushes away from that particle.  You can specify this radii size here.  It's also good to note that going negative will clump the particles together.

Max Relax Radius

--  This gets used for technical reasons - basically to prevent a point from searching out into infinity for points to relax with.  If you turn this off, the maximum distance a point can look is half of the diagonal of the bounding box of the object.  So, a value of 0 ought to suffice for nearly all situations.  If you're interested in the technical reasons why this is the case, then check out the user doc text:

"This must be set appropriately to prevent outlier points in low-density areas causing problems when relaxing points.
In order to approximately maintain variations in density, points are assigned radii inversely proportional to density (for curves), the square root of density (for surfaces), or the cube root of density (for volumes). This may cause problems for areas whose densities are near zero, especially in volumes, when painting density on a surface, or when using a density texture with a black background, since the radius approaches infinity. This parameter specifies the maximum radius within which points will influence other points.
When this is disabled, there will still be a maximum radius, which is currently chosen as half the diagonal length of the bounding box of the input geometry."


Scale Point Count by Area:

--  This parameter has a terrible name.  Remember how the "Emission" attribute above doesn't scale up the particle count and instead acts as a way of adjusting the probability of whether or not something scatters along a polygon?  Well, if you check this box, it will now scale based on that emission attribute.  So, if you specify a value of 10, then 10 times the number of particles will be scattered onto the surface.  In practice, this is how this checkbox gets used the most.

    In addition, this parameter will also allow the number of particles to exceed the constant and impulse count numbers because it now adds extra particles to polygons that are big.  The overall scale of particles is then adjusted by the Reference area parameter.

Remove Overlapping:

--  Want to be sure that new particles don't spawn within the radius of existing particles?  This allows you to prevent that situation from happening, and it's super-nice because newly spawned particles can cause your sand/water simulations to blow up if you add particles within the radius of existing particle's pscale values.  

"Potential new particles are compared against the existing set of particles. If their pscale attribute overlaps, the new particle isn’t added.
This can be useful to continuously add new particles to a sand simulation without creating explosions from overlaps.
Note this only tests against particles that already exist, so it is important the set of new sourced particles don’t overlap within themselves."

Drag to resize


creates a certain number of particles each time the node cooks.
creates a certain number of particles per second.

Impulse Activation:

--  Turns impulse emission on and off. Impulse emits the number of particles in the Impulse Birth Rate below each time the operator cooks. A value of 0 means off, any other value means on.

Impulse Count:

--  Number of particles to emit each time the node cooks (when Impulse Activation is turned on)

Const. Activation:

--  Turns constant emission on and off. Impulse emits the number of particles in the Constant birth rate below each second. A value of 0 means off, any other value means on.

Const. Birth Rate:

--  Number of particles to emit per second (when Constant Activation is on).

Max Sim Points:

--  This parameter is a cap on the total number of points in the bound geometry. If this limiting is enabled, then the emitter will not create any more particles once the specified maximum is reached. 
    In other words, this is the maximum number of particles that this pop source is allowed to make inside your DOP network.

Max Points per Frame:

--  Limit on the number of points that can be added each frame. This option can be used to prevent the emitter from spawning an undesirably large amount of particles as a result of errant parameter values. 

Probabilistic Emission:

--  This parameter seeks to answer the question: "When will the particles be born when using constant birth rate?"  To see what this does, try setting the const. birth rate to 1 so that one particle is supposed to be spawned each second.  What you'll notice is that with Probabilistic Emission turned on, it will not always spawn at the start of each second.  This is because Probabilistic Emission is saying, "Hey it's cool if we spawn things at a rate of x particles per second, but it doesn't have to happen at exactly each second."  It could spawn 3 particles all at once after three seconds have gone by.  If you turn Probabilistic Emission off, then you'll notice that each particle spawns at exactly one second each time.

Just Born Group:

--  Want to make a group which contains all particles which were just born?  Type in what you want this group to be called and you got it.  The particles will only be in this group the same substep that they were created.


--  Randomly changes the overall result of the simulation.

Life Expectancy:

--  How long should your particles live before they're killed?  This parameter is in seconds.

Life Variance:

--  Want to randomly change when particles die?  Life Variance takes the Life Expectancy and randomly adds/subtracts up to the value you specify here.

Jitter Birth Time:

--  This parameter is very important if you want to emit on moving objects, and you'll want to use this properly with the "Interpolate Source" parameter.  Jitter birth time alters the age attribute on your points and moves them around IF they are sourced in with velocity. 
    Jitter birth time looks at your subframes and makes an age attribute that randomly correlates to a location along the subframe. (For more information about subframes, visit Houdini For the New Artist II).  Once it does that, it then moves your particles based on the incoming velocity and the new age attribute.  Without velocity, it will not move your particles.

To easily see what this does, make a viewport marker with the age attribute values visible.  

To set this up properly, set the jitter birth time to Negative if it is in the post solve.  This means that your age starts off negatively.  This also pushes you particles away from the direction that the emitter is moving when velocity gets used in conjunction with age to move particles around.  If you ever find that particles are spawning in front of your emitter, there's a good chance that it's due to velocity and positive jitter birth time pushing them forward.  If you plug your pop source into the pre-solve, then set the jitter birth time to positive.

Interpolate Source:

--  This parameter allows you to smoothly emit particles along the subframes.  This parameter will OVERRIDE the jitter birth time velocity*age operation to move the particles around (as described above).  So, if you're using this parameter, then you'll need to work differently than what is described above.  

This basically works by stretching the position of your mesh points from one frame to the next OR by using velocity to predict where something is going on the next frame and then stretching the point positions to that location.  In practice, only use velocity if you have changing point ids in your source.

To keep things simple here, do this:

If your pop source is plugged into the post-solve of the solver, set jitter birth time to positive and interpolate source to negative.  If plugged into the pre-solve, then use negative Jitter Birth Time and backwards interpolation.

The user docs mention a clumping issue if large forces are present, but I haven't been able to replicate the issue as of yet.

Interpolate Method:

--  See above

Drag to resize


This section deals with how the pop source should deal with existing attributes that are brought in from SOPs

Initial State:

--  If the emission type is Scatter on Surfaces, and the source is a SOP Path, the initial state of the particles can be set to sliding, stuck, or stopped.
Particles can then be released by setting the i@sliding, i@stuck, or i@stopped attributes to 0.

        *  Free flying = normal particle behavior
        *  Stopped = "Particles that stop will no longer integrate their velocity, position, orientation, or angular velocity. They can still be moved directly though.  For example, by the Look At POP in instantaneous mode."  In other words, you're telling the particle that it's not allowed to use velocity, orientation, or angular velocity to move around.  The only way to do so is by explicitly defining its position, orientation, etc.
        * Stuck = When a particle collides with an object, it will stick to the surface.  @stuck=1  Unlike "Stopped," particles
set to the stuck behavior can move around in space until they hit something.  
        * Sliding = When a particle collides with an object, it will stick to the object by a certain amount.  How strongly it sticks to the object depends on another attribute called "cling."  You can adjust "cling" by using a pop properties node.  If the forces in your scene are strong enough, it can cause the particle to detach from the surface.

Inherit Attributes:

--  Specifies which attributes you'd like to import from SOPs.

Initial Velocity:

--  This tells the pop source how you would like to import velocity (point attribute called "v").  You can "inherit" it - which means use the sop velocity values, you can "add to inherited" - which means take SOPs and then add some, or you can specify it directly using the "set velocity" parameter.

Inherit Velocity:

--  Scales up or down the imported velocity from sops.
-- See above


--  Adds or subtracts randomly up to this amount on your velocity.

Add ID Attributes:

--  A particle id is a unique id that's separate from point id.  The reason why this happens is because point ids will change if particles die.  The particle id created here will not change - even if particles die during the simulation.  This has implications for many things in Houdini - especially after something has been simulated.

Drag to resize

Stream & Bindings:


    In Houdini, streams are basically like groups in the sense that they allow you to isolate things in DOPs.  The reason why you might want to use streams instead of groups is because they are more efficient and are easier to read when viewing a node network.  If using particles, this is often associated with the popstream node which is placed above your pop forces.
    By default, most DOP nodes use $OS as the stream name so that you can easily identify which node something came from.  As an example, you could use two pop source nodes with different stream names and then color those particles.
    Also notice that whenever you have a group parameter dropdown in dops, this group is looking for the stream name.
    For more examples of streams, visit the SideFX documentation here:  https://www.sidefx.com/docs/houdini/dopparticles/streams.html


    Bindings can be used to tell which nodes are allowed to work with each other.  Nodes which belong to the same geometry name are allowed to work with each other.

    As an example, if you set the binding on a pop source to "goobie" and leave everything else at its defaults, no other node in your dop network will want to work with the popsource because they have a different binding name.  If, however, you go to your solver and change its binding to "goobie" as well - now the pop solver will work with the pop source node.  Lastly, if you set a pop force's binding to "goobie", that will now allow the pop force to interact with the pop source node.  NOTE:  Global forces (ex: the Gravity DOP) do not feature any bindings and will work on all data within the dop network.