Previews and Progress

Yes progress! We are looking good for a beta 0.5 version mid to end of Feb. I have added some preview code and got some nice previs without the long render times that we get with Implicit Objects. As you can see in the screen shot we can also now add obstructions and the like.

However one thing is for sure, with the current setup the implcit objects are just too slow. There are two soluctions, one speed up the implicit object evaluations and make some optimization to the implicit code by assuming a smooth function. I want to do both, but we will have to see how things pan out.

Back from Köln

Yes, we finnaly got out of Veinna for a holiday. Just 3 days and a extra day in Solovakia just to vist the best chocolate shop in the world. So anyway we will be back to work on this today and tommorow.

Boundry condtions

I couldn't sleep last night so I pondered a better way to do boundry condtions. At this point I use the common method of a number of layers of particles attached to the boundry. Unfortunatly this does not really let me import polygon geometry very easily. Or any other type of gemometry for that matter. Another method is reflected particles. Unfortunaly this tends to increase stablity issues with impacting drops since the effective velocity is twice what it should be.

So another way to avoid storing the particles is a "hacked" refelcted boundry particles. Well rather the particles are reflected so that they are on the boundry rather than behind it. Taking this to next simplified step, and the cost of accuracy, we just place a single particle closest to the current particle on the surface, aka perpendicular to the tangent line of the surface. Futher particles can be generated from a stable latice on that surface. Care must be taken at the corners.


Anyway thats not yet implemetened. Here are 2 simulations with differnt thresholds for the surface. Not that one went unstable. I suspect its a threading issue and some particles got updated twice.

Treshold=5
treshold=10 and goes unstable

Art of Illusion

We have started to intergrate the code into art of illusion. If you are like me and havn't heard about AoI then pop over to site. Its a great project and its writen in java which makes intergrating easier than blender. But like all 3d apps its takes getting use to since everything is slightly different. It also has volume rendering which has appeal for smoke effects. And yes I'm still going to put this in blender as well. AoI is great but lacks some of the great modling and animation of blender. But then blender is older and has a lot more people working on it.

I even have some renders from the AoI raytracer and the intergrated fluid engine. Still early stages tho. And note the freck out in one of them when the fluid goes unstable. For those of you that use the blender fluids, just remember its a very easy fluid solver to use, and will problably always be easyer than this one... anyway, the links:

first atempt

faster render

smaller particles

smaller particles and freck out!

Long time since last time

Yes. Learning a 2nd lanuage and work is taking up far more of my time than expected. However there has been progress I just have not posted it here. I have just got another machine for home so this will help. But its still a AMD64 so it takes a while to get all the python working properly.

But we are getting there. My try to show at least a nice render before Christmass.

Vienna

Well we are still getting settled here in our new Country. Flying for almost 24 hours straight is a long time when you don't fit between the seats. I still haven't got a computer yet and one HDD that come with me still hasn't hooked up to a computer.

Just before we left I was working on the iso-surface code that is meant to turn the bunch of particles into a nice flowing liquid. That was getting there and only have a few more details to check. Unfortunately for a lot of real world applications it is slow and could add 20% or more to the total simulation time.

The Goal is now to have a custom fluid simulator that will interact with animated objects. The 2nd feature set will be floating objects. This is mainly to support the special effects that I want to put in some short films meant for a game that my brother and I are working on. This correctness won't be dealt with until next year.

I must admit that I have been surprised to get some comments. I want to point out that my original goal is a fluid dynamics solver that will work for real design work. Not just cool animations. I like my high power rockets and work like to contribute to the community a bit with this code. Also I assure you this is not dead, but slow. I will announce the first release in the blender forums.

Thesis Is In

Yep... I have handed in the PhD thesis. Oh Joy. So if you have ever done a PhD you will understand the lack of postings. But don't worry I have done some work on it. Almost got the isosurface tessalation finished so we can have nice smooth sufaces without the huge performance hit that metaballs gives you. So you will see some updates in the next few weeks.

I will likly be "prerealeased" sometime in march.

Non Code Work

I have been doing quite a bit of R&D but mainly R. I really want this code to provide quite a wide range of capabilities, including thermal transport, reacting flows and full equation of state (supercritical fluids). Also i want to be able to model thermal transport through solids all in the same framework. This does not look like it will be too complicated, but there has not been much code devlopment.

Soon I will push for a release, manily for animations. It will focus on ease of finding a stable set of parameters, with some nice "defaults" for common liquids.

Back with the flow

Finally the computer is back up to full spec. The ram was not the
problem, it was a doggy motherboard. With the reduced ram i could not
both write and work on the fluid dynamics in the breaks. I will now be
back on it. The emphasis is still placed on real physical flows, and
its getting there, but it will be some time before its a verified
piece of code.

Bad Weather

Here in NZ Auckland there was a bit of a storm. Yes the weather was bad, but that's not what I'm talking about.

My Daughter decided to play up in the weekend and unfortunately, the inlaws played up with her. So we have had to move out and find another place to live. It did just take one day to do that and 2 more to shift into the new place. Its nice and there's a bit more room, although with less money I now have a small computer desk. I'm trying one of those small keyboads so that I have enough room for the mouse, so far its not so good. But we will give it time.

The upshot of all this is that the code has had nothing done to it since the last blog. Till next time, which will be before the end of the week.

Getting the Density Right....

I have been going over the theoretical foundations quite a bit this week. Reading papers and generally taking note of what different people do for boundary conditions. I have also done quite a bit of testing with very small particles and large particles.

I found one very big problem. At boundary and free surfaces, the density is "smoothed". This creates big pressure gradients at the surface and can cause big problems for initial conditions. However this is well known in the SPH literature and is called the particle consistency problem.

One method of fixing it is to consider the Taylor series and you get a reasonably simple expression for density. But the equations become implicit, and thus solving systems of equations are required. Instead I use the correction from the previous time step and thus is just a estimate. This works very well for density, but when I use the corresponding expression for the grad operator, I get nothing but instability. The expression can be 0/0 and the correct limit is 0, but numericaly.....

So at this point I only use the correction for the density and I'm getting some very nice results. But I will do some more work on proper correction of partial derivatives and attempt to get that working.

Finally Progress- We have Waves

Well XSPH did not pan out at all. Although it seem to improve stability, it did not make enough difference and really small steps were still required and there was a lot of particle randomness. So for the mean time, XSPH will be cut out.

Next I tried using different schemes to reduce numerical dissipation. I focused on methods that work with shocks, with the view that moving to shocked flows would be easier. I was very pleased with the result. It was reasonably easy to get nice splashes and waves while keeping the scheme very stable. I'm using two different methods and both will be included in the release.

Finally I have resolved boundary issues. I use the kernel as a force function and this seems to produced very nice results. Also by including viscosity with the wall we get a approximation to the no slip condition. It should be accurate enough and I believe it will give the correct boundary conditions in the limit.

The plan now, is to first clean the code. Then add animated obstacles, and finally add rigid body's. I don't know when we will implement the marching cubes iso-surface stuff. But it will be soon.

Making a Splash

I have fallen further behind. Oh well. Bound to happen. But thats not the same as no progress.

After trying to get a good splash effect and noticing that the resultant waves damp down very quickly. I experimented with very low viscosity settings. Unfortunately the particle small scale motion becomes quite random. The normal way of solving this is with XSPH, but i found this did not significantly solve the problem. I will try XSPH tonight some more, but then will look at direct methods at reducing numerical dissipation.

The boundary conditions is still getting constant overhauls. Especially when it comes to interacting rigid body motion. I still do not have a fixed solution for this yet and most likely there will be a plethora of options.

Finally one paper suggested a 10 times speed increase by just rearranging the particles in memory to make better use of the CPU Cache architecture. In java this amounts to recreating objects so that they are next to each other in the memory. On a Intel with a normal JVM I got between 2-4 times speed increase. On the AMD64 (already heaps faster) it slowed it down by 5%. So this optimization will stay on the back burner for a while. At any rate I was a little skeptical of 10 times speed increase.

Another Weak end

Yep... Still not that much closer to a release. Because of the change of plan, I have gone over the code to ensure that it is physically correct. Quite a few changes where required, but now its a correct SPH solver. We are using a 2nd order leap frog method that provides good stability. I have done some simulations with 100,000 particles without too much trouble. There has been a few issues with boundary conditions that now need a few options. But otherwise everything is progressing nicely, just a little slower than I would like.

So first is too include the Floating body code. Then finish the GUI. Before the release I will add a marching cubes iso-surface output option.

I may, in the near future add a POVRAY output option. This will allow very cool visualisation of shocks and over parameters with its volume rendering.

So i should have some animation by next week...

Blender Python GUI and new directions

Well the weekend was not so good. I tried to do a GUI in blender with python, and when in circles. I hate writing GUI's at the best of times, but learning the limitations of the integration of python was slow. So I'm ending up with a simplified interface with some restrictions that will be lifted later. At this point the restrictions are not too bad, which is just one, only 10 objects total. But again this is a GUI limitation not a code limitation.

Also I'm changing the focus a little. Originally it was just for good looking fluid. But now its target is fluid simulation. Eventually for compressible flows including shocks. But interacting fluids is first, and modeling floating objects looks like it will make the now delayed first release. I'm changing the focus for two reasons. One, the fluid engine thats going into blender is plenty good enough, and theres reason to believe that it will be always a bit quicker. Two, I have always done fluid dynamic solvers in my free time, and I love doing them, but usually end up spending a huge amount of time getting the geometry of the problem into my programs. Alto blender is not a solid modeler, the python scripting really makes getting geometry in and out very easy. Its internal renderer is more than good enough and fast enough and yafray adds that sex appeal to presentations. So thats what i'm going to do. Heres the basic plan.

• Fluid dynamics of incompressible liquids with interfaces.
• interactive objects. Both "floating/sinking" and manually animated interaction.
• Lots of options and a reference set so it be used for "real" studies.
• Smoke--ok this will be purely for effects..
• compressible flows
• 2D domains (its all 3D up to here)
• shocked flows.

No dates since this will be a work in progress. The first 2 will be done soon. At that point making it OS will be a option. But i intend to eventually get a publication out of this.

Delt0r.

Blender Fluid Dynamics

Well blender will soon have Fluid dynamics. Only I started to do a fluid dynamics plugin b4 I found out about the Summer of Code. [elYsiunm]

So i'm gunna finish it anyway. Mainly because i really want code i can play with. But also because i think my fluid code will fill a different need. Also my code will be ready to roll some time in the next 2 weeks.

The desgin is a bit strange, but I have my reasons. A python plugin will run/interact with a java program. The java sovles all the fluid dynamics stuff, and even floating and rigid body motion (hopefully). This writes output that a python script link then reads for the "baked" fluild simulation. The result is a mesh or a set of vertices that you can then dupvert or subsurface to your heats content. But you won't be able to "edit" the mesh and keep the changes i'm affraid.

The fluid simulation uses Smoothed particle hydrodynamics. Basicaly a bunch of particles, with the needed math to make it work like a real fluid.

I'm hoping that it will even do smoke. But that will need to wait.

The image is with halo particles and the fluid simulation time was about 5 mins on a AMD64. The animation is here and there another one here. There is a dupverted sphere animation here .
Delt0r