OpenVDB cache files have extra "_00" at end. #47655

Closed
opened 2016-03-02 10:12:49 +01:00 by Galen Beals · 31 comments

System Information
MacBook Pro (15-inch, Mid 2009)
Processor: 2.8 GHz Intel Core 2 Duo
Memory: 4 GB 1067 MHz DDR3
Graphics: NVIDIA GeForce 9600/9400M 256 MB

Blender Version
2.77 RC
date: 2016-02-26 12:32
Hash: b594b25
Branch: Head

Short description of error
When Smoke cache files are written, there is an extra "_00" at the end, just before the extension. So a files are usually called something like, SmokeCache_000010_00.vdb. Up till now this hasn't been a problem. But when using OpenVDB, it causes many problems when trying to load them into other programs. At this point you must manually rename the files by hand in order to get them to load. I have tested this with Modo and Vray in 3DSMax.

Exact steps for others to reproduce the error
No need for steps. It's Pretty obvious.

**System Information** MacBook Pro (15-inch, Mid 2009) Processor: 2.8 GHz Intel Core 2 Duo Memory: 4 GB 1067 MHz DDR3 Graphics: NVIDIA GeForce 9600/9400M 256 MB **Blender Version** 2.77 RC date: 2016-02-26 12:32 Hash: b594b25 Branch: Head **Short description of error** When Smoke cache files are written, there is an extra "_00" at the end, just before the extension. So a files are usually called something like, SmokeCache_000010_00.vdb. Up till now this hasn't been a problem. But when using OpenVDB, it causes many problems when trying to load them into other programs. At this point you must manually rename the files by hand in order to get them to load. I have tested this with Modo and Vray in 3DSMax. **Exact steps for others to reproduce the error** No need for steps. It's Pretty obvious.
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @galenbeals

Added subscriber: @galenbeals

#55151 was marked as duplicate of this issue

#55151 was marked as duplicate of this issue

Added subscriber: @kevindietrich

Added subscriber: @kevindietrich

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Kévin Dietrich self-assigned this 2016-03-02 11:07:17 +01:00

This is not a bug but the way file names are generated by the point cache system. The "_00" is actually the index of the cache, so you can also have "_01", "_02", etc... It's annoying indeed, but changing that would require a complete rewrite of the overall cache system, which is kinda planned for Blender 2.8.

This is not a bug but the way file names are generated by the point cache system. The "_00" is actually the index of the cache, so you can also have "_01", "_02", etc... It's annoying indeed, but changing that would require a complete rewrite of the overall cache system, which is kinda planned for Blender 2.8.
Author

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.

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.

Added subscriber: @ErickNyanduKabongo

Added subscriber: @ErickNyanduKabongo

"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

"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
Member

Added subscriber: @Ton

Added subscriber: @Ton
Member

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.

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 (#37578), 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 .), 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 @galenbeals'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.
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 (#37578), 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 @galenbeals'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.
Author

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.

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.

Added subscribers: @Rawalanche, @lichtwerk, @brecht, @dr.sybren

Added subscribers: @Rawalanche, @lichtwerk, @brecht, @dr.sybren

Added subscriber: @knekke

Added subscriber: @knekke

Changed status from 'Archived' to: 'Open'

Changed status from 'Archived' to: 'Open'

In #47655#361499, @kevindietrich wrote:
....which is kinda planned for Blender 2.8.

Bumping, because it's annoying me right now....again...
2.8 was mentioned to be a workflow/pipeline release. So please!

> In #47655#361499, @kevindietrich wrote: > ....which is kinda planned for Blender 2.8. Bumping, because it's annoying me right now....again... 2.8 was mentioned to be a workflow/pipeline release. So please!
Contributor

Added subscriber: @ZedDB

Added subscriber: @ZedDB
Contributor

@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".

@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".

@Rawalanche these bugs are not forgotten. If you want to fix this issue, feel free to do so. Patches are welcome

@Rawalanche these bugs are not forgotten. If you want to fix this issue, feel free to do so. Patches are welcome
Contributor

In #47655#632030, @ZedDB wrote:
@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? :)

> In #47655#632030, @ZedDB wrote: > @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? :)

Added subscriber: @MrJoMo

Added subscriber: @MrJoMo

I have also noticed this recently. I simple fix could be to have the index before the frame number. i.e: fileName_index_frameNumber

I have also noticed this recently. I simple fix could be to have the index before the frame number. i.e: fileName_index_frameNumber

Added subscriber: @NiallEarley

Added subscriber: @NiallEarley

This is still an issue and another thing that limit's blender's ability to play nicely with other software.
I get that people don't want to break previous caches from working in newer blender versions, but this strange naming convention is pretty frustrating to deal with. Especially in windows, where batch renaming is a convoluted and tedious process.

Is a fix/change to this possible when the new mantaflow branch is merged? Perhaps it would make the most sense to implement at that point since I'm sure the issue is more complex to solve than it seems to us laymen.

This is still an issue and another thing that limit's blender's ability to play nicely with other software. I get that people don't want to break previous caches from working in newer blender versions, but this strange naming convention is pretty frustrating to deal with. Especially in windows, where batch renaming is a convoluted and tedious process. Is a fix/change to this possible when the new mantaflow branch is merged? Perhaps it would make the most sense to implement at that point since I'm sure the issue is more complex to solve than it seems to us laymen.

Added subscriber: @stephenwongdesign

Added subscriber: @stephenwongdesign

+1 would be great to have it updated in Blender 2.81

+1 would be great to have it updated in Blender 2.81
Kévin Dietrich was unassigned by Dalai Felinto 2019-12-23 16:37:16 +01:00

Added subscriber: @sebbas

Added subscriber: @sebbas

So with Mantaflow smoke simulations this issue should be solvable very easily. Can someone report if there are any issues with the current OpenVDB cache files?

So with Mantaflow smoke simulations this issue should be solvable very easily. Can someone report if there are any issues with the current OpenVDB cache files?

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Sebastián Barschkis self-assigned this 2020-01-22 21:22:47 +01:00

Closing since new OpenVDB cache files (created with Mantaflow) don't have "_00" at the end. Any new issues would go into new report.

Closing since new OpenVDB cache files (created with Mantaflow) don't have "_00" at the end. Any new issues would go into new report.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
13 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#47655
No description provided.