Thanks. Emm I would love to but if I understand correctly how it works I would have to actually implement it into blender during that time and I don’t think it’ll be ready enough at that point.
I mean there are a lot of things still missing and I don’t really consider myself a good programmer so the expectations would be high and the possible outcome may be dissapointing for some.
So if it would be an option I would like to try but I’m not sure I’m ready for such pression for getting it done 
@michal1000w would it be an option for you to maybe look into potential OpenVDB optimizations in Blender? I am sure that after a few patches make it in, it would be possible to request a grant to continue with the simulation experiments, since your stuff is pretty much the only thing happening around blender and simulations nowadays. The interest from both devs and users would be through the roof!
Does Blender perform slow / crash with VDB in the viewport or is it a Cycle’s specific problem?
I could try with viewport preview at the beginning as it is very laggy with higher resolution files, however it may require a lot of time, which at this point I just does not have. But some time in the future why not.
The viewport at 900^3 resolution is almost unusable due to terrible performance, however it works fine in terms of stability.
The problem is with Cycles (constant crashes and weird errors) (I’m rendering on the GPUs so I don’t know if it also is a problem with the CPU compute or just GPU)
Especially weird were the errors about lack of memory when at the peak it used about 4GB and I have 24GB on each card.
During creation of this sample scene I’ve made some huge improvements in JFlow’s internal particle simulation system, such as:
非常酷！非常酷！
Very cool!
Very cool!
It’s very very cool. Imho, the simulation lacks a bit a vorticity. I do not know if your method allow it, but at every animation you make, I notice that.
Good work still 
Hmm, first of all thanks for the critique, sometimes during the work I can forget about some important features like for example vorticity, so every feedback is welcome as it can speed up the creation process.
For now I work in a way where I have an idea for a scene. Then I look what features do I need to make it possible, I implement them, and later the whole scene is made in like maximum 30 minutes (including baking and exporting times). So that also may be the problem with the low quality of these sims.
Anyway, I think I’ve created this solver to be quite flexible in terms of features addition so it should be possible to add the vorticity kernel without any massive changes to the core. And as today I have some boring lectures I could try to implement it, however I don’t have a GPU on my laptop so I won’t be able to compile and test it during this time; but if everything will go fine the first draft should be ready by tomorrow.
I’m following your progress and from the numbers you are giving it looks very nice (performance-wise).
But I also want to second @Kdaf point about vorticity. If you look closer to most of your sims the noise pattern is very uniform across the volume. Vorticity helps with breaking it to more realistic sizes so there are some local variation to it. Aside from vorticity maybe its worth checking how to make noise size adaptable to some other conditions.
Last thing is that sometimes it looks like noise pattern stays in place and is not following the direction of the smoke. It’s subtle, but its there. This also can break the immersion.
Just a note that Mantaflow suffers from the same issues, so I assume they are inherent to smoke sims in general not only your implementation.
And as always - keep up the good work.
Yeah, that’s a good point. I definitely want to work on this, the only problem is that I have very limited time to work on this and I’m not the sharpest tool in the shed. This solver also was not made to compete with some state of the art solvers found in Houd*** and EmberG** (as they are developed by a group of much better programmers than me and also these solvers are much more mature) but as a suplement to Mantaflow or step-up in quality from the older JFlow solver.
In terms of noise following the direction of smoke it is there (at least in theory), as I use perlin noise with some simple evaluation to follow the smoke, and curl noise for the additional turbulance in the entire domain. So it may be my fault with the simulation settings (I did not perfect them yet) or a bug in the kernel. I have plans to add wavelet noise to enhance the randomness even more alongside the vorticity kernel. So hopefully it will be better soon.
But in summary current results looks ok (for me) compared to old solver and maybe mantaflow but when I look on some other solvers than my looks like crap in comparison and I kinda wanna quit from this project and start growing tomatoes.
So there is a chance that the results could be good with this solver some time in the future, but I think that they will be acceptable about 2 new solvers in the future (if ever)
Keep going at it! Every iteration is better 
So I’ve added vorticity kernel, as well as additional wavelet noise. So now it’s a case of finding the best parameters, as there are pelin and curl noises for small detail in fire and smoke and wavelet noise for handling larger plumes. In the simulation below I’ve tweaked fast some of the parameters so hopefully it looks better
That looks so amazing! 
I look forward to being able to use this on a project someday!
Thanks, I will release the early demo for testing when I finish the GUI. It however takes a bit longer as this time not only I want to make it look and behave more mature but also I’m working on the node system for scene creation so it will be a little bit more advanced than the previous version.
Inspired by some Houd*** renders I’m trying to create a more “realistic” explosion shader. For now these are the results I came up with. It contains 2 shader groups mixed with a light path info node and each group has 2 different fire shaders and a density shader. When I’m happy with the results I can ship JFlow with a sample blender file.
For now the main drawback of this shader is the rendering speeds. As for this frame in 4K resolution it took almost 3 minutes on 3x RTX3090. The results though looks a lot better than the previous shader and require almost no post-production (in the example below I just added the background and a little bit more contrast, when on previous animations I had a huge node tree in DaVin** Resol**).
That’s awesome !! Thank you so much for taking the feedback into consideration, really appreciate.
I have to find some free time to help you about Blender integration. This project absolutely needs more attention !
There is the final render
All I can say to this is wow! The previous simulations you’ve posted have all been incredible, but that one is just next level! I find it quite hard to imagine making something similar in Blender currently. How long did it take to simulate?
This one should be possible, as in JFlow it took only 0.114sec/frame to simulate (the domain was honestly just 400^3). After implementing new noise methods and combining them with previous techniques it just requires less resolution to look more detailed (previous sims were much higher res).
Also the new shader enhances it even more.
So mantaflow could do that, however it may take few hours per attempt and to make it in the final form I made about 5-6 trials so the speed of the new workflow just made it much easier and allowed for more tweaks in the same time.
