Hi Kévin, I have a lot of respect for you and your work and I don't want to get on your bad side but this really isn't an acceptable answer. What was the point of using OpenVDB if you can't exchange cache files between apps? It certainly isn't a "Better" replacement for the current cacheing system. It actually hinders playback speed. So, if you can't easily use these caches in other applications, what is the point of having it. I know I'm coming off as confrontational but I have waited sooo long to get this feature just to be told, that's the way it's supposed to work. There must be a better solution. I'm on OS X and there's no simple way to batch rename files. In windows it might be simple to "rename" with wild cards in the command line, but in Unix the standard way rename files is with 'mv' which does't handle batches of files. I could write a shell script but is every user going to need to do this if they want to use the files in other programs? Not to mention that renaming the files invalidates them for use in Blender.

Also, while I know I don't understand the intricacies of the cacheing system, wouldn't it be trivial to just swap the order of how it reads and writes the file names; [CacheName]_[FrameNumber]_[Index].vdb to -> [CacheName]_[Index]_[FrameNumber].vdb? I can't imagine that would cause you to have to rewrite the cacheing system.

"What was the point of using OpenVDB if you can't exchange cache files between apps?" cache is using less disc space.
Convert yourself fully to Blender you will be saved. LOL

Galen: when we add new features in Blender we should carefully try to be compatible with other programs. Having OpenVDB files to be exchanged in a mixed pipeline is a logical feature to implement.

What Kevin probably points at is an old convention in Blender for caches. We have to fix that, but it's not trivial. He didn't purposely design it to not work.

Someone mentioned that mac finder now supports batch rename. Select files, RMB menu.

As far as I know some people already managed to get .vdb files out of Blender working in other software (Octane and Houdini, iirc), with the only issue being that the grids are Z-up (but that's not much of a problem). So they are compatible with other software (and I open them in other software too).

Now the only real problem seems to be the file names (though, this is the first time I hear about this issue). Lukas kinda pointed at the problems the way names are generated by the point cache in his Alembic design task (T37578), and the index is pretty much required since you can have multiple caches in the same ID block, so it's not really a convention, more like a design issue. Maybe we could reorder the elements in the name (to <name>_<index>_<frame>.<ext>), but that will automatically break every existing caches, therefore some weird versioning would need to be done. I say "weird" because it's not in the DNA, so not straightforward (or is it?), and might cause some complication as far as as maintenance is concerned.

Now to comment on @Galen Beals (galenb)'s comment:

• the primary goal was smaller cache files, not exchange format, though that can work too.
• it's not a replacement of the current cache system, but an extra file format for the current cache system.
• it hinders on playback because you need to convert between VDB grids and dense buffers (which is single threaded currently).
• FYI, on Linux there is the 'rename' command to do batch renaming.

Ton: thanks, I'll have a look at the finder option.
kévin: thanks, I apriciate you keeping a level head while I lost mine. ;-) I think I understand now. It's more about backward compatibility than anything else. By the way, I understood that the cache files were designed like this before you even worked on it. I was just surprised that there wasn't a solution at this point. Thanks again.

@Sebastian Parborg (zeddb) Hi, I'd just like to make sure this bug has not been forgotten. It's been reported back in 2016, last activity on it was almost 3 months ago and it is assigned to a person who's probably not active anymore, yet the status of this bug is still "Needs triage by developer".

Overall, around 60 bugs currently have the "Needs triage by developer" status. That's not much so it should not take a long to review them. It would be good to look at the list from the bottom and see if any bugs haven't slipped through the cracks. I've seen a few that seem important yet still in a "limbo".

@Ludvik Koutny (rawalanche) these bugs are not forgotten. If you want to fix this issue, feel free to do so. Patches are welcome

In T47655#632030, @Sebastian Parborg (zeddb) wrote:

@Ludvik Koutny (rawalanche) these bugs are not forgotten. If you want to fix this issue, feel free to do so. Patches are welcome

That's not what I meant. My point is - shouldn't it be finally triaged and assigned a priority now that it has its 3rd year anniversary since the report? :)