Saturday, July 11, 2009
Poll for what I should work on next
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.
Monday, April 20, 2009
Emiter update.
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.
Monday, April 13, 2009
Selection Sets and Physics
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
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
Monday, January 19, 2009
Ops
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.
So now it should always "convert to trimesh" without any special settings. Same link as below.
Small Release
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
So its at the normal place:
Physics.jar
Wednesday, July 30, 2008
Do we like bugs?
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.
Sunday, July 27, 2008
Surface quality and another beta-alpha release.
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.
Cheers
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
Wednesday, July 16, 2008
The Beta Alpha ++ release.
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.
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:
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
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.
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.
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
Subscribe to:
Posts (Atom)