OpenVDB cache files have extra "_00" at end. #47655
Labels
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
No Assignees
13 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#47655
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Changed status to: 'Open'
Added subscriber: @galenbeals
#55151 was marked as duplicate of this issue
Added subscriber: @kevindietrich
Changed status from 'Open' to: 'Archived'
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.
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
"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
Added subscriber: @Ton
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:
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 subscriber: @knekke
Changed status from 'Archived' to: 'Open'
Bumping, because it's annoying me right now....again...
2.8 was mentioned to be a workflow/pipeline release. So please!
Added subscriber: @ZedDB
@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
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
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
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
+1 would be great to have it updated in Blender 2.81
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?
Changed status from 'Confirmed' to: 'Resolved'
Closing since new OpenVDB cache files (created with Mantaflow) don't have "_00" at the end. Any new issues would go into new report.