Summary:

    The key to understanding the DOP import is understanding the purpose behind each import style.  The DOP import can simply import geometry from DOPs, and it can also apply transform data found in dops to things in sops.  Also remember that in DOPs, your geometry is stored within your "objects" (ex: static objects, rbd objects, cloth objects, etc...)  Because of this, the DOP Import is looking for those objects to fetch information.  Also remember that when typing expressions in the object mask -  "*" = "everything" ... "!" = "except" ... and "*foo*" = "find anything with the name 'foo' in it." 

Main Parameters:


DOP Network:

-- The DOP network to use

Object Mask:

--  Which objects in dops would you like this node to import information from?  

Use Single Object:

--  The DOP import node will try to transform sop geometry that's connected to it.  If "Use Single Object" is turned off, then it will try to match primitive groups in sops to primitive groups found in dops.  If it finds a match between groups, then it knows how to associate objects in sops with objects in dops.  
    If "Use Single Object" is turned on, however, then it will not try to match things based on primitive groups.  Instead, it just looks at the first object it finds in the object mask and uses that transform for all the connected geometry.  In truth, this parameter is unnecessary, and I would recommend just typing in the object name if you only want to read one transform from something in DOPs.  

Import Style:

Transform Input Geometry:

--  This setting will try to transform sop data that's connected to the Dop Import node.  In order for this to work, you'll need something to associate the dop objects with the corresponding sop objects.  There's two main ways of doing this:  One way is by using primitive groups (see "Use Single Object" parameter above), and the other way of doing this is through the @name attribute.  NOTE:  You must check off "Import By Name" if you intend on using primitive groups. 

    Also keep in mind, that the name attribute needs to be a primitive attribute!  This will not work if the name is set to a point attribute.

    What's really cool about this import style is that it makes it possible to simulate with low res geometry while applying it's transform data to high resolution geometry.  Because it uses either the primitive group or @name, it allows you to speed up your simulation with low res, while applying the transform data to high res.

Fetch Geometry from DOP Network:

--  If you use Fetch Geometry from DOP Network, then the DOP Import node will ignore anything that's connected to it.  In this situation, it will simply just import all the information found inside the dop objects.

Fetch Packed Geometry from DOP Network (depreciated):

--  Do not use this parameter because it is depreciated.

Fetch Unpacked Geometry from DOP Network:

--  Don't know what "packed" geometry is?  Then check out Destruction I where I cover this topic in detail.  According to the docs:
    **  "Pulls geometry from the DOP Network, ignoring any SOP that may be connected to its input. For an RBD Packed Object, the unpacked collision geometry will be returned."  Based on that definition, this will unpack any packed geometry that's being used in DOPs by a RBD Packed Object node. **
    ** For more information on why packed objects are used in RBD simulations, check out Destruction I

Stamp Input Geometry:

--  In general, I would advise against using this import style unless you find some sort of reason that makes it necessary.  This parameter is poorly explained and I have yet to find great resources which demonstrate it's use and functionality.  If you happen to find something that offers a better explanation, please contact me, and I will be happy to update this section with a better explanation. 

    What this parameter is trying to do is this:  Suppose you have multiple objects in your dop simulation that have the same object name (which is, generally speaking, a very bad way of working).  What happens when the dop import tries to associate the object name with the primitive groups in sops?  It doesn't know what to do.  So, to fix this potential issue, the Stamp Input Geometry creates copies of primitive groups (found in dops) from the SOP connected to its input, and it gives you the option to associate geometry based on something called an "Object Id."  An "Object Id" is unique to each object in the dop network - even if they are named the same thing. 
    You'll notice that if you set this to Object Id, the dop import node will try associating things based on primitive groups that have been renamed to "objectid_(1,2,3,4,etc..)"  With this new object ID, you are then able to get around the problem of naming two objects the same thing... but in truth, you're better off just not naming dop objects the same thing in the first place, and matching an object id to the proper mesh in sops is problematic.

Create Points to Represent Objects

--  This import style is ideal when importing packed, fractured geometry, and you can find a demonstration of this technique by visiting Destruction I.  Be sure to fast-forward the lesson to about the 8 minute mark.  The intention here is that you are creating points which represent each object in your simulation.  This then gets copied over along with your high resolution geometry, and the transform is controlled by the attributes on those points.  This process is typically achieved through the transform pieces sop. 
    The great thing about using points like this is that it makes your cached files very light and also makes it easier for you to calculate sub-frame data on cached points when using this with a time warp node.  For these reasons, the Create Points to Represent Objects setting is my recommended setting for importing RBD data.  Just don't forget to transfer any attributes or groups that you would like to be associated with these points as well in the "transfer attribute" and "transfer groups" parameters below.