Okey, so as planned I cut the memory consumption of the solver by almost half so much bigger explosions can be done with just the GPU.
However still you can use regular RAM with the GPU computing for something even larger but it will be much slower.
So for 650 resolution the consumption looks like this:
Normal solver:
9,3GB; 0.04sec
Half solver:
5,6GB; 0.04sec
*1000 resolution takes around 19,3GB
I’m working now on finishing the new “real-time” render engine. At this point I’m focusing more on the realism and the optimisation part will come later. For now it’s somewhere in the middle.
For animation below I’ve rendered it in 4K resolution and it took around 0.6sec/frame. For Cycles it was around 3.2min/frame for the same exact scene. In lower resolutions it is much faster though.
Basicly Jflow is the remplacent of mentaflow ?
It was made because Mantaflow is a bit slow and has weird behavior sometimes. Also the main goal is to support all funcionality that it has and if possible give better overall results in much shorter time.
At this time it also supports only Gas simulation (The liquid simulator is also during development, some screens were above but it’s very early).
So it may be a replacement when it’s better, but the decision is not mine.
I’m starting working on forces. The first one is a wind kernel. Still work in progress but the results are promising.
Simulation and rendering made entirely with JFlow.
Resolution: 1000
Sim time: ~0.8sec/frame
Rendering: ~0.46sec/frame in 4K
Nice!
BTW, when uploading a demo, can you add the memory usage to the technical info? I think It’s almost always relevant and practical.
Keep up the great work!
Oh, yeah, that’s a valid point. I will do it in the next ones. I just totaly forgot about it.
Thanks for mentioning that 
And test tornado simulation. For now the effect has been made with blender particle system, which I imported into JFlow, but later I want to add swirl force into the simulator itself.
Resolution: 900
Rendering: ~1sec/frame 4K
Simulation: ~0.7sec/frame
Memory: 6,6GB
Are there plans to make forces procedural, rather than discrete, defined for empty?
Hmm. For now there are few global forces defined for the entire domain like drag, turbulance, wind, wavelet noise, etc. which are based on procedural noises (mostly curl and perlin) and user can modify its parameters to his liking.
Later I thought about adding discrete forces attached to a point so the user can move them for some more creative control.
But overall I want to make this solver node based so finally the user will be able to define his own forces.
Hope it explained your question 
So after making a lot of internal changes I wanted to compare how far I’ve gone in last month in terms of speed and quality using similar setup.
P.S. New thing added yesterday was wavelet noise masking for more control over detail enchancement.
I am so thrilled how you progress with your project !!! And i appreciate that you intend to make it free. I really hope it will be considered for implementation in blender. It just looks stunning. I am really into blowing stuff up in CG and i played with mantaflow for quite some time, but gave up, because it is just so timeconsuming. Really looking forward to have fun with it once its done. Thanks again for your effort !
I’m trying my best. Blender integration in form of an addon or natively is from my side totally open and I’m willing to do it myself in the future if needed.
And about Mantaflow - today I’m making a little comparison between solvers and to be honest Mantaflow is quite difficult for me to work with, especially when I have my own solver and the results were not 100% the same, but the scene preparation and settings were matched roughly and these are the results:
Mantaflow
~80sec/frame
34GB RAM
330^3 Res
JFlow GPU
~0.17sec/frame
1,3GB VRAM
330^3 Res
JFlow CPU
~50sec/frame
1.7GB RAM
330^3 Res
So as you can see Mantaflow has a big memory consumption problem as my simulator uses just 1.7GB constant for this scene while Mantaflow peaked at 34GB during the simulation. Also it is much slower even on the CPU, which is weird as JFlow is not like super optimized for this device. So a lot of interesting data
My guy, do you have a patreon or something that I can help support you on?
I’d love to see this continue improving and if a little bit of cash your direction would help that I’d love to contribute.
Does your simulator have sparse volumes?
Not yet. It will have at some point but I have not figured it out at this moment. But it is still capable of high res simulations due to good memory management.
Little comparison of same setup for Houdini 19 vs JFlow.
Looking at the data JFlow is both faster and much more memory friendly. I’m not sure however if the results are good enough so you can tell in comments.
Houdini
0.1 voxel size
20,5GB VRAM
1.0sec/frame
JFlow
0.1 voxel size
1.8GB VRAM
0.7sec/frame
Can’t wait to see this maybe go to master! Hope it does!
It seems to me that Houdini has a high viscosity in vortex flows. As far as I know, there are special versions for the Navier Stokes solutions that take into account the vortex exponents
It seems so. I’ve also played later with the JFlow settings and made more similar looking flow, however there is also a problem with the method of sampling particle emitter as houdini internally has a lot more data than my JFlow importer. Especially subsampling, which I have to cheat a little bit. But overall it’ll get better with the time.
There is also a huge memory advantage, as with Houdini this was the maximum resolution of the domain with an RTX3090 and with JFlow I can go much higher as it barely used VRAM at all and even if filled it could still expand it using regular RAM so there is technically no limit to the sim resolution.