Moving along

Don't panic. There is progress. However I do have a life outside this hobby and that has been getting more attention recently.

First of all work has been getting further and further behind. But with a very focused 2 weeks Its all back on track. However there still a lot to do to finish the paper I'm working on.

The second reason is that I can get 11 euro train tickets to anywhere in Austria on staurdays till the end of march. We are using that big time. Last week we went to Saltzburg, this week were are off to Gratz. It nice to finnaly get out of Wien.

To follow that we finally got some cheap flights to Brussles. We are there for 2 days plus one day in Paris via the train. I promised Jayne and Jordan that we would see Europe while we are here, and after almost a year I'm starting to make good on that promise.

As for the fluid code. Its manily a staurday affair, so it has not got the attention lattly. But don't worry I have been working on and I do have some more movies. I wanted something out in feb and now its march. I won't give a data at this stage for a beta 0.5 release. But it should be sooner rather than later.

Moving Things Around

As I have had to revise the boundary condition code I thought I would test what does and doesn't work with moving boundaries. The big problem is always whats stable and whats accurate. Often getting both features can be tricky.

Originally I would use the velocity vector to provide a force that would then alter the velocity. Unfortunately if more than one "piece" of boundary was interacting with the particle the final velocity could be unbounded. Clearly not a ideal solution. However it did fit into the work flow better than other methods.

I have tried reflected particles and just "dead" boundary particles but have found both solutions somewhat lacking. Both are very slow, and treating density correctly is not as straightforward as it appears. Usually very small time steps are required.

Finally we have the method I'm now settled on. First we use the distance not from the boundary point but from the boundary plane that the point represents. Secondly we use a special step to update the velocity. In that the boundary only affects the velocity and only at fixed time in the update schedule. It give very nice bounded results as shown below in the movies.

There are a few points to consider however. First is that each boundary particle can affect the fluid. This means that the boundary behaviour is determined by how many particles are used to make up that boundary. Secondly there is no bounce, although that can be easily added at a later time.

So the movies consist of the same animation. One with the velocity vectors and the other with the isosurface. The tub that the water is being poured is set to hidden and the paddle does penetrate the tub. When the paddle "squished" the water between the wall and the tub, we see squirt of water. This is where the simulations would go unstable with other boundary condtions. However it should be noted that this "squish" will be very sensitive to parameters, and it will still be possible to send this into unstable regions with sufficient squishing.

Movies of moving paddle:
Raytraced Isosurface
Velocity Vector preview

Huston- we have a problem.

Yep. I have been just blindly using my fluid code that i devloped in NZ. Unfortunaly its not the latest version and the latest version is back in New Zealand on a unpluged HDD. That about 18,000km away!

So what does that mean. Well some dealys anyway. The current code is not "stable" in the sence that the simulation tends to go unstable easily. Even if i keep to all the usual time step limits. There are about 3 different things that it could be, and they will need to be debuged.

But otherwise we continue to make progress. For example we now have a proper object import system. Also moving boundrys are almost there. We are getting some nice previews and it should be quite fast.

Here are a few more movies:
Velocity arrows raster animation
Isosurface of the same animation But cut short.

Current Plan

Quite a lot of progress was made in the weekend. I don't have any screenshots however. Things are really shaping up for a 0.5 beta mid feb (aka ~10 days). Here is a feature milestone outline:

• Beta 0.5
  
  
  
  • Obstructions
  
  
  • non-adaptive time steps
  
  
  • Polygon Previews with velocity visualizing
  
  
  • Adjustable fluid parameters
  
  
  
  


• Beta 0.7
  
  
  
  • Polygon renderings(Could also be used for traingulation of isosurfaces)
  
  
  • Adaptive time steps
  
  
  • Multitreading fluid solver
  
  
  • Limited Moving boundary support
  
  
  • Accelerated Isosurface methods and baking
  
  
  
  


• Beta 0.9 feature freeze
  
  
  
  • Moving Obstructions
  
  
  • Surface tension (for small scale fluids)
  
  
  • Scale options
  
  
  • Moving fluid source/exit (aka hose end that's moving)
  
  
  • Useful presets (like water, honey)
  
  
  • Maybe a materials texture for dye and visualization
  
  
  
  

Going from 0.9 to 1.0 will be just bug fixes. Yea I get bugs in my code sometimes. At this point I'm working on the GUI. Dam I hate GUI's. Last night someone asked why I use the command line for mplayer when watching a DVD, because its easier than trying to find the option you want with clicks.

Wave Machine...

I remember on TV there was this wave machine where the water is pumped over a surface. Well I thought it would be better to get full on tubes. So here is the first atempt at animating a real wave machine.

Wave Machine

Another polygon preview:

Splash

If we look at the last frame and compare a polygon preview with a isosurface render.





So whats going on. Well the last frame took almost 10 mins on a AMD64 X2 5000+ with java64. Thats slow for such a fast machine. This is not so good for debugging so I put some effort into preview visulaizations. So I produce a single axis alginged triangle for each particle. This also includes boundry particles, thats what the stationary ones are. It the first splash you can see them on the surface of the object.

So now with rapid visulaization I should be able to finish this plugin sooner rather than later. But be warned I start my next german course next week so I will be very busy.

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.