Cannot load empty VDB file, VDB frame held

[Italic_]

I have a sequence of VDBs in my current project from my blender smoke cache, the first of which starts on frame 108 of my Octane project. However, Octane refuses to load the first VDB in the sequence. I'm assuming the file is empty, because the scene has no smoke in it and the file itself is only 4kB on the disk (compared to frame 109 at 160 kB). This isn't inherently bad, but it becomes problematic when I start the VDB sequence in the middle of the project; if I load the sequence starting with frame 109, it then holds frame 109's VDB file until frame 110 (every frame < 109 displays 109's VDB). This is problematic because there shouldn't be any smoke in the scene before 109. To compound this, emissions are also enabled for all those previous frames. I think it's Octane's problem reading the VDB because I can open the same VDB sequence in Maya and it scrubs through from beginning to end. I can't change the looping method in the VDB sequence window because I don't want it to loop or ping-pong.

Currently my solution is to separate the VDB into its own renderlayer, invert the layer and enable visibility only. I can render from 0-108 with the renderlayer enabled, then disable for the rest of the sequence. While ultimately it isn't much of a roadblock, the process is more involved and manual than it needs to be, requiring multiple batch renders to output everything.

Attached is a snippet of the VDB sequence and an ABC camera export.

So now my questions are:

• Is this a known problem?
• Is this a problem in the first place or is it intended to work like this?
• Is this a problem with Octane reading the VDB or is it blender's fault for exporting a faulty VDB?
• If this is blender's fault, can anyone more experienced with VDB caching guide me?
• If possible, how can I fix this one file to load?

In my opinion, the sequence should start on the specified frame and only on that frame, not held until the second VDB loads. It makes sense to hold a VDB for the whole project if it's a singular file and animation is disabled, but not when it's explicitly turned into a sequence. If holding is desired, the user could check a box for "hold before" and "hold after."

I will attach a sample movie file when it finishes rendering to illustrate my problem.

EDIT: Here is the render:

held_VDB.mov

(676.87 KiB) Downloaded 3189 times

[haze]

Hi Italic, thanks for the post, I will check this out, it doesn't look like correct behaviour from Octane. It doesn't seem that the VDB itself would be the problem, rather, it would appear Octane is selecting the wrong VDB for a particular frame

[Italic_]

Hi Haze. I noticed that behavior, too.

If I start rendering on frames before the start of the sequence (say, frame 100) it renders the second frame (the first non-empty frame) until the next frame is called and continues through the sequence normally. But when I start rendering on the frame at the start of the sequence (frame 108 in this case), it will render some completely different frame, then continue through the sequence properly.

And just to make sure I'm being absolutely 100% clear of what my problem is, my next post will be an exact series of steps to reproduce the behavior in a video and screenshots. I feel I didn't communicate it very clearly in my original post.

Thanks Haze!

[Italic_]

It looks to me like Octane loads the frame that is currently in memory for the empty VDB. If I scrub the timeline quickly, it will use the last loaded frame for the empty frame and all before it (this frame will change depending on how quickly I scrub).



Load the first VDB in the sequence:

load1.png (48.26 KiB) Viewed 3262 times

and this error occurs:

Load second VDB in the sequence:

load2.png (47.59 KiB) Viewed 3262 times

The file loads. Turn it into a sequence with all the VDBs:

load_sequence.png (58.35 KiB) Viewed 3262 times

Frames before sequence start display incorrect VDB:

Frames after sequence start display correct VDB:

[haze]

Thanks for the info - I've just made the change so that empty volumes are not discarded anymore, so this should at least make the issue a bit more workable.

Currently, setting time to anything less than 100 for a volume animation sequence that start at time 100, Octane will render the first volume in the sequence - this is a similar limitation from other types of animation sequences in Octane (and why there are no start times for any of those). At the moment the only workaround would be to always start the sequence of volumes with an empty volume when setting a non-zero start time (which will be possible from the next release)

I have a feeling it might be more practical if Blender exports all the VDBs including the first 107 that are empty, and feeding these directly into Octane (from its next release)?

[grimm]

Yep, the first frame of the simulation will always be empty in Blender. Why don't you load the sequence without the first frame? That has worked for me when I was testing it. Or if you need the simulation to start on that frame, push the simulation one frame back, if possible.

[Italic_]

Yep, the first frame of the simulation will always be empty in Blender. Why don't you load the sequence without the first frame? That has worked for me when I was testing it. Or if you need the simulation to start on that frame, push the simulation one frame back, if possible.

Offsetting the sequence by one frame keeps it in time, but then the frames before the start frame display a volume when there shouldn't be one. In the video demo in my previous post, you can see me scrubbing before the first frame of the VDB sequence, but it was still displaying the first frame of the sequence.

[Italic_]

Currently, setting time to anything less than 100 for a volume animation sequence that start at time 100, Octane will render the first volume in the sequence - this is a similar limitation from other types of animation sequences in Octane (and why there are no start times for any of those). At the moment the only workaround would be to always start the sequence of volumes with an empty volume when setting a non-zero start time (which will be possible from the next release)

I have a feeling it might be more practical if Blender exports all the VDBs including the first 107 that are empty, and feeding these directly into Octane (from its next release)?

Assuming Octane doesn't throw away empty VDBs, it would be trivial to duplicate the empty first frame through the beginning of the scene. If it didn't throw away empty VDBs, this wouldn't be a problem at all, so thank you for fixing that. I look forward to the next release.