VDB_CacheLoader frame offset is inverted

  • Eddy version: 1.6.1
  • Nuke version: 10.5v5
  • Operating system: Centos 7
  • GPU model: GTX 1080TI
  • Graphics driver version:384.59
  • Is the bug reproducible? yes
  • Steps to reproduce the bug: use frame offset in VDB_Cache
    The frame offset parameter behaves opposite to what is expected, that is a negative number will shift the cache later in time when.
    E.g. -10 Will make the cache start 10 frames later rather earlier. In Nuke’s TimeOffset node the logic is that you are applying the specified number to the start frame, so a negative n umber will make an element start sooner.

Also, if possible, it would be great to be able to see the VDB_Cache node in the Dope Sheet.

For the VDB_Cache node in DopeSheet, do you mean to show which frames are cached to disk? just curious.

I just mean for the Cache node should show in the dope sheet like a Read node does (since it is a Read node for vdb caches). This would show you what the frame offset parameter actually does and, ideally, you would be able to drag the node around in the dope sheet to drive the frame offset interactively (like a Read node does).
Not sure if this sort of thing is accessible via the NDK but if it is it would be a helpful addition.

1 Like

Hi Frank,

Since this is a fairly new addition, we can probably invert this logic on newer builds. It should behave like nukes node. The logic on the current version is that the frame offset is applied to the current frame. The result is the frame we load. So if current frame is 10 and you offset by -10, you have 10 + -10 = 0. So the cache would be delayed 10 frames effectively.

–Ronnie

Thanks Ronnie. In Nuke the logic uses the target frame, not the source frame. So -10 will map the source frame to the target frame - 10, therefore making it start earlier.
Is it possible to expose the Cache reader in the dope sheet? That would make it nice and obvious.

Assuming it’s possible, I’m going to re-implement the cache reader and writer nodes as FileOps. This would provide the standard interface as other IO ops and would also support the dopesheet. So I may leave these nodes exactly as they are and deprecate them when the new ones are available.

Sound good?

1 Like

That would be great, yes.

FYI - I was just having a look at the built-in IO nodes and noticed the ReadGeo and WriteGeo nodes don’t present the full frame range options the image based nodes provide. They also don’t appear in the dopesheet.

Correct. One of those sloppy inconsistencies that drive me nuts in Nuke.
Maybe have a look at the TimeClip node, that one provides retiming features while being visible in the dope sheet.