I'm finally able to jump in Houdini 16, and I've got a few questions about Packed Disk Sequences. They seem like they'd be a huge help, but the documentation is a little sparse.

1) Packed Disk Sequence primitives have an intrinsic attribute called “wrap” that defaults to “cycle”. Are there other options available? Or would I have to mess with the “index” intrinsic to clamp, ping-pong or ignore the file read?

2) Do Packed Disk Sequences work with sub-frames? Or are they linearly blending whole numbered frames?

3) What's the relationship between the “Geo Time Samples” and “Packed Sequence Segments” render properties? I've seen that I can only get motion blur when “Geo Time Samples” is 2 or higher, and “Packed Sequence Segments” defaults to 4. Is “Packed Sequence Segments” a limit on “Geo Time Samples” or is there something else going on?

1) The modes are “clamp”, “cycle”, and “strict”. This code may be relatively untested, so if you do find something wrong, please submit a bug. I'll try to make sure the documentation is updated.

Edit:

• clamp: Geometry exists, but the sample index is clamped between 0 and $N
  
• cycle: The sample index wraps using modulo
  
• strict: If the index is outside the valid range, no geometry is unpacked
  

2) Packed Disk Sequences will interpolate sub-frame geometry in a similar fashion to the blend SOP. Currently, blending between keys is linear. The key geometry is integer based.

Interpolation of the key frames is renderer dependent. The viewport turns blending off. Mantra quantizes the sub-frame index into N distinct sub-steps based on the vm_packsequence_substeps object property. So, if you have a packed disk sequence with 10 segments, and instance it randomly through time 1,000,000 times, but have a maximum substeps of 4, you should only end up with 40 unique geometries being instanced.

3) A packed disk sequence has two pieces of data. a) The list of filenames, b) The time being sampled (i.e. index - which doesn't have to be an integer). When asked to render, the primitive will compute the geometry at the sample time.

When “Geo Time Samples” is set to 2, there will be 2 separate packed disk sequence primitives sent down based on the shutter time. These two primitives will have different time indices, and the geometry will be blended in mantra between those two pieces of geometry.

So, for a single packed disk sequence with 10 key frames, you might end up with key frame 1 and key frame 4. With 4 “Geo Time Samples”, mantra would blend between key 1, 2, 3 and 4.

The “Packed Sequence Segments” is what I alluded to in question 2. To save on memory, mantra will “quantize” time steps. So, if you had 10 packed disk sequence primitives that shared the same geometry, but had indices of: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, this would normally result in 10 unique pieces of geometry. A quantization of 4 time steps would quantize time into four time steps: 1.0, 1.0, 1.25, 1.25, 1.5, 1.5, 1.5, 1.75, 1.75, 2.0

So, it's not 100% accurate, but you can have considerable memory savings since there's automatic instancing of the geometry based on the same sample time. That is, instead of 10 unique pieces of geometry, you'd have 5.

Hope this clarifies things.

The Blend SOP supports spherical blending of transforms for packed primitives. Will the packed disk sequence perform similar blending of rotation matrices when the file contains packed primitives?

Mark, that makes a lot of sense! Thanks for the thorough explanation!

jsmack
The Blend SOP supports spherical blending of transforms for packed primitives. Will the packed disk sequence perform similar blending of rotation matrices when the file contains packed primitives?

Transforms on primitives are blended using slerp. There's also special case blending for some primitives (including Agents).

So how does PDS deal with subframe caches on disk?
Think of a bat that beats its wings about 17 times a second. I would want to cache the file in 1/8 frame increments. Can PDS deal with this? At the moment it only seems to want to pull in the $F file name, not any of the subframes saved using $FF in the file name.

So im building my own code to handle subframes and the index. All is going well but seems the python code errors:


returning this error:


Using setattrib in Vex is a workaround, but seems like this is a bug in python?

JordanWalsh
…So im building my own code to handle subframes and the index …

before you go into the lengths of building your own code, can't you just use Alembic? It can automatically interpolate among samples and the samples don't have to be on integer frames
- just keep it as PackedAlembic and change abcframe intrinsic per copy (which despite of the name is in seconds)
- to loop you will have to mod the time yourself, but that's a small price to pay compared to managing indices for subframes