The other AoI Fluids blog

Source code relased.

2011-02-19T21:23:00.002Z

This was done some time ago. But I forgot to blog post the news. Sorry, but i just don't have the time to finish or perhaps restart and finish this code. So the code is released in its raw awesome form. For more details please refer to the sorceforge forum:

http://sourceforge.net/projects/aoi/forums/forum/47784/topic/3725222

Wow

2010-04-13T21:43:00.001Z

Long time no posts. Sorry. The code is not clean. However if i don't do something with it very soon i will release it all.

Again. Sorry. Life interferes like that.

Poll for what I should work on next

2009-07-11T12:49:00.000Z

But no dates for when they would be worked on. Yes documentation is not on the list. Sorry. I think that slackware64 current has a screen grabber so perhaps you will get a video tutorial soon.

Emiter update.

2009-04-20T18:25:00.004Z

TroY manged to find a bug or two with emitters. So setting normals should work now. Don't forget that for the object to be animated you must uncheck the static checkbox. Also Emitters are still "old" code in that only vertex's emit fluid and their normals are defined by the AoI object, so you need shading to be set for the object. Same link as always.

Selection Sets and Physics

2009-04-13T20:13:00.002Z

I have now revamped part of the GUI work the why I would have always liked it to work. To make a long story short you can now set up parameters on a selection of objects or even a selection Set. This can make larger scenes much easier to work with.

There are however a few things you should know. If you selected a group of objects, then every selection set that is a subset of the current selection will also be selected. Also if you selected a selection set --all its selection set subsets are also selected.

Now the tricky part is when the editor is disabled. This means that all the objects that are selected do NOT have the same parameters or type. Or alternatively the type selected from the drop down is different. At this stage you can choose to set all of the current selection to what the editor has via the set to selection button.

So anyway a little playing around should make things clear.

The other thing that has changed is the way other objects are handled. In particular soft-bodies. They now have there own iterative solver. Its not different at this stage, but uses a smaller time step from the rest of the simulation, and hence the whole simulation can proceed much faster (ie with larger time steps). You can control this with the internal reps parameters for soft-bodies. Higher means more internal iterations. However this won't solve all stability issues so smaller global time steps will still be generally required for fluid soft-body interactions.

The other nice change is that I now check to see if the soft body simulation is trying to use all the ram. At this point it throws an exception rather than just consuming every last Meg on your machine. In this case either increase the internal reps or reduce the time step.

Don't forget to delete the physics object on older scenes and recreate a new one.

Here it is

Ops

2009-01-19T20:23:00.001Z

Once i properly answered the question i found even more bugs....

So now it should always "convert to trimesh" without any special settings. Same link as below.

Small Release

2009-01-19T19:51:00.003Z

Due to a question in the weekend i found a few Synchronization bugs. These are fixed in this release. There is still another bug floating around that does not seem to stop anything...

So its at the normal place:
Physics.jar

Do we like bugs?

2008-07-30T20:51:00.002Z

Cus I have a lot of em! The fixes for the surfaces had lots of bugs. And now they are fixed. I don't have much time so this will be brief.

Metaball ratio now works. So rather than changing spacing in the advance menu you can just set this to a value larger than 1. You will then need to adjust the threshold and if you get funny ray traced isosurfaces, you need to put the max gradient up to about 3 or higher as needed. This can slow down raytracing a lot.
Doubling the metaball size will make render about 8 times slower. Use the sampled grid if you can.
You can now convert your physics object to a triangle mesh. Just how legal the mesh is and how well it works in the rest of AoI is prone to ... unstable behaver.
I completely revamped the synchronization code using ReadWriteLocks. Seems to work well, but I still cheat a little.
This means there should be no more flashing animations. If you do get one with this new version let me know.
When you reload the file you worked on "yesterday" the particles are duped. This means that the first frame from you bake is stuffed. Don't use it to see whats going on and don't "rebake" from the first frame without reseting the whole thing.
Generally if something seems to start to go wrong. Reset, Rebake.

You know where to download it from.....

Surface quality and another beta-alpha release.

2008-07-27T19:03:00.011Z

I have been spending some time on working out how to get a nice looking surface. As you can see from previous posts, the surface currently looks rather "blobby". So I have read papers and done some experiments. I think I am getting somewhere, but there is much more to be done yet.

First of all I now let the surface kernel be different from the SPH kernel. The SPH kernel has a lot of math that it must obey in order to work properly which a "viewing" kernel does not need. The result is a much nicer looking surface, but far from perfect. There is a catch, you need to set the isosurface threshold down to 1 rather than the default 500. Otherwise you won't see a thing. My current viewing kernel is (1-r^2)^2 and is often used with metaballs. The results is much better and just results in a small amount of roughness. With some adjustment even better results are possible.

Here is an example:
Threshold=1

With a larger threshold:
Threshold=3

Both in a composite:
Both together

Same but with polygons Ray traced:
Ray Traced Poly Surface

lower threshold and higher poly res. Note that rendering time is dominated by the mesh build. So this could be much faster for transparent fluids.
Ray traced with finer polys and larger threshold

And a composite:
The Above together in white this time

As you can see the threshold can make some difference. Generally there is no right value and it will need to be adjusted. It should be noted that other fluid packages has similar parameters that need to be adjusted. Surface tracking is not a exact problem and hence the different methods that are used to tackle the problem. Also this will make less difference with very small particle sizes. But it will be slower.

The final version will be almost be 100% based on a mesh. But a good mesh is very slow to build and hence may need to be backed in with the rest of the simulation. In real flow you can bake lots of mesh's to a single "particle" bake and you can then adjust the different parameters better for different views (aka close ups vers far shots...).
The trick with meshes is not that they are better, in fact they will be the same as the isosurface examples above. But note that these examples are only a little rough and some smoothing could make it almost perfect. And that what we do. We add post smoothing to the mesh, usually via a iterative scheme that can be tuned.

Unfortunately the mesh code has some issues. First is the fact that there are bugs. For some reason when the mesh preview is on the cpu goes to 100% and never stops. Has anyone else noticed this? The next is that there are some cases that i get null triangles. And the biggest is that is uses some code that nobody seems to have written. This creates clear issues with the GPL'ness of the code base and I may just have to rewrite it.

I will still keep the isosurface code and at this point it gives the best results. You get some performance issues however and the best way to deal with that is to turn on the useSampleGrid option. In my scene above they caused the render to be about 5-10 times faster, and the difference would be even greater with transparent fluids.

Other changes are there are now some options for fluid objects. The first is a dither and just randomizes the particle positions so as to loose perfect alignment effects. The other is x, y and z ratios. These are fill ratios in these respective directions. The default gravity is in the y direction so if we set y to 0.5 the object will be half full. Also the fluid objects and softbody objects no longer get "blobs" at the vertices's.

Add one more render:
Transparent

The updated plugin is at the same link as last time. The last post still makes up some of the release notes.

Do not forget to change the threshold to about 1 or a little more for this version.

Cheers

The Beta Alpha ++ release.

2008-07-16T08:53:00.007Z

Yep a new release is here. First some movies:
loopable AoI
Filling an A with the old boundary
Filling an A new boundaries

There is a lot in this release so we will start with a list derived from the change logs.

Fluid objects are in. They are not "stabilized" and look rough. But we can now start with liquid in the scene.
New boundary parameters have been added and generally work better than the velocity bias parameter. The parameters are a factor to increase boundary force and a clamp value to limit the max value of that force. If the clamp value is greater than one particles can bounce a bit.
All particle boundary code has been more or less removed.
The integrator was made more consistent. This mean one more pass per iteration, but is more stable.
Softbodies are working.... Kind-of. WARNING, this can break your scene, have a backup.
Note that you still need to subdivide emitters.

So the fluid objects do work pretty good at this stage. They are however rough in that the surface does not look so good. When stabilization is added it will improve. What is stabilization. Say if you have a block of fluid and you place it into the same block as a boundary. When the simulation starts the fluid will move a little in order to settle properly. Its not a big deal but a "lake" will drop a little over the first few frames/seconds of the animation. Don't forget when using small particle sizes that you also need to drop the time steps as well.

Next is the boundary code. I'm a lot happier with these parameters to control boundaries than the velocity bias. The boundary factor is just a simple multiplier on the base force and clamp simple clamps the value. So the default is that the boundary has a effect of one on the surface. If we set the multiplier to say 1.5 and leave the clamp at one. Then the "thinness" of max effect is now larger. But the magnitude of the maximum effect is the same. If we let clamp be larger than one then the boundary gets a little spring to it and can push particles back rather than stop them from traveling though the boundary.

But what about softbodies! Well first of all its a long way from finished. Ok so not that long. But this really is a alpha alpha stage in that I does delete data from the scene and generally does not like anything other than full rebakes every time. So here are the guidelines:

Don't use high poly/vertex count objects.
Keep the spring stiffness high. About 5000-100000.
If the object collapses the simulation will go unstable.
If you want fluid interactions, then you will need to up the mass values to more than 1 on the softbodies. Also smaller time steps will be needed.
Every time you make a change to the scene rebake.
Once a object is set to softbody its animation tracks may get deleted. You cannot move the object around the scene. Reload the scene and position the object before adding it as a softbody.
Vertex are mass. If you have a lot of vertexs at one end, thats the heavy end.
avoid long and short vertexs in the same model.

So after that list does anyone want to try it? Note that softbody objects must be triangle meshes and can have approximation/interpolation smoothing.

Now I often get complaints with the large number of options. That is the deal at this stage. I/We need to be able to work out what works and what does not. The only way to do that easily is have the options available to try in different situations.

Happy AoI'ing....
Oh, I almost forgot, the plugin is here:
The Plugin

Softbodies and soft bugs...

2008-07-13T16:57:00.004Z

In the interests of interest, I have been working on the softbody section of code in the fluid plugin. Thats right, its called Physics.jar for a reason. The entire structure and methods used are there so that fluids, softbodies and rigid bodies can be integrated into one single engine. This will allow fluids to interact with these objects. But it does mean less optimized "sub solutions".

Currently the softbodies are working, with some known shortcomings while I sort out the finer details. Also I keep finding bugs. Right now there needs to be a little bit of a clean up of the raw simulation code. I have too many methods that don't properly document the contract for the engine. So boundaries are a bit of a interesting mix of problems really. Its all experimental code at the core and thus its far from clear what methods work well in practice. A good example is the no slip boundary conditions that are frequently used. When you are using fixed mass particles this turns out to be a really bad approximation, as the boundary layer is smaller that the particle resolution. Simple friction with velocity normals work very well and are much more stable.

I have now read more papers than I care to count on the subject of SPH. There is a general pattern however, and that's that its generally about a 1st to 2nd order method at best. Boundaries are where the side is let down, and even thou there are corrections (that I use) the smoothing kernels limit the local approximation across the parameters. To make a long story short, I'm not aiming for a 3rd/4th order method. In fact I estimate that I have 1st order at the boundaries and 2nd order throughout the fluid. I use only first order explicit time integrators. The combination turns out to not be so bad after all. So I keep the code that works, and its a little adhoc right now.

So the current softbody list of features and antifeatures:

Interact with each other
Interact with fluids. ie can float
Must be a triMesh
the mesh can be set to approximating to smooth deformations.
Interactions with each other is from vertex to face. So few vertexs means they tend to interpenetrate a bit.
Unfortunately you need quite small time steps to keep stable because of the explicit integration scheme.

And a very small example...
Soft body and fluids

The first Alpha Beta release....

2008-07-07T13:35:00.006Z

The final dusting to the poly boundary code have been completed. So now you can play with the new code. There are a few extra options now for boundary's that I will try to explain here. At this stage its about making options avalible so that others can play with setting to what works and what does not.

The first new option is the PolyBoundry. This makes it a polygon type boundary rather than a vertex based boundary object. The remaining options don't work unless PolyBoundry is true.

The next option is the calculate boundary outside poly. What this means is does a polygon effect extend out from the edges rather than the projected normal volume. In more technical terms, if we project a particle with the plane normal onto the plane that contains the polygon, do I do anything if its outside the polygon. Generally setting this to false works best. But for convex shapes there is the possibility of "leak vectors" . Setting it on mean that concave sections give too much boundary force.

The last new option is really for the case where Calculate boundary outside is set to false. Generally we will get very slow leaks over time. If we provide a constant velocity bias to the boundary conditions we help move particles that are close to leaking, back inside. But this is adding energy to the system and therefore can lead to pretty weired results. Below are some examples, but this should be small 0.01 or smaller. Always try 0 first. Even at low values that can make still fluids "boil".

There are some limitations to the current implementation. The biggest is the complete lack of friction. All current boundary's are frictionless and that can lead to bizzar results from what you might expect. Another is getting fluid boundaries to match the boundary surfaces for rendering. Currently there is no way to ensure that ray tracing a glass with water will be done correctly as far as I know. Its also not currently optimized either meaning that its slow that it needs to be. But its still faster than particle boundaries. The last limitation is the need to put the boundary triangle into all voxels that it overlaps. This means that using smaller particle sizes will increase memory requirements for the boundary objects.

So here is an example of the unstable rotation that is now, hopefully fixed.
rotator mpeg 4

This a example scene with the outside boundary's set to true.
Hour Cup
Note the large distance between the walls and the particles.

The same thing but with outside boundary's set to false.
Leaking
It now leaks, but only slowly.

Then we add just a little velocity bias (0.01).
bias fixes leak
We can really see the lack of friction here.

Getting stupid with bias (0.05).
Too much bias
Now the lack of friction is compounded with the extra energy added by the boundary.

Finally the file I have used.
AoI example file

This plugin is now only for AoI 2.6. But only because I don't use 2.5. Also its a beta-alpha for a reason.

Download the Physics Plugin

Polys for boundaries and stupid bugs

2008-07-06T22:03:00.003Z

Oh yes, Its finally done. We have polygon boundaries so you never need to subdivide a mesh again. This should make it about 200 times easier to use now and I will get much less over/under subdivided meshes, asking where it all when wrong.

Ok, so its not finished. The source objects only use vertices's, and we still need to convert to triangle meshes and you still can't have a initial condition that includes a full glass of water. But otherwise this is working with the only regression I have noticed is the save state issue discussed below.

However there was one bug that took almost the whole weekend to find. When I had a object rotating under a fluid source, it would go unstable. Even with time steps down to 1e-6 it would still go unstable. To make a long story short I did not really find the bug. But i did prove that it *only* occurs on perfectly axis aligned vertices's rotating in the x plane! Even rotated .1 deg in the y axis would prevent the problem. I think I fixed it but I'm really not sure. Its possible that you just need everything to be perfectly aligned in some other axis....

But its good enough for me. So I will package this up on Monday as a beta-Alpha release for those who want to give it a try. Remember that performance on the old highly subdivided meshed will be very poor at this point in time, so a "clean" slate may be best. Also remember that there is no guarantee that there will be any level of AoI file backward file compatibility.

Also I will update the blog with a link to some new movies Monday as well.

Real Triangles, well infinate planes anyway...

2008-07-02T17:22:00.003Z

The first big steps to removing the need to subdivide meshes has been taken. The biggest chunk of the required infrastructure is in place and working. The triangles however are approximated as infinite planes instead. But due to the fact that I use the particle boundary code there should not be to many issues to iron out as most of the code has been used a quite a bit.

I make one quite big assumption. I approximate all properties across the face of a triangle as a linear combination of the vertex values. This means that velocity of the face is not accurate for large polygons that are rotating, but this can be solved simply with subdivision for these perhaps quite rare cases. Another consideration is that the force of the fluid is transfered to rigid bodies in a similar fashion for rigid body dynamics, and this could also lead to inaccuracies and perhaps instability.

The code is not in the best state, and there is still quite a bit of try and comment out code as well as out right hacks in there. The is already one regression. The plugin does not preserve state of object that are created after the physics plugin for example.

In order to catch regressions early, I was thinking of releasing regular snapshots that are simply totaly untested. If folks would like this it would mean that regressions would be picked up sooner rather than later. Otherwise the whole debug cycle gets a little slow. Let me know what you think.

So the next *proper* beta release (0.7) I will hopefully have the following fetures.

Full polygon boundaries for moving and stationary objects.
Basic Rigid body dynamics.
Animating parameters.

I have also noticed some serious performance issues. Its just much slower than it should be. This will perhaps not get looked at in the next release.

Laptop

2008-06-22T15:19:00.002Z

In the interests of getting work done when I'm on a train, I just got myself a new laptop. This is in fact my very first laptop and unfortunately it has been cursed with Vista. But I already have cygwin working and will put Linux on it once I have at least some good uptime with a live DVD.

In the mean time this means that it will be much easier for me to work on things like the fluids plugin when I'm away from my fixed machines.

Other Things

2008-03-24T10:02:00.003Z

This is just to give a update on what i have been doing. Although it was not on the AoI fluids plugin. But it is not forgotten, and if i ever do abandon it, I will release a full source version. Remember I want this plugin too. Your feed back was read and will be reread, so its not wasted.

So what have i been doing. Well I been to New Zealand and back. I have got a contract in the wings that means I can stay in Austria for another 2 years (maybe I will learn some German?). I have noted my lack of ability to Get Things Done, found a book with that title and I am finding it really helps to, well get things done.

Last but not least I have migrated all my code from subversion to Git. Oh what a joy git is compared to cvs and svn.

Its interesting how I found out about Git. I started using CVS for everything in about 1995-7 (can't remember exactly as I cleaned and reset my repository in 2000). I was not that impressed. I could not do a lot of the things I wanted to like move files. Binarys was not well handled and some things were far slower than I thought they should be. I did try a merge from a branch once.... and only once...

Then I ended up working for some companies that used source safe. Now I hate working on windows at the best of time. Nothing personal, I just find that MS support and documentation is terrible compared to other companies I have worked with. But what the Hell was MS thinking with source safe? Surely they didn't use it in house? To make a bad tool worse, the company I was working with had very stupid polices regarding file locking.

To make a long story short, I fell in love with CVS because she was the prettiest girl at the party. Not because she was pretty.

I kept looking for a better way because there must be a better way. Hence I found subversion. I have now used it for about 3 years. The problem is that its not really a better way, but the same way. Combined with the tools in IDE's (eclipse mainly but netbeans as well) my repository kept getting into limbo states preventing commits. It was difficult to fix without a complicated rolling backup system. Further to that problem, which directly affected the fluid plugin, was that I would end up out of sync with home all the time (I had no internet).

It was the fluid plugin devlopment that got me thinking that my personal devlopment model was in fact distributed. It didn't take long to find git. Unfortunately the admin at work never would give me a time when he would install it at work. So i waited until our machines got upgraded which was last week. Now all my repositories have been transfered to git. I don't use IDE tools for version control anymore since they just don't work that well. But with git is does not matter because the checked out directory is clean.

So why Git? Here is my list.

Distributed development.
Fast, very very fast.
Merges work so branching becomes common. This means there is better history too.
Unix tool set.
Very good repository integrity checking. This is a big deal IMO.
Easy to use (edit) configuration file.
Frequent branching makes "frozen" release much easier to manage. Debugging on the frozen branch can be easily merged with the main devlopment trunk.

The is even some tools to import a subversion repository with history. So I still have a history back to 2000. In short, even if you are a solo developer I would still recommend Git first and distributed version control over everything else.

Feedback.....

2007-10-25T14:57:00.000Z

Just to let anyone know that may care. I'm still waiting for feedback on the current state of the plugin before I update to the new version.

Also a few comments on what people get wrong.

Yes you do need to divide the meshes up finely. But not that fine. As long as each vertex is about a particle size away your fine. I have seen some meshes with 10k+ vertex's. Thats too fine unless particle size is smaller that .001
Normals pointing in the wrong direction. It seems that there are few issues with normals. Use approximated polygon objects, convert to triangle mesh and then set smooth shading.
You need a lot of particles to get a "good" fluid. 10,000 is not a lot. Rendering time still dominate in my experience.
Time steps are too large. If the fluid just disappears, its because the simulation blew up.

So unless i get comments to the contrary I will work on the following.

Remove the need for subdivided meshes. This should fix the normal problems too. This is however quite a bit of code.
Some small adjustments to the GUI, but they won't be big. Yet.
Try to get some adaptive time steps in there. This will be a experimental feature.

Please keep the feedback coming.

Beta 0.6

2007-10-01T11:36:00.000Z

The servers are still down and could be for a while. But i found a good file sharing site mediafire. It works on all the browsers i tried (Ok it didn't work with lynx) and didn't swamp me with popups. Nik is going to also host the main jar as well (Thanks). Watch out for his link latter.

So there are big changes with the beta 0.6. Most are behind the scenes to get everything ready for other physics and particle work. Rigid body and softbodys should not be that far away, and including them with this makes fluid interaction much easier. Also gases and fluid driven Materials and textures (for the procedural texture/material editor) will also be not too far away.

But for the current uses heres the bugs that will impact you the most:

Found and fixed a bug in the find neighbors code. Now you can use larger time steps and not blow up.
Found and fixed a density calculation bug when the spacing parameter is smaller than about 1.2. Now any spacing parameter less than 2 can be specified.
Some bugs in the thread code that lead to things being done twice on dual core machines was fixed.
XSPH bugs were fixed and is now exposed to users.
Many more i can't remember.

Some things that I have not yet fixed:

The flash/flicker that some have seen in rendering is almost defiantly a thread issue. Where it renders a next frame before the data for that frame is loaded properly.
It is still difficult to get a "smooth" surface to the fluid. This may require a lot of work to fix properly. Some surface tracking methods are more complicated that the fluid simulation. We will see how it pans out.

The big things added:

Mesh previewer. Its is however slow and not that accurate for the resolution. Its not adaptive and will scale with the bounding box. Also you might want to turn it off when you render a ray traced movie.
Sampled Grid to speed up ray tracing. On very simple scenes on the dual core machine at home there is almost no improvement. But when AA or extra lights are added this starts to change quickly. At work on a slower single core machine its about 2x faster with java 1.6 and about 5x faster with java 1.5. Note that you get very weird results if Sample Grid factor is too small. 4 or larger are fine. Too large and you spend a lot of time building the sampled grid. Note this does not use a tree so the grid build time scales with the volume of fluid. This should make it fast enough to render transparent fluids.
Improved GUI for object management. Again its not finished, but its easier to use both for a user and a coder.

Unfortunately this has added a issue or two:

Sometimes a when you load a file and raytrace it there is no fluid. I can't locate the bug yet but a workaround is to turn on the sampled grid (under preview/view tab) render and then turn it off again. Preview renders seem to give you a good idea of whats going on.
What little documentation there was is now largely wrong. There is no other documentation at this stage.
The mesh preview will rarely have a large missing strip on it. The fix is to either move the physics object very very slightly (The fluid won't move because its in world coordinates) or add a small about to the mesh size under the preview/view panel to not be a whole fraction or multiple of the particle size. ie mesh size = 0.050001.
Previous save files will not load properly with this version. However AoI is robust and will load everything else and you will just need to delete the not loaded physics and add a new one and configure and save.

Quite a long list here. I will try to now just comment of a few catches when using the plugin.

When you change parameters like particles size. You must reset the simulation and rebake. If you don't the simulation can blow up no matter how small the step size. Generally if in doubt rebake.
If you bake a simulation but did not save the parameters set, then when loaded from a save file everything can be inconstant eg. particle size, and hence raytraces and meshes will be wrong.
Use lots of particles for realistic effects and use a high density threshold for emitters. The advanced option of spacing can be reduced, but will increase simulation time.
ensure that all boundary and emitter meshes are subdivied enough and that the smoothing method is set to shading.
If you try XSPH reduce the step size.

So where are the files:
Here
The plugin is the Physics.jar file.
Everything will move to the server I was using before when its back online. And don't forget. Its still a beta.

Downed Servers.

2007-09-29T09:49:00.000Z

Unfortunately the raid (So much for redundant) of our server at work has died. I can get no word on when it will be fixed. 1 week tops. Very sorry about this. I might put the files in some temp place for a week or so.

Update

2007-09-24T13:33:00.000Z

The Plugin has been updated. So this is version 0.51. Don't forget you need java 1.5.
So what was done?

Fixed a bug in the bake file saving code. Now you shouldn't get "stuck" as was happening before.
Found and fixed 2 bugs in the simulation code. It now should be more accurate. Note that in the advanced options you can select a single pass simulation mode. It might be faster, it will certainly be less accurate and may need smaller time steps.
Implemented a direct gradient finder for the ray tracer.
Provided a good default for max gradient. This makes ray tracing much faster. You might get some rendering artifacts however. Just increase the max density adjustment under the views and previews panel. Thanks goes to Peter for implementing this suggestion so quickly.
Fixed a another bug in the bake file saving where the y velocity component was getting placed on both the y and z axis. This would cause rebakes to be totally incorrect.
The coordinate system is now world coordinates, not the physics plugin local coordinates. This will change the direction gravity acts. Default is the -z direction.
Moving between frames with a lot of particles was very slow. This has been somewhat fixed and should be a lot faster now.

So because of these bugs you should update ASAP. Here are some results from the debug process when its all pear shaped.

Simulate

Render. Problem!

Now it works and only 12 mins to render.

Don't forget with these render times that I have a AMD X2 5000 and use java 1.6 (about 1.5x faster than 1.5). The simulation time was under 10 mins, but i don't remember exactly how long it was. Also the simulation code is single threaded at this time.

And almost forgot. The Plugin is in the same place. Here

Good news everyone....

2007-09-15T18:18:00.000Z

Think the Professor from Futurama when you read the title.

Yep. The beta 0.5 is out. However the documentation is even more sparse than I would like. Remember this really is a beta.

Basic HTML getting started

PDF of the same thing

Failed attempt at a Flash tut I used wink, unfortunately screen grabs when a menu is selected/pulled down does not work. So its not so good. But maybe it will help someone.

Image dump of the above flash. Warning, quite large.

And finally the link you are all waiting for:
The Plugin and it comes with the whole No warranty deal.

And finally I forgot one very important thing. Trying to ray trace transparent materials will be Really Really slow (Glacial speed). This will be fixed at a later time. Also in the mean time report bugs at the AoI source forge forums.

No posts does not mean zero progress

2007-09-12T14:06:00.000Z

Well something like that anyway. I have been working away at the plugin. First of all we have added everything for the 0.5 beta release. I just need to fix the last few bugs that bug me. Secondly I'm moving the plugin over to the AoI 2.5 format. So when will it be ready? Well soon.

Last weekend I just got sick of computers and took my family to Venice for the weekend. It was nice and much cheaper than i thought it would be. This weekend could be the weekend. Lets hope.

Anitbugs

2007-07-13T15:16:00.000Z

An antibug is a bug that combines with another bug and "fixes" it. Last night I found quite a few bugs and then had to spend most of the night finding the corresponding antibugs. These were infact quite big bugs in the sense that they where mathematical in nature. So if the size of the particles was changed, the results were quite simply wrong. Fixing this has meant some performance improvements as well. Unfortunately it means I didn't finish the plugin to a beta 0.5 yet. Also I have two more things to add to the list of todo's. Firstly I want to put in the advanced Options and a "reset" button.

So here is the suface version of the jump with the old code:
Old code Jump

Here is a new version of the jump with the fixed code:
New code Jump
New code Jump, Side View

Reading the tea

2007-07-12T12:35:00.000Z

So I hit the literature last night too see how much the field has progressed. How surfaces are generally done and incompressible SPH. There is finally a few papers on divergence free projection methods out there now. Because this has been used with other methods espisally for visually effects where accuracy is not so important (aka RealFlow I think) I was surprised that it took so long to be implemented with SPH.

In the future I will probably implement a divergence free fluid solver (via projection) as this will allow for very large time steps and allows for "vortex forcing", that is make the fluid more turbulent which is often the desired visual effect. As for surface tracking I will probably try a "colour" method to determine the normal at the surface. The unnormalized normal is a proxy measure of distance from the surface which provides a nice way to integrate with the isosurface solver in AoI.

Oh and here is a full simulation of the bent channel flow. It took 8 hours and has a maximum of 20000 particles with another 10000 boundary particles. This should be perhaps a bit faster really.
Zigging and Zaging
IsoSurface render

I also did a hydraulic jump. The iso render is cooking.
Jumping fluid

The reference to tea is because I cannot drink the large amounts of coffee I would usually drink. So now its lots of tea......

Final Beta 0.5 Stages

2007-07-11T13:10:00.000Z

To my surprise I got to spend about 6 hours on the code yesterday. This was enough to get real close to a releasable beta.

What was added:

Moving fluid inflow
Moving fluid outflow
Improved GUI
Bounds parameter (removes particles outside the bound)
Max particle parameter
re-coded the interface between GUI objects and fluid Solver Objects

What needs to be done:

Add support for save and load.
Fix some minor bugs
Documentation. You will need some to use the beta (perhaps alpha?)
Add some parameters to the GUI, like max particle count.
Add tool tips. Makes docs easier.

There are some other issues that have come to light. First is that there will need to be some serious improvement on the surface representation to get a nice look. This could be some work and will be done later. Secondly without adaptive time steps there are large performance issues. In particular I want to add adaptive time steps both in time and space.

So the 2nd Generation Fluid solver will have adaptive time steps and support for multi core CPU's and will be what I work on after the beta release. The new surface stuff will need to be later. We will see. Anyway heres some movies of the latest incarnation of the plug in.

Ugly Surfaces
Same as above in preview mode(15MB)
30000 particles is a bit slow

Appendicitus

2007-07-07T17:13:00.000Z

I have had a sore stomach for some time. It finally got bad enough that I couldn't go to work and had to see a doctor. To make a long story short I got my appendix removed, and spent most of last week in hospital. The good news is that the Austrian Health system is fantastic. All up its going to cost me 30 Euros!!. Seems I got lucky and went to one of the better Hospitals.

Of course the bad news is that work is now further behind along with the fluids plugin. I was hoping to do some while I was away from work. But unfortunately It looks like that won't happen. Sorry. There isn't much to do for a beta. But its still not ready. The goal is to be at version 1.0 by the end of the year.

I'm very sorry it won't be sooner. But quite a few things have gone a little pear shaped this year so far. Nothing serious of course, well not too serious, but enough that things just don't get finished when we wanted.

So thanks for all the comments, they do help. All i can say about the beta is that it will be out before duke nukem forever.

Edging closer

2007-06-10T13:58:00.000Z

I managed to write some code. Create some regresion bugs and then fix them. Here are the short movies. There are quite a few "bugs" that you can see in these movies, however thay are perfectly normal and with high resolution meshes and fluids you won't have problems with them.

Preview renders
A few seconds with the ray tracer

Note that the liquid surface needs work. This will come later.

Slowly

2007-05-04T14:46:00.000Z

Very sorry for the lack of updates. I knew that march and April would be a write off. May is looking that way too unfortunately. This is why I tried to get it out in feb, since long delays were going to be the order of the day otherwise. Frankly I'm surprised that I have not had a few more "bumps" from the AoI users.

So I want to make one thing very clear. Its fine to request info on updates. Its makes a big difference on what in my spare time gets the time. I would like to say that I'm a super disciplined machine with great work/fun allocation skills. However I'm not. So don't feel you can't keep asking whats going on.

The other thing I want to make clear, is that it will get finished to version 1. I will push it that far and then open up the source. I may take to the end of the year, but it will get there.

Oh and just in case your interested. I have been teaching and writing for work. Also add some unprodctivness in there as well.

Options

2007-04-05T09:14:00.000Z

So for the first beta there is going to be a lot of options. For the most part folk won't want to adjust them, however they should provide work arounds for most problems you will encounter. In particular since I still don't have adptive steps there is the problem of choosing small enough step sizes, otherwise the fluid blows up, more or less.

There is still a bit to do. I need to put in motion avraging code, theres the partical density and the scale factor to add. Also there is some code cleaning to do. At this point I will stick with the main AoI realease and work with the new beta stuff later. As a result renders are a little slower than they need to be at this point.

Same slosh without the box and using the raytracer

GUI's

2007-04-04T13:55:00.000Z

Been working on the GUI again. Its getting there. It won't be finished by a 0.5 beta but then again I want some feed back on the general GUI design. Hoping to make some serious progress over easter. Although I have 6 hours of leasons to get ready. Heres the latest Vid.

Slosh in a Box

Moving along

2007-03-09T14:56:00.000Z

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

2007-02-12T12:43:00.000Z

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.

2007-02-09T18:40:00.000Z

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

2007-02-05T13:03:00.000Z

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...

2007-02-01T12:40:00.000Z

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

2007-01-31T15:03:00.000Z

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

2007-01-14T14:32:00.000Z

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

2007-01-05T13:03:00.000Z

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

2007-01-04T21:13:00.000Z

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

2006-11-24T17:54:00.000Z

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

2006-05-18T11:16:00.000Z

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

2006-02-06T21:13:00.000Z

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

2005-11-04T22:10:00.000Z

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

2005-10-16T23:50:00.000Z

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

2005-09-20T11:00:00.000Z

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....

2005-09-15T20:50:00.000Z

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

2005-09-11T23:16:00.000Z

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

2005-09-09T01:34:00.000Z

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

2005-08-29T07:57:00.000Z

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

2005-08-22T21:42:00.000Z

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

2005-08-18T11:14:00.000Z

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