General Attributes

• v@Cd
  
  v@Cd represents color by using a combination of:
  Red (r), Green (g), and Blue (b) amounts.  Note that you need to use a capital "C" in "Cd" in order to use this attribute properly. 
  
  One nice thing about setting v@Cd is that the viewport will automatically detect this and shade the geometry in your scene according to its values.  Oftentimes when determining what values you'd like for any attribute, it helps to start with v@Cd and then change it to whatever other attribute you'd like once you're satisfied with the values.
  
  For example, let's say that you'd like to use an attribute noise node to set the value for a new attribute called, "foo."  If you start by setting v@Cd first, then you can quickly determine the values you'd like because v@Cd is recognized by the viewport.  Then, once those values look good to you, you can change v@Cd to "foo", and you're good to go.
  
  Sometimes v@Cd is recognized by shaders as a multiplying value against the color signal.  However, keep in mind that creating a v@Cd value of black (0,0,0) doesn't automatically ensure that your shader will color something black.  The shading signal and v@Cd are often two separate things, and it's better to think of this "color" as the "viewport color" rather than the final color of your object at render.  To add a bit more confusion to this, v@Cd is called "Cd" to stand for "Color Diffuse." 
  
  In the old days, v@Cd had a more direct impact as to the final color of an object.  Nowadays, it serves as a viewport color, and the name has stuck ever since.
  
  If you're working in Solaris, v@Cd will convert to a pimvar named, "displayColor."  This conversion takes place because "displayColor" is a USD convention that's been determined by Pixar.  Any Mtlx shaders that use a "Geometry Properties" node in Karma will be on the lookout for "displayColor" which is the converted values of v@Cd.

• v@N

  
  This attribute stands for the "Normal" of something.  The "Normal" is used to describe which way something is facing.  Note that you need to use a capital "N" for this attribute in order for it to be recognized properly.
  
  v@N is a vector attribute that uses x,y,z coordinates.  These coordinates are relative to the location of each point, prim, or vert.  The coordinates will offset away from the current position, and the direction in which it is offsetting describes which way something is facing.
  
  For example, let's say that you have a polygon primitive whose centroid (center location) is here:
  
  v@P = (23,0.4,3)
  And the primitive attribute of v@N value is...
  v@N = (0,1,0)
  
  This means that the polygon is facing upwards the Y direction.  The normal is relative to the position, so it simply says, "go up one meter in y from its current position" and that how it describes which way its facing.
  
  v@N is often used in a variety of other ways as well.  Because v@N describes the direction of something, it's fairly common to use its values as a starting value for velocity (v@v).  In shading, v@N can describe a "smooth shading" operation which makes certain areas look smooth and others look faceted.  Just google, "smooth shading with vertex normals" in google to get a visual idea of what that looks like.  v@N is also used when instancing objects to determine the orientation of something.  For more information about normals, make sure to watch the transform and orientations chapter of Houdini Principles.

• f@pscale
  
  f@pscale describes a uniform radius around a point, and it's very useful in variety of situations.  When instancing, f@pscale can determine the overall size of an instanced object.  f@pscale is also used in simulations to determine how collisions are handled.  This is often seen in particle, FLIP, and/or vellum simulations because they are point-based simulations.  Unlike v@scale, pscale is a float value because it describes a uniform size in x,y,z for the radius of a point.

• v@scale
  
  v@scale is nearly identical to f@pscale because it describes the radius around a point.  However, unlike pscale, v@scale gives you the option to scale up or down in x,y,z.  That's why this is a vector attribute rather than a float attribute.
  
  By default, v@scale will scale things in x,y,z using global coordinates.  For example, if you set v@scale = (1, 2, 1), it will always stretch upwards in the y direction.  However, these can become local coordinates if velocity (v@v) is present.  If present, it will stretch in the direction that a point is moving in rather than directly upwards in the y direction.  Note that v@up is not respected.  v@scale only changes its orientation when v@v is being used.
  
  For intermediate / advanced users - If v@scale doesn't accomplish what you're looking for, then it may be best to change the primitive intrinsic values directly on the instanced packed objects.  One way to do so is by using vex.  In that case you would...
  
  1.  Gather the packed transform matrix by using the getpackedtransform() function.
  2.  Scale it down by using the scale() function
  3.  Set the newly scaled down transform by using the setpackedtransform() function
  
  This can work as an alternative to v@scale if it doesn't have what you're looking for.  In most situations, however, using v@scale works just fine.

• v@rest
  
  v@rest describes the non-moving, default position values of a mesh.  The easiest way to establish v@rest is by using the "rest position" sop.  When using the rest position sop, you'll want to have a moving and non-moving stream of data going to the first and second inputs.  You can freeze the animation of something by using a timeshift node.
  
  This often gets used when texturing to help patterns stick to a mesh.  Sometimes when meshes move around, textures will have a hard time sticking to objects.  If that happens, using the rest coordinates instead of position coordinates will help it stick.  If you're using Redshift, then the v@rest will be automatically recognized if it's found on the points.
  
  v@rest is often used to determine the default position of a mesh when rigging.  If you'd like to reset the position of something, all you need to do is set v@P = v@rest. 
  
  Rest can also be used when determining how much a mesh has been deformed.  If you take the difference between the current position and rest, it allows you to determine how "different" the current position is vs. the original.

• s@name
  
  Coming soon...

• i@id
  
  Coming soon...

• f@age
  
  Coming soon...

• f@width
  
  Coming soon...

• f@mass
  
  Coming soon...

• s@shop_materialpath
  
  Coming soon...

RBD

General Attributes

• i@active
  
  Toggles between the object being “active.”  Being active means that this will be affected by other objects and forces within the scene. 
  1 = On and 0 = Off

• i@animated
  

  
  This will tell the bullet solver to update an object's position based on transforms that have been created within a sop network.  This will not account for meshes that require new collision shapes because they are being deformed.  This will also not apply transforms that have been made on the obj level.

• i@deforming
  
  This will tell the bullet solver to rebuild collision shapes at each timestep.  For example, if you animated a bend sop on your geometry, that would cause the collision shape to be changed over time due to the changing point positions.  In that case, you would need to set the deforming value = 1 to account for the changing collision shape.  This will also increase your simulation times.

• i@bounce
  
  This describes the elasticity of the object. If two objects of bounce 1.0 collide, they will rebound without losing energy. If two objects of bounce 0.0 collide, they come to an immediate standstill.

• f@friction
  
  This describes the coefficient of friction of the object. 0 = the object is friction-less.  Higher values will introduce more friction. This is used to slow an object down as it collides with another object.  For example, if you have two pieces of cloth colliding against each other, it will take the friction of one multiplied by the friction of the other, multiplied the global static friction on the solver, which will become the static friction for the collision.

• v@v
  
  This is the linear velocity of the object.  Linear velocity descries which way something is moving in x,y,z and it considers this over the span of one second.  So, for example, a velocity of 1,0,0 means, "Move one meter in x from where you are in one second."  Note that linear velocity does not spin objects.  It simply moves them in space.

• v@w
  
  This attribute is used to describe the angular velocity of a packed  piece.  This can be thought of in two parts: 
  
  1. w is a vector describing the rotational axis.  Imagine a toothpick that you spin with your fingers, and that toothpick is stabbing into the centroid of the packed geometry.  The direction of the toothpick is what w describes by specifying a direction that's offset from the centroid position of the packed piece.
  
  2. w also describes how much this imaginary toothpick is being spun with its magnitude.  The further away w is from the centroid of a piece, the faster the toothpick will twirl.  Hence, the faster your packed piece will spin.  This spin rate is in radians per second.  One full spin will = 6.28319 radians, so the magnitude of w needs to be at least that value to spin once per second.

• f@speedmax + f@speedmin
  
  These attributes will establish a minimum and maximum speed that a particle / packed piece can move per second.  "Speed" can also be understood as the magnitude of v@v.  The further velocity is located from the centroid of a point, the faster it will move.   This movement does not account for spinning motion, and it is described in meters per second.

• f@spinmin + f@spinmax
  
  These attributes will establish a minimum and maximum spin speed that a particle and/or packed piece can move.   This is described in radians per second.  One full spin will = 6.28319 radians. 
  For example, if f@spinmin = 6.28, then that says, "the minimum speed of rotation cannot be less than one full turn per second."

• f@computemass
  
  This determines how the f@mass attribute is calculated.  If on (f@computemass=1), it will calculate mass based on f@density and f@volume by multiplying them together.  This is typically how Houdini calculates the mass of an object by default, but you can  turn this off if you'd like to manually specify mass instead.

• f@mass
  
  This describes the mass of an object.  Mass is calculated in kilograms.  Typically, mass is calculated by taking f@density * f@volume.  Doing this allows small pieces to have less mass than larger pieces.  However, you can override this behavior by directly specifying mass with this attribute instead.  Alternatively, you can modify this attribute after the density * volume calculation has been made to control how heavy objects are within your simulation.

• f@density
  
  This attribute is often used to calculate the mass of an object by taking this value * the measured volume.  Measuring density is in kilograms per cubic meter (kg/m^3), and you need this attribute in conjunction with the measured volume of a piece to = mass.  Some users may also use f@density to isolate different materials in their scene.  Concrete, for example, would have a higher density than loose dirt, so using the density attribute could allow you to isolate these materials.

• f@creationtime
  
  This stores the simulation time at which the object was created.  This will be described in seconds rather than frames.  In practice, this is often used to trigger other events or affect older pieces in some kind of way.

• f@inertialtensorstiffness
  
  This is related to rotational stiffness, and acts as a scale factor applied to the inertial tensor.  The inertial tensor is the equivalent of mass, but governing angular velocity rather than velocity. A smaller inertial tensor results in an object that will spin more readily whereas a large value makes it difficult to spin.  In practice, this can be used to control angular velocity (v@w) more easily.  Because angular velocity is described in radians, it's often easier to use this attribute to control how easily things spin around. 
  
  One practical application for this attribute is in controlling quick rotations caused by small rbd pieces.  You could measure all the pieces, then use an attribute remap node to apply a high f@inertialtensorstiffness value to the smaller pieces and lower values for the large pieces.

• i@computecom
  
  This specifies whether the center of mass of the object should be computed automatically from the object’s collision shape.  For example, this attribute may be useful if you're trying to compute the center of mass outside the collision shape.  Keep in mind that i@computecom may override any other v@pivot values if set to 1.
  If that's the case, then setting f@computecom = 0 will allow you to adjust where the center of mass is located.  The pivot attribute could then be used to determine the center of mass position.

• f@bullet_angular_sleep_threshold
  
  This is the sleeping threshold for the object’s angular velocity.  Angular velocity controls how something spins.  This is measured in radians.  One full spin will = 6.28319 radians.  So, for example, if this attribute is set to 6.28, then it will become a candidate for sleeping once it's spinning less than one full spin per second.  An object that "sleeps" is an object that is no longer moving and rotating.
  
  In order for an object to sleep, a few things need to happen:
  1.  f@bullet_angular_sleep_threshold and/or f@bullet_linear_sleep_threshold values need to be set.  If both are set, then both thresholds need to be met before an object is a candidate for sleeping.
  2.  The i@bullet_want_deactivate attribute should be = 1.
  3.  The piece must be moving less than the threshold values set for a certain amount of time.  By default, the "Sleeping Time" parameter in the bullet solver / rigid body solver is going to determine how long a piece needs to meet these criteria before they are put to sleep.

• f@bullet_linear_sleep_threshold
  
  This describes the sleeping threshold for the object’s linear velocity (v@v).  An object that "sleeps" is an object that stops moving and rotating.  If an object is moving less fast than what is described by f@bullet_linear_sleep_threshold, then it is allowed to be a candidate for sleeping. Once v@v is less than f@bullet_linear_sleep_threshold, it must remain under the threshold for a certain amount of time before it sleeps.  That "Sleeping Time" is determined by the "Sleeping Time" parameter found in the solver.
  
  For example, if the threshold was set to 1, then once the velocity is traveling less than 1m/sec, it will be a candidate for sleeping.  Then, it must be traveling less than 1m/sec for the duration of the "Sleeping Time" in order to be put to sleep.  Note that this does not affect how a piece spins, however.  That is handled separately by f@bullet_angular_sleep_threshold.
  
  In order for an object to sleep, a few things need to happen:
  1.  f@bullet_angular_sleep_threshold and/or f@bullet_linear_sleep_threshold values need to be set.  If both are set, then both thresholds need to be met before an object is a candidate for sleeping.
  2.  The i@bullet_want_deactivate attribute should be = 1.
  3.  The piece must be moving less than the threshold values set for a certain amount of time.  By default, the "Sleeping Time" parameter in the bullet solver / rigid body solver is going to determine how long a piece needs to meet these criteria before they are put to sleep.

• f@bullet_ignore
  
  Specifies whether the object / geometry should be completely ignored by the Bullet solver.  1 = geometry is ignored and 0 = geometry is not ignored by the bullet solver.  Unlike setting the active attribute to zero, other objects in the simulation will not be able to collide against this object if they are using the bullet solver as well

• i@bullet_add_impact
  
  When this attribute is enabled (set to a value = 1), it tells the bullet solver to record any impacts that occur during the simulation, and this creates Impact / Feedback data.  This will increase simulation time and memory usage, however, it will provide you with other attributes that can be used to accomplish tasks related to RBD impacts.  To get this working, it's best to turn it on using the Bullet tab on the geometry in the dopnet instead of sourcing in this attribute from sop geometry if you are building your dopnet from scratch.

• i@bullet_want_deactivate
  
  This attribute allows / disallows pieces to sleep.  An object that "sleeps" is an object that stops moving or rotating.  Setting this attribute can be useful if you want certain pieces to be considered for sleeping and others to not be considered for sleeping. If this value = 1, then the linear and angular speed thresholds are allowed to be used to activate sleeping.

• i@dead
  
  This specifies whether the object should be deleted during the next solve.  In practice, this can be used to permanently remove pieces that are no longer needed, and that, in turn, can speed up the remaining simulation.  The pop kill node is often used to create this attribute.  However, you can also set this attribute by using wrangles if you'd like.

• i@inheritvelocity
  
  This informs the bullet solver that it should use the v@v and v@w attributes from the sop geometry to compute the initial linear and angular velocities for each piece.  This attribute can be sourced in from sops, or added in by checking on, "Inherit Velocity from Point Velocity" on the rbd packed object node.

• s@name or i@name
  
  The name attribute informs the solver which primitives / points belong with each other when making up one piece.  For example, if you had two rocks named, "rock001," the solver would look those rocks as one piece instead of two because they have the same name value.  This attribute is typically a string.  However, it can also be used as an integer attribute.  In the example we just made, if both rocks shared the same integer value of 1, then they would be calculated as one piece rather than two.

• s@collisionignore
  
  This specifies dop objects, the ID of dop objects, DOP groups, the collisiongroup_agent point attribute value of an agent primitive, or the collision group point attribute of a packed primitive that will be ignored when collisions are calculated for the piece.  There are many different ways this attribute can be used, so let's take a look at a few different examples:
  
  Example 1: You have packed pieces and are using one rbd packed pieces node in DOPs as the object. You want to create two groups: point group A and point group B. You want group A to ignore group b when collisions are calculated.  So, the way that you do this is by assigning the points an attribute called s@collisiongroup.  Group A's s@collisiongroup value = “Group A Points” and Group B = “Group B Points.” Then, to get group A to ignore group B, you would assign the s@collisionignore value to = “Group B Points”
  
  Example 2: You have two separate objects in dops. In this case, two rbdpacked pieces nodes have been used and renamed to “Group A” and “Group B.”  For Group A’s points, you can assign the s@collisionignore = “Group B” and it will recognize the other rbdpacked object’s name.
  
  Example 3: You have crowd agents that should ignore each other when colliding. In this case, you would follow the same logic used in example 1.  However, this time you would assign the s@collisiongroup_agent point attribute value to identify each individual group of agents instead of s@collisiongroup.
  
  You can also use * and ^ to say "all" or "except."  You can also keyword search names by using *word* syntax.  For example, *wall* would look for any name values with "wall" as a keyword.

• s@collisiongroup
  
  This attribute is used to help identify points or prims that are to be considered when using the s@collisionignore attribute.  Read up on that attribute to learn more.
  

• s@activationignore
  
  If the geometry is inactive and has a positive min_activation_impulse value, it will not be activated by collisions with any objects that match this pattern. The pattern uses the same syntax as the s@collisionignore attribute.  In other words, if something is sleeping and you do not want something else waking it up, then specify that ignored object here.  Just like s@collisionignore, this will accept patterns that specify dop objects, the ID of dop objects, DOP groups, the s@collisiongroup_agent point attribute value of an agent primitive, or the s@collisiongroup point attribute of a packed primitive.  For more info / examples on how to name and group objects, read up on the s@collisionignore attribute.
  

• s@activationxformgroup
  
  This parameter relates to agent primitives when simulating crowds.  When set, it allows transform groups to become activated when colliding with something.  Transform groups identify areas along the agent primitive (so, for example, you could have arm transform groups, torso transform groups, etc).  In order for this to work, you also need to set the f@min_activation_impulse attribute to a value greater than 1.  The value for this attribute is a string that is the name of a transform group that you’d like to be activated.  If no value is set, then all transform groups can be activated whenever f@min_activation_impulse>1
  
  For example, if you have crowd agents walking past each other on a busy street, you can use the s@activationxformgroup attribute to isolate any collisions to only the arms as they brush past each other.  Without setting this attribute, all other transform groups could get affected by the collisions with other agents.
  

• f@min_activation_impulse
  
  This parameter is responsible for determining how much force is required to switch from an inactive to an active state.  The activation occurs at the instant that the collision occurs. The i@activationignore attribute can be used to prevent the object from being activated by collisions with particular objects.  The higher this value is, the more force is required to switch something from inactive to active.

• v@scale
  
  When used in a RBD simulation, the v@scale attribute has a few considerations that are different than what you would typically encounter with a pop simulation.  This will scale the piece around the v@pivot in x,y,z (which oriented in world space).  If no v@pivot attribute is specified, then it will scale from the centroid of each piece.  This value will also multiply with f@pscale, which is a uniform scale for each piece.  
  
  Note that an object’s mass is not automatically re-calculated if the scale is changed over time.  If it is changing over time, then make sure to set the i@computemass = 1.  Also know that if you change the scale over time and the geometry representation setting is on box, capsule, cylinder, sphere, or plane, it will not update the collision hull unless you specify i@bullet_autofit_valid =0 using a pop wrangle in dops.  This will inform the bullet solver that it needs to re-calculate the bounding object at each frame.   Alternatively, you can also source in your own proxy geometry for each piece and use the “convex hull” option instead.  Doing this will automatically update the shape.
  
  In practice, modifying scale could be an interesting way to create abstract growth / shrinking effects for rbd pieces.  It’s not the most commonly used attribute, however, it can accomplish some interesting behavior.

• f@minstickycollisionimpulse
  
  Sticky collisions allow pieces to stick to each other as they simulate.  Make sure that you're using Houdini 20 or higher for this to work.
  
  Note in Regards to Sticky Collisions:  If you are building your DOP network from scratch instead of using the SOP nodes, then you need to add a constraint network node after the rbd packed object in order for constraints to be added properly by the bullet solver.  Additionally, you want to use one object that contains all the pieces that are being affected.  Using multiple rbd packed objects may give you problems due to the constraints not linking up properly with the pieces.
  
  f@minstickycollionimpulse enables sticky collisions and describes the minimum amount of force that's required to generate a constraint which sticks the pieces together on impact.  A value of -1 = turn off sticky collisions.  A value of 0 = make everything stick.  This "impulse" measurement is arbitrary, and somewhat difficult to control.  It measures how far inside a mesh something goes before being corrected by the solver.  Higher impact values means that the solver needs to move the object more to correct for the collision.  Adding substeps will reduce this impact value because it requires less distance for the correction. 
  
  In practice, you should first determine how many substeps you want, and then play the value a few times until you get the result you're looking for.

• i@maxstickycollisionobjects
  
  When the sticky constraints are generated, they connect two or more objects together.  i@maxstickycollisionobjects determines how many times objects are allowed to be connected to the piece. 
  
  Here's the important part to keep in mind - each substep of the bullet solver will require a new sticky constraint to be generated in order to maintain the stickiness. 
  
  For example, if you set i@maxstickycollisionobjects = 1, it will stick on frame one to one object and then immediately disappear on the next solve because a new sticky collision needs to be made. 
  
  Here's how to control this behavior... If you want something to stick for one second, take your frames per-second * the constraint iterations of the bullet solver.  By default, that would be 24*10 = 240.  Assuming that sticky constraints are made at each step, this will cause something to stick for one second.
  
  A number that = 0 or less than 0 means that there are an unlimited number of times that an object can stick to something.

• i@numstickycollisionobjects
  
  This value is updated by the solver to track the number of other objects that a piece was stuck to (limited by i@maxstickycollisionobjects). This is not a value that you would modify.  Instead, it's there to inform you on whether sticky collisions have occurred for an object.  To view this attribute, visit the geometry in dops and look for this attribute in the geo spreadsheet.

• i@maxstickycollisionpoints
  
  According to the docs, "The maximum number of anchor points (constraints) that can be used to stick this object to another object. Constraints are attached at contact points between the two objects. The default value is 1, allowing a single constraint to be created between each pair of objects."  In practice, you may notice a stronger stickiness that occurs upon impact when turning this value upwards.  However, it doesn't seem to make much more of a difference in my tests.

• s@stickycollisionignore
  
  Sticky collisions will not occur for collisions with any objects that match this pattern. The pattern uses the same syntax as the s@collisionignore attribute.  This string pattern can include dop objects, the ID of dop objects, DOP groups, the collisiongroup_agent point attribute value of an agent primitive, or the collision group point attribute of a packed primitive.  For more examples, visit the s@collisionignore attribute entry.

• i@nextid
  
  This attribute stores the id that the solver will assign to the next new object that is added.  It's not something that you need to modify, however it could be useful if you're troubleshooting any issues related to the i@id attribute.

• i@id
  
  For a comprehensive demonstration and explanation of the i@id attribute, visit Houdini For the New Artist II.  With RBD simulations, the i@id attribute is typically less important because s@name is used to identify each individual piece.  However, i@id might be useful if you need to identify each piece via an integer attribute instead of a string attribute. 
  
  Another situation which may be useful is if objects appear / disappear with the same name attribute value. In general, it's advisable to make s@name different for each new piece that spawns, however, if that's not the case, then i@id may offer you an easier way of creating a unique index value for each spawned piece.  Id ought to be created by default if you're using the bullet solver.

• 4@restxform
  
  This attribute is created automatically by the bullet solver and represents an unchanging identity matrix for each point. (For more info on transforms and orientations, visit Houdini Principles).  This attribute isn't something that you need to typically modify.  In practice, other nodes and operations may refer to this identify matrix data when going about certain calculations.  However, from my perspective, it's not quite clear as to why this data is necessary because it seems to be just an unchanging identity matrix.  According to the docs, "The initial transform of the packed primitive. The packed primitive’s current transform is the combination of this transform with the position transform (the transform applied by the simulation). The position transform is defined by P, rest, pivot, orient, pscale, and scale. This attribute is automatically initialized by the solver when a new object is identified and its creation time attribute is uninitialized." 
  

• i@found_overlap
  
  When the solver sees an object for the first time, it checks whether that object is initially overlapping with any other objects in the simulation and prevents any such pairs of objects from being forced apart. This value is used by the solver to determine whether it has performed this process for the object on a previous frame.

• f@spinresist
  
  When the f@spinresist attribute is set to value greater than 0, the angular velocity (v@w) will try to match its value to whatever the v@targetw is set to.  The higher the f@spinresist attribute is, the faster v@w will become v@targetw.
  
  In practice, this can be useful in a couple of ways.  Firstly, this could be useful if you need to apply a drag to v@w.  In other words, this can help you slow down the rotation over time.  To do this, you could set the v@targetw to 0,0,0 and the f@spinresist between a value of 0-1 depending on how quickly you want it to slow down.  
  
  Another way this can be used is if constant rotation needs to be maintained.  Other rotational forces may affect the object, but with f@spinresist greater than 1, v@w will return back to a constant rotational value that's specified by v@targetw.
  
  When f@spinresist = 1, that means, "cause v@w to match the v@targetw on the next frame."  Values above 1 will not have any additional effect.
  
  The Pop Drag Spin node can also be used to affect these values.

• v@targetw
  
  The v@targetw attribute is designed to work with f@spinresist.  Be sure to read about f@spinresist as well if you plan on using this attribute. 
  
  v@targetw is the angular velocity goal that will cause v@w to eventually become its value.  v@targetw works in the same way as v@w does by affecting angular velocity (the way that pieces spin).  If you're not familiar with v@w, then read up on that first. 
  
  You can picture v@targetw as a toothpick that spears into the pivot location and twists around by how far away from the pivot it is.  v@targetw needs a positive f@spinresist value in order to have any effect.

• v@targetv
  
  The v@targetv attribute is designed to work with f@airresist.  Be sure to read about f@airresist as well if you plan on using this attribute.
  
  v@targetv is the linear velocity goal that will cause v@v to eventually become its value.  v@targetv works in the same way as v@v does by affecting linear velocity (that is, how an object moves over the span of one second).  If you're not familiar with v@v, then read up on that first.
  
  v@targetv needs a positive f@airresist value in order to have any effect.

• f@airresist
  
  When the f@airresist attribute is set to value greater than 0, the linear velocity (v@v) will gradually match its value to whatever the v@targetv is set to.  The higher the f@airresist attribute is, the faster v@v will become v@targetv.  f@airresist often requires high values to = the v@targetv on the next frame, and they are scale dependent (meaning that they affect small and large pieces differently).  These values are arbitrary, so it can be a little challenging to control them.  For this reason, in 99% of situations, you'll have an easier time using the pop drag node instead of manually setting this value.
  
  If you do decide to control this manually, then it's best to keep this value between 0 - 1 and then use (f@drag * mass) = a value that generally has the drag amount you're looking for. 
  
  In practice, this can be useful in a couple of ways.  Firstly, this could be useful if you need to slow down the movement over time.  To do this, you could set the v@targetv to 0,0,0.
  
  Another situation is when you'd like to maintain a constant velocity.  Other forces may affect the object, but with f@airresist greater than 1, v@v will gradually return back to a constant value that's specified by v@targetw.
  
  The Pop Drag node can also be used to affect these values.
  

• f@drag
  
  This attribute multiplies against f@airresist.  The reason why you may want to use this attribute instead of directly affecting f@airresist is because it allows you to keep air resist between 0 - 1.  By having air resist between 0 and 1, it may offer you easier control. 
  
  Good values for drag tend to be about 5 * f@mass for each piece.  From there, you can then adjust the f@airresist between 0 and 1 with a fair amount of control.

• f@dragexp
  
  The f@dragexp attribute affects how quickly the v@targetv and v@targetw attributes are met.  Unlike f@airresist and f@spinresist, this has a greater effect when values are more dissimilar to the targetv or targetw vectors.  Higher f@dragexp values will cause distant values to reach the target velocities more quickly than values which are close to targetv and/or targetw.  A lower f@dragexp will have less of a drag effect on dissimilar target values.  When adjusting this, start at a value of 1 and move upwards and downwards from there until you have the movement you're looking for.
  This effect will be much more noticeable on fast moving / spinning pieces.

• v@torque
  
  The torque attribute works in the same way as v@w does by affecting angular velocity (the way that pieces spin).  If you're not familiar with v@w, then read up on that first.  You can picture v@torque as a toothpick that spears into the pivot location and twists around by how far away from the pivot it is.  The main difference between v@torque and v@w is that v@torque represents a force which alters the v@w value. 
  
  This is useful in situations when you want to rotate an existing v@w in some way.  For example, if pieces are already spinning in a simulation, and you'd like to apply another rotational force, using v@torque allows you to have better control than you would otherwise have by directly changing the v@w values as the pieces are spinning around. 
  
  It's not uncommon to require higher values with v@torque in order to see the effect.  Try starting at a magnitude of 200 and adjust from there when working with v@torque.

• p@orient
  
  In rbd simulations, p@orient is typically useful after the simulation has taken place.  It describes which way a piece is facing.  For more information about p@orient, make sure to visit the transform and orientations chapter of Houdini Principles. 
  
  Here are two examples of when this may be useful:
  
  1.  Before file caching a rbd simulation, it's best to only keep the centroids of each piece when caching.  This saves on disk space and speeds up how quickly it can be read from disk.  Once the cache file is read back into the scene, p@orient can then be used to put the pieces back onto the points with the correct orientations.
  
  2.  For some simulations, it may be possible to rotate pieces after it has been simulated by affecting the p@orient data on the cached centroid points.  Again, for more info on how to do this, visit the Houdini Principles course.

• v@pivot
  
  The pivot attribute can affect a variety of other attributes by describing a world-space location that acts as position from which scaling, orientating, and rotating can be applied.  If you're trying to scale, rotate, or offset orientations for each piece away from the centroid, then adjusting the pivot will allow you to do so.  v@pivot works with a variety of other RBD attributes.  This includes: f@pscale, v@scale, v@w, p@orient, and v@torque.
  
  One of the most common ways that v@pivot is used is when adding breakup / variation to angular velocity (v@w).  If you move the pivot away from the centroid, it can create some interesting movements with the angular velocity because rotations are no longer being applied to the center of each piece.  Instead, when the pivot is moved, the rotations are applied to the pivot location.  Scaling would also scale from the position of each pivot.
  
    if i@computecom is non-zero, then this will be computed from the object's collision shape.  In other words, you may need to set i@computecom = 0 in order to move the pivot away from the center of each piece.
  
  If you'd like to adjust the v@pivot value, you'll need world-space positions for each piece.  An easy way to do that is by determining the centroid location of each piece and then modifying the position values from there.  The centroid node can create points that are the center of each piece.  If you sample those positions using a point wrangle, that can get you started with initial values.  From there, you can offset those positions however you'd like, and that will adjust the pivot locations to areas outside of the center of each piece.

• i@bullet_sleeping
  
  This attribute tracks whether the object has been put to sleep by the solver.  This attribute is automatically created by the bullet solver.   Sleeping occurs after the object and any nearby / constrained objects have been below the Linear Threshold and Angular Threshold for a period of time that's determined by the "Sleeping Time" parameter on the solver node.  If you decide to set i@bullet_sleeping = 0, (which wakes an object up), you'll also need to set the f@deactivation_time = 0 to prevent the piece from immediately going back to sleep.
  
  You can also wake up an object (that is, change i@bullet_sleeping =0) based on f@activation_min_impulse.  This will cause the piece to wake up if it is hit hard enough by something else. 
  
  Another common way of waking up pieces is by keyframing i@bullet_sleeping = 1 along with f@deactivation_time = 0.  You can do this via a pop wrangle or a point wrangle within a sop solver.  If you'd like a certain area to become activated, then you can further control this by using groups + a pop/point wrangle.  The sop solver dop node is an easy way to create these groups.  For more info on how to use groups, visit Houdini Principles.

• f@deactivation_time
  
  The deactivation time describes how long a piece's movement has been less than the f@bullet_angular_sleep_threshold and/or f@bullet_linear_sleep_threshold.  Be sure to read up on those attributes to better understand this attribute. 
  
  When the f@deactivation_time is greater than or = to the sleep time (as specified on the solver parameters), then a piece falls asleep. 
  
  Note that the f@deactivation_time will reset to a value of 0 if a piece's movement gets above the angular and/or linear threshold while it is going to sleep. 
  
  Typically, you do not need to change this attribute value, however, it does provide insight as to whether or not the linear / angular thresholds are being met for the pieces.

• v@bullet_deactivated_color
  
  If a piece of geometry is "deactivated" (that is, put to sleep), then it will turn into whatever color you specify here.

• i@bullet_autofit
  
  This specifies whether to use the bounds of the object’s geometry to compute the collision shape when Geometry Representation (s@bullet_georep) is Box, Capsule, Cylinder, Sphere, or Plane. 
  
  By default, this value is turned on with a value = 1.  If this parameter is not turned on, then it will create a shape for each piece at the origin.  For example, if your mesh had 100 pieces, it would then place 100 overlapping spheres at the origin if the Geometry Representation is set to spheres.  These sphere's position, rotation, and size would be at default values.  When simulated, all movement for each piece will collide / react to these shapes rather than the pieces of your geometry.  So, as an example, if the sphere's are thrown up from the origin, and land on the ground plane, the pieces will copy that movement even if they are not at the same location as the spheres.
  
  It's not clear as to why you might want to turn this off.  However, the option is there in case there's a reason for doing so.

• s@bullet_georep
  
  This attribute dictates the type of collision shape that's used to represent each piece of your object. 
  
  The reason why the bullet solver creates these "collision shape" objects is to speed up the simulation.  If you were to simulate all the points / primitives that exist in sops, it would take a very long time.  So, instead, the bullet solver creates temporary geometry (these collision shapes) with less points / faces.  This "collision" geometry is then the geometry used by the solver to calculate the movement of everything, and eventually that movement is applied to the high resolution pieces again.
  
  There are a few options when creating the collision geometry.  The possible string values are: "convexhull, concave, box, capsule, cylinder, compound, sphere, plane, and none."  In most situations, you will want to use convex hull, box, or sphere.  Compound is the most computationally expensive option, and it's best to not use it if possible.  To preview these shapes, visit the RBD Packed Object node and turn on the "Show Guide Geometry" option.
  
  If a string attribute value is dictated in sops, it will override the options set by the RBD Packed Object node.  Setting the object to "none" will produce a static object with collisions disabled.  (In other words, an object that doesn't move or collide with anything).  However, you can still attach constraints to the object. 
  

• f@bullet_length
  
  This attribute relates to the "cylinder" geometry representation for your collision objects.  This attribute is only adjusted when the i@bullet_autofit is turned off, and it affects the length of each cylinder.
  
  In practice, there isn't much of a reason to ever adjust this attribute because usually i@bullet_autofit = 1.

• f@bullet_radius
  
  This attribute relates to the "cylinder" geometry representation for your collision objects.  This attribute is only adjusted when the i@bullet_autofit is turned off, and it affects the radius of each cylinder.
  
  In practice, there isn't much of a reason to ever adjust this attribute because usually i@bullet_autofit = 1.
  

• v@bullet_primT
  
  This value is automatically calculated by the bullet solver when i@bullet_autofit = 1.  It describes the position of the collision geometry in x,y,z.  There's typically no need to alter these values.
  

• v@bullet_primR
  
  This value is automatically calculated by the bullet solver when i@bullet_autofit = 1.  It describes the orientation of the collision geometry.  There's typically no need to alter these values.

• v@bullet_primS

  
  

  This value is automatically calculated by the bullet solver when i@bullet_autofit = 1.  It describes the size of the collision geometry.  There's typically no need to alter these values.

• i@bullet_autofit_valid
  
  This attribute can be useful for debugging purposes.  When i@bullet_autofit =1, this value stores whether the solver has already computed collision shape attributes.  If it has done so, then i@bullet_autofit_valid = 1.  If it has not done so, then this attribute will = 0.

• i@bullet_adjust_geometry
  
  This parameter will either allow or disallow the shrinking of the collision geometry.  When = 1, it allows it, and when = 0 it disallows it.
  
  If you have fractured geometry with pieces that are right next to each other, then it's usually best to keep this on because it creates tiny gaps between each piece when shrinking.  These tiny gaps help the bullet solver quickly calculate the frame, and it improves the overall stability of the simulation.  So, in most situations, it's best to leave this on.
  
  If this is turned off, then collision padding will push outwards instead of inwards.  For pieces that are not directly next to each other, it may be beneficial to move outwards a little bit in order to help pieces rest on the ground without penetration through the ground geometry.  Typically, however, it's best to leave this at the defaults unless you have a reason for doing otherwise.
  
  
  

• f@bullet_collision_margin
  
   This attribute describes the padding distance between shapes.  This padding is used by the Bullet engine to improve the reliability and performance of the collision detection. You may need to scale this value depending on the scale of your scene.  If you are finding that collisions are not being corrected properly when dealing with large and/or small objects, then this attribute can help.  For large scenes, try turning this value up by about a value that's (your scale)/10m.  For smaller scenes, try turning this value down by about a value that's (your scale)/10m.  You can easily adjust this value by visiting the RBD Packed Object node and adjusting the "Collision Padding" parameter.

• f@bullet_shrink_amount
  
  This attribute is separate from the collision padding, and is only responsible for shrinking the shape.  By default, this value is set equal to the padding amount.  In most situations, you'll never need to change those defaults.  However,  it is possible to both shrink the piece inwards first and then outwards again with the collision padding.  It's not clear as to why you would want to do that, but nonetheless the option is here.

• i@bullet_color
  
  This determines the color of the collision geometry.  You can adjust this value by visiting the rbd packed object node and changing the guide geometry color.

• i@bullet_groupconnected
  
  This attribute only works if the Geometry Representation is set to Convex Hull.  When on, it will create multiple collision hulls if you have multiple pieces of disconnected geometry packed into one object.
  
  As an example, let's say you took two separate spheres and packed them into one object.  By default, the solver would understand that as one object because there is only one packed piece.  When the collision hull is created, it will stretch between the two spheres because it sees one packed object. 
  
  However, if you set this attribute = 1, the solver will recognize that there are multiple disconnected objects that are packed into the object.  Then, it will draw two collision hulls for each sphere instead of one.
  
  In practice, I would advise against packing multiple pieces of disconnected geometry into a packed object.  It's usually better to have each separate piece = its own packed object.  However, the option is here in case you'd like to do otherwise.
  
  This attribute can be set manually or by visiting the RBD Packed Object node and toggling "Create Convex Hull per Set of Connected Primitives"

• f@accelmax + f@angaccelmax
  
  Both f@accelmax and f@accelmax are attributes that are designed to dampen the movement of your pieces.  This is most noticeable when the pieces land on the ground.  This does so by limiting the change in the object's speed for both linear and angular velocity. 
  
  It is recommended to set both f@accelmax and f@angaccelmax at the same time if you decide to enable these attributes.  Low values can create jittery pieces.  Additional substeps can help in reducing this jittery behavior. When setting these values, it's usually best to use 2-4 substeps on your solver to prevent jittering.
  
  In practice, these values are difficult to balance properly.  Often, it's easier to control this sort of behavior using the pop speed limit node.  Using one for the overall simulation and another for pieces that fall under the sleeping thresholds tend to produce more controllable results.

• v@force
  
  The v@force attribute affects an object's velocity based on mass.  Pieces with smaller mass will be affected more by v@force values than heavy pieces.  Forces are not limited by a target speed value.  This means that a force will cause pieces to move faster and faster.  It also means that once a force has been applied to the pieces, they will continue moving even if v@force returns to 0,0,0.
  
  Note that v@force is not capable of breaking constraints by default.
  

RBD

General Attributes

• i@active
  
  Toggles between the object being “active.”  Being active means that this will be affected by other objects and forces within the scene. 
  1 = On and 0 = Off

• i@animated
  

  
  This will tell the bullet solver to update an object's position based on transforms that have been created within a sop network.  This will not account for meshes that require new collision shapes because they are being deformed.  This will also not apply transforms that have been made on the obj level.

• i@deforming
  
  This will tell the bullet solver to rebuild collision shapes at each timestep.  For example, if you animated a bend sop on your geometry, that would cause the collision shape to be changed over time due to the changing point positions.  In that case, you would need to set the deforming value = 1 to account for the changing collision shape.  This will also increase your simulation times.

• i@bounce
  
  This describes the elasticity of the object. If two objects of bounce 1.0 collide, they will rebound without losing energy. If two objects of bounce 0.0 collide, they come to an immediate standstill.

• f@friction
  
  This describes the coefficient of friction of the object. 0 = the object is friction-less.  Higher values will introduce more friction. This is used to slow an object down as it collides with another object.  For example, if you have two pieces of cloth colliding against each other, it will take the friction of one multiplied by the friction of the other, multiplied the global static friction on the solver, which will become the static friction for the collision.

• v@v
  
  This is the linear velocity of the object.  Linear velocity descries which way something is moving in x,y,z and it considers this over the span of one second.  So, for example, a velocity of 1,0,0 means, "Move one meter in x from where you are in one second."  Note that linear velocity does not spin objects.  It simply moves them in space.

• v@w
  
  This attribute is used to describe the angular velocity of a packed  piece.  This can be thought of in two parts: 
  
  1. w is a vector describing the rotational axis.  Imagine a toothpick that you spin with your fingers, and that toothpick is stabbing into the centroid of the packed geometry.  The direction of the toothpick is what w describes by specifying a direction that's offset from the centroid position of the packed piece.
  
  2. w also describes how much this imaginary toothpick is being spun with its magnitude.  The further away w is from the centroid of a piece, the faster the toothpick will twirl.  Hence, the faster your packed piece will spin.  This spin rate is in radians per second.  One full spin will = 6.28319 radians, so the magnitude of w needs to be at least that value to spin once per second.

• f@speedmax + f@speedmin
  
  These attributes will establish a minimum and maximum speed that a particle / packed piece can move per second.  "Speed" can also be understood as the magnitude of v@v.  The further velocity is located from the centroid of a point, the faster it will move.   This movement does not account for spinning motion, and it is described in meters per second.

• f@spinmin + f@spinmax
  
  These attributes will establish a minimum and maximum spin speed that a particle and/or packed piece can move.   This is described in radians per second.  One full spin will = 6.28319 radians. 
  For example, if f@spinmin = 6.28, then that says, "the minimum speed of rotation cannot be less than one full turn per second."

• f@computemass
  
  This determines how the f@mass attribute is calculated.  If on (f@computemass=1), it will calculate mass based on f@density and f@volume by multiplying them together.  This is typically how Houdini calculates the mass of an object by default, but you can  turn this off if you'd like to manually specify mass instead.

• f@mass
  
  This describes the mass of an object.  Mass is calculated in kilograms.  Typically, mass is calculated by taking f@density * f@volume.  Doing this allows small pieces to have less mass than larger pieces.  However, you can override this behavior by directly specifying mass with this attribute instead.  Alternatively, you can modify this attribute after the density * volume calculation has been made to control how heavy objects are within your simulation.

• f@density
  
  This attribute is often used to calculate the mass of an object by taking this value * the measured volume.  Measuring density is in kilograms per cubic meter (kg/m^3), and you need this attribute in conjunction with the measured volume of a piece to = mass.  Some users may also use f@density to isolate different materials in their scene.  Concrete, for example, would have a higher density than loose dirt, so using the density attribute could allow you to isolate these materials.

• f@creationtime
  
  This stores the simulation time at which the object was created.  This will be described in seconds rather than frames.  In practice, this is often used to trigger other events or affect older pieces in some kind of way.

• f@inertialtensorstiffness
  
  This is related to rotational stiffness, and acts as a scale factor applied to the inertial tensor.  The inertial tensor is the equivalent of mass, but governing angular velocity rather than velocity. A smaller inertial tensor results in an object that will spin more readily whereas a large value makes it difficult to spin.  In practice, this can be used to control angular velocity (v@w) more easily.  Because angular velocity is described in radians, it's often easier to use this attribute to control how easily things spin around. 
  
  One practical application for this attribute is in controlling quick rotations caused by small rbd pieces.  You could measure all the pieces, then use an attribute remap node to apply a high f@inertialtensorstiffness value to the smaller pieces and lower values for the large pieces.

• i@computecom
  
  This specifies whether the center of mass of the object should be computed automatically from the object’s collision shape.  For example, this attribute may be useful if you're trying to compute the center of mass outside the collision shape. 
  If that's the case, then setting f@computecom = 0 will allow you to adjust where the center of mass is located.  The pivot attribute could then be used to determine the center of mass position.

• f@bullet_angular_sleep_threshold
  
  This is the sleeping threshold for the object’s angular velocity.  Angular velocity controls how something spins.  This is measured in radians.  One full spin will = 6.28319 radians.  So, for example, if this attribute is set to 6.28, then it will become a candidate for sleeping once it's spinning less than one full spin per second.  An object that "sleeps" is an object that is no longer moving and rotating.
  
  In order for an object to sleep, a few things need to happen:
  1.  f@bullet_angular_sleep_threshold and/or f@bullet_linear_sleep_threshold values need to be set.  If both are set, then both thresholds need to be met before an object is a candidate for sleeping.
  2.  The i@bullet_want_deactivate attribute should be = 1.
  3.  The piece must be moving less than the threshold values set for a certain amount of time.  By default, the "Sleeping Time" parameter in the bullet solver / rigid body solver is going to determine how long a piece needs to meet these criteria before they are put to sleep.

• f@bullet_linear_sleep_threshold
  
  This describes the sleeping threshold for the object’s linear velocity (v@v).  An object that "sleeps" is an object that stops moving and rotating.  If an object is moving less fast than what is described by f@bullet_linear_sleep_threshold, then it is allowed to be a candidate for sleeping. Once v@v is less than f@bullet_linear_sleep_threshold, it must remain under the threshold for a certain amount of time before it sleeps.  That "Sleeping Time" is determined by the "Sleeping Time" parameter found in the solver.
  
  For example, if the threshold was set to 1, then once the velocity is traveling less than 1m/sec, it will be a candidate for sleeping.  Then, it must be traveling less than 1m/sec for the duration of the "Sleeping Time" in order to be put to sleep.  Note that this does not affect how a piece spins, however.  That is handled separately by f@bullet_angular_sleep_threshold.
  
  In order for an object to sleep, a few things need to happen:
  1.  f@bullet_angular_sleep_threshold and/or f@bullet_linear_sleep_threshold values need to be set.  If both are set, then both thresholds need to be met before an object is a candidate for sleeping.
  2.  The i@bullet_want_deactivate attribute should be = 1.
  3.  The piece must be moving less than the threshold values set for a certain amount of time.  By default, the "Sleeping Time" parameter in the bullet solver / rigid body solver is going to determine how long a piece needs to meet these criteria before they are put to sleep.

• f@bullet_ignore
  
  Specifies whether the object / geometry should be completely ignored by the Bullet solver.  1 = geometry is ignored and 0 = geometry is not ignored by the bullet solver.  Unlike setting the active attribute to zero, other objects in the simulation will not be able to collide against this object if they are using the bullet solver as well

• i@bullet_add_impact
  
  When this attribute is enabled (set to a value = 1), it tells the bullet solver to record any impacts that occur during the simulation, and this creates Impact / Feedback data.  This will increase simulation time and memory usage, however, it will provide you with other attributes that can be used to accomplish tasks related to RBD impacts.  To get this working, it's best to turn it on using the Bullet tab on the geometry in the dopnet instead of sourcing in this attribute from sop geometry if you are building your dopnet from scratch.

• i@bullet_want_deactivate
  
  This attribute allows / disallows pieces to sleep.  An object that "sleeps" is an object that stops moving or rotating.  Setting this attribute can be useful if you want certain pieces to be considered for sleeping and others to not be considered for sleeping. If this value = 1, then the linear and angular speed thresholds are allowed to be used to activate sleeping.

• i@dead
  
  This specifies whether the object should be deleted during the next solve.  In practice, this can be used to permanently remove pieces that are no longer needed, and that, in turn, can speed up the remaining simulation.  The pop kill node is often used to create this attribute.  However, you can also set this attribute by using wrangles if you'd like.

• i@inheritvelocity
  
  This informs the bullet solver that it should use the v@v and v@w attributes from the sop geometry to compute the initial linear and angular velocities for each piece.  This attribute can be sourced in from sops, or added in by checking on, "Inherit Velocity from Point Velocity" on the rbd packed object node.

• s@name

• s@collisionignore

• v@scale

• i@nextid

• i@id

• 4@restxform

• i@found_overlap

• s@stickycollisionignore

• f@minstickycollisionimpulse

• i@maxstickycollisionobjects

• i@numstickycollisionobjects

• i@maxstickycollisionpoints

• v@targetw

• f@deactivation_time

• i@bullet_sleeping

• i@bullet_autofit_valid

• v@torque

• v@targetv

• f@spinresist

• p@orient
  

• v@pivot

• i@bullet_adjust_geometry

• i@bullet_color

• i@bullet_deactivated_color

• i@bullet_autofit

• f@bullet_collision_margin

• s@bullet_georep
  

• i@bullet_groupconnected

• f@bullet_length

• v@bullet_primR

• v@bullet_primS

• v@bullet_primT
  

• f@bullet_radius
  

• f@bullet_shrink_amount
  

• s@activationignore
  

• s@activationxformgroup
  

• s@collisiongroup
  

• f@min_activation_impulse
  

• f@accelmax
  

• f@angaccelmax
  

• f@airresist
  

• f@drag
  

• f@dragexp
  

• v@force