Page MenuHome

OpenVDB cache doesn't support unicode characters in filename
Open, Confirmed, MediumPublic


System Information
Windows 8.1 x64, nVidia 740M

Blender Version
Broken: 2.79
Worked: None that I can remember (since v 2.72)

Short description of error
Simulation cache disappears without a reason

Exact steps for others to reproduce the error
Simply make a Quick Smoke simulation.
Then play a bit with the frames (move forward and backwards) - you already should have lost your cache.
Let's say you were lucky and you did NOT: Start rendering say 5 frames and stop.
Come one day after and try to start from frame #6... You simply can't.



Event Timeline

ronan ducluzeau (zeauro) closed this task as Invalid.
ronan ducluzeau (zeauro) claimed this task.

User have to save .blend file, name cache and press Bake button or Current Cache to Bake under Smoke Cache panel in order to protect cache.
This behavior is common to most of Physics simulations.

This is a general support issue and not a software error we can investigate.

For general issues, check on support sites such as:

You're obviously kidding me.
I tried the "Current Cache to Bake" way, to no avail.

And NO. With or without a name (absurd that it hasn't a default one), it does NOT work.
And OF COURSE, I already tried "Bake button" AND "Current Cache to Bake", to no avail.

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedOct 25 2017, 6:31 PM

I was unable to reproduce the problem with this file:

Open "quick_smoke.blend" file. Press "Bake" button. You save the file again (File > Save). Close Blender. You open the "quick_smoke.blend" file again. Baked simulation will remain there as long as you do not delete the folder named "blendcache_quick_smoke" that had been created on the same path where you saved .blend file.

Kubuntu Linux 64 bits.

There is no such a file.
Thank you for having fun at me.

If I press "Bake" in my file, and then close and reopen it, I don't have it working anymore.
And there is no "blendcache_quick_smoke" folder in my path.

So, in the end, I had to give up.
Because Blender actually sucks at simulations!!.

Thank you for closing this B-U-G.
But it's your expected behaviour, after all.

I'm used to that.

  1. I'm pretty sure we talked to you about your temper/language use before [edit: i just see you removed the curse words aimed at the people trying to help you]
  2. Multiple people have taken the time to try to reproduce your issue and failed, one of them even posted a sample file of their own for you to try (which you seem to have given no feedback on) If you are having problem with a specific file, please attach it.

Unless we can reproduce the issue ourselves, we can't fix it.

LazyDodo (LazyDodo) reopened this task as Open.Oct 25 2017, 10:58 PM
LazyDodo (LazyDodo) triaged this task as Needs Information from User priority.

"... people trying to help you" - well, I found NO HELP at all.

I mean, it's 24 hours I'm trying everything: Free Bake, Bake, Alt+A, Current Cache to Bake, change from Open VDB to BPhys...

Alt+A produces a nice animation, but when I hit ESC, and move to desired frame, it disappears.
No matter if I hit Current Cache to Bake.
Same if I Free All bakes and then Bake again.

Now only BPhys seems to write on disk (yesterday, on a different file, I was able to save VDB files) - And I don't want it (too large files).

Yesterday I was going to prepare a DEMO blend file to post it here and show the error.
So I removed all the extra meshes.
Guess what? THAT only file works. But it's USELESS, without the other actors.

Then I thought I could copy the cahe files (VDB!!) to the actual file I'm STILL TRYING to work on.
Fails to load.
But the cache "Name" is the very same!!

I'm really demotivated.

My last attempt would be to re-import the other meshes to the "demo" file.

  • If it does (supposedly) no longer work, then it would mean that only the Domain and Emitter are alowed - no other mesh.

This could make some sense (not really, but has some kind of perverse logic - which I'm used to, in Blender, like the Right and Left sides "swapped").

  • If it works... Then I'll jump to the ceiling, happy.

But I'd forever remain with a question: "WHY would THIS ONE work and the other one would not?"


The second works - MYSTERY!!!!

But there must be something wrong which should be further investigated: I mean, if you play a bit with a simulation (change file format, Free bakes, re-cache, copy to bake, and all these stuff), you'll end up with a destroyed file.

And this is no good.

Why does the VDB files NEVER get recreated (only PointCache files get created) is a big mystery.

You'll have to post exact steps on how to reproduce the problem otherwise there is nothing we can do.

You're all over the place, at this point i'm not even sure what the issue is anymore.

here's your options

  1. Post a file that exhibits the issue
  1. Post an exact step by step guide on how to reproduce the issue (and this can't be, hey if you mess about for a bit and do some random things, things break)

if you can't do either of these things, there is nothing to investigate for us and i'll be required to close the ticket.

I was trying to replicate the error on a demo file (stripped out the other meshes and gave it a different name) - it works!
Now, given that the other meshes aren't the cuprits, the culprit is... UNICODE CHARACTERS in the file name.

The original file name (not working) contains the character à.
I highly suspect this is the culprit.

Somehow, the cache files generation for VDB files (bhys files DO WORK) doesn't like UNICODE.

Arto Kitula (akitula) renamed this task from Smoke simulation cache gets lost to OpenVDB cache doesn't support unicode characters in filename.Oct 27 2017, 1:28 PM

I think now we have correct name for this ticket.

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Confirmed, Medium.

Did a quick check here on linux (which is utf-8 unicode system since… ages), with non-ascii chars in file name, and it works perfectly well.

So as expected, it’s not that VDB does not supports utf-8, it’s that VDB does not handle correctly conversion between utf-8 unicode and stupid 8bit encoding of Windows… Remains to wee whether missing conversion is in Blender side of things, or in the library itself.