Well I loaded your file. Change the bake file name and presto. 1 second without problems. I can move forward or back. I did notice that my preview particle vectors are all messed up however. I though so. Another regression from 2.4 . Note that you would hit the max partical count of 30000 which is tough on a system. If you are not using jogl it would be painful if it worked.
But i can't see anything wrong.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I saved the original bake under a new name and proceded with a new bake. This one looks a lot mroe promising:
1. the first second of bake took some 5 or 10 seconds, rather than about 2 secs elapsed.
2. The next 9 secs took muuuch longer than before, and sped up near the end (presumably as particles left the system)
3. moving the timeline around (well, jumping to different time points) showed visible changes in the views, so I think I'm now cooking with gas :o)
I'll kick a render off soon, and see what comes out of that.
I have a few questions on my model.
Q: Which direction does gravity go? I had presumed it would go from top to bottom in my scene. Yet it seems to be going from right to left (same direction as the inlet box).
Q: Is the direction of gravity a function of something in my model? In which case what?
Q: Is there an easy way to animate the flow rate? Say I wanted to bake and render an animation of a tap being gradually turned on and then off again? How would I animate the increase and decrease in flow?
However, this is truly fabulous. I love the render of the water splashing into a bowl that was posted by someone on your blog. I'm off to try something like that soon. :o))
Cheers!
Nik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gravity should be in world coords. However its not. Its in physic pluigin coordinates. So gravity is in the -Z direction for the physics plugin. either rotate that object, or change the gravity acceleration in the parameters tab (Can't remember the name, but the one with partical size).
You cannot animate flow parameters. Yet. I will look into that in the future. You can only turn things off and on, and that is even manual.
Remember that clear fluids will be *VERY* slow to render (far too slow IMO) and that you can you the raster renderer to get the preview particles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nik
>>I love the render of the water splashing into a bowl that was posted by someone on your blog.
Bob
>>Remember that clear fluids will be *VERY* slow to render (far too slow IMO) and that you can you the raster renderer to get the preview particles.
I'm the one who posted that picture of the water splashing in the bowl. It didn't seem to take as long as you're suggesting, Bob. I think the final render time was only 12 minutes. Although, if someone was to try animating something like this, 12 minutes per frame is border-line too slow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
12 minutes is slow for production, but not bad if you're just doing stills...I just read an interview somewhere (can't remember the site) with a production animator who said he tries not to exceed two minutes for a single frame. In my own test animations I've gone way above that (especially with GI)...but it's worth considering.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I say too slow for mainly the reason that its probable 4-5x slower than it needs to be. If you use the implicit surface plugin you can get a idea of how much of a slow down I'm introducing. This will be fixed later by "baking" the density field to a sampled grid (oct-tree probably.. but we will see). With these simple scenes about +90% of the time was evaluating the density.
Also nothing that i have used is quite as fast as the renderman renderers with animation. There is a *heap* of stuff you can keep between frames and they seem to do best. I don't know how much photon maps etc are cached in AoI, but with GI it can make or break it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are some odd "flashes" in the latter stages of the video, as if the lighting has suddenly increased. I'm not aware of anything in AOI which would cause this, so I *guess* it's caused by the fluids plugin. The only problem is that it seems so *unlikely* that the plugin could cause this.
I'm using the regular Raytracer for this render, not AR.
> There is a *heap* of stuff you can keep between frames...
For better of for worse, the AOI renderers don't currently cache anything between frames. (At least, nothing that I am aware of.)
I have investigated a number of ideas for optimising both still and animation rendering, a number of which involved reusing data.
Hopefully once I've cleared my current backlog, I can get a few of those released for review.
Cheers!
Nik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Flashes are a complete mystery. I have never had problems like that. In fact with rendering there really was only the ones I posted here. But then again, I did almost everything in 2.4 so perhaps theres yet another 2.4 vrs 2.5 thing going on. The particle view does look wrong, and it could be related. I will set up some renders tonight on 2.5.
What are peoples thoughts on the coordinate system to use. Should i use only world coordinates or should i stick with the Physics plugin coordinates.
As for the caching thing. Most mainstream cache much less than i thought they would. Blender is only *just* starting to do it, and needs a bit of user intervention to work. The renderman renderers I have used need little more than the RIB file or whatever. Its a good system for top end stuff to be sure.
However the code setup for AoI means that a plugin renderer could be done for some of this sort of thing. AoI modular structure and resonable simple open access to the whole scene data for plugins makes adding this stuff a bit easier than in other apps i think.
Don't forget that you can animate the all the interactive objects. I haven't tried with the bone system, but this should work too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Flashes are a complete mystery.
Agreed. I'll re-run the render a few more times and see if a pattern emerges.
> What are peoples thoughts on the coordinate system to use. Should i use only world coordinates or should i stick with the Physics plugin coordinates.
I would make the default behaviour that gravity works from up to down in world coordinates. I found it quite counter-intuitive that the water went some other way. Part of this was that the mini-tutorial was specific about the orientation of the objects, so I had assumed that this was to do with gravity.
I can see that having object-specific gravity could be useful as well, for simulation of acceleration, special effects and for numerous spaceship scenes.
So failing a concrete decision, I would suggest gravity from up to down in world coordinates with an ability in the GUI to override that to use the local coordinates of that particular Physics object.
Regarding data caching, you are correct that AOI's structure makes it quite easy for various optimisations to be built as plugins.
Cheers!
Nik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't posted a render with transparent liquid for two reasons:
1. It it living up to Bob's predictions in terms of render time
2. I have not managed to get a transparent material that doesn't render with lots of ugly black and grey specks *sigh*
I'll work on the material more over the weekend.
Cheers!
Nik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nik - this might be unrelated but have you tried increasing the Max Ray Tree Depth ? If you have lots of transparent particles, you might be hitting problems unless you increase this accordingly.
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Baking was about 30min - but I´m very unsure as I didn´t watch the time.
One tip: I realised that initially I try to reduce partikel size so, that those partikels would go down
in the "heightfield". Without success.
Then I made the "swimmingpool" larger 4 times each direction - and leave the particle size at 0,1.
That worked for me!
I´m pretty much impressed of the possibilities and already know that I rather scratched the surface.
Please give us more hints about the parameters Bob (or deltor).
Harald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AA will totally kill any chance of a render in some reasonable time frame with transparent fluids as well. Bascily ray marching through the fluids needs *lots* of work. because the fluid is a max density in these parts a lot of fluid elements need to be considered. This makes it real slow. But if the ray only gets to the surface, then most of the time the ray is moving though empty space that needs few or no fluid elements to be evaluated. The plan is to cache the "voxels" that are "full" and empty.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I don't know how much photon maps etc are cached in AoI, but with GI it can make or break it.
In most cases, building the photon maps isn't a major speed issue. Watch the status messages when you're rendering an image, since it will tell you when it's building the photon maps. Although there are exceptions, it's usually a small fraction of the total rendering time.
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Nik - this might be unrelated but have you tried increasing the Max Ray Tree Depth ?
This did help, but I think my main problem with rendering the transparent tecture was not enabling caustics :o/
Thanks for the help folks!
Cheers!
Nik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I loaded your file. Change the bake file name and presto. 1 second without problems. I can move forward or back. I did notice that my preview particle vectors are all messed up however. I though so. Another regression from 2.4 . Note that you would hit the max partical count of 30000 which is tough on a system. If you are not using jogl it would be painful if it worked.
But i can't see anything wrong.
Just so you know I'm not fibbing ;). Though there something funny going on with the simulation.....
http://www.cibiv.univie.ac.at/~greg/Nik.mp4
Hey Bob,
Ok, I saved the original bake under a new name and proceded with a new bake. This one looks a lot mroe promising:
1. the first second of bake took some 5 or 10 seconds, rather than about 2 secs elapsed.
2. The next 9 secs took muuuch longer than before, and sped up near the end (presumably as particles left the system)
3. moving the timeline around (well, jumping to different time points) showed visible changes in the views, so I think I'm now cooking with gas :o)
I'll kick a render off soon, and see what comes out of that.
I have a few questions on my model.
Q: Which direction does gravity go? I had presumed it would go from top to bottom in my scene. Yet it seems to be going from right to left (same direction as the inlet box).
Q: Is the direction of gravity a function of something in my model? In which case what?
Q: Is there an easy way to animate the flow rate? Say I wanted to bake and render an animation of a tap being gradually turned on and then off again? How would I animate the increase and decrease in flow?
However, this is truly fabulous. I love the render of the water splashing into a bowl that was posted by someone on your blog. I'm off to try something like that soon. :o))
Cheers!
Nik
Gravity should be in world coords. However its not. Its in physic pluigin coordinates. So gravity is in the -Z direction for the physics plugin. either rotate that object, or change the gravity acceleration in the parameters tab (Can't remember the name, but the one with partical size).
You cannot animate flow parameters. Yet. I will look into that in the future. You can only turn things off and on, and that is even manual.
Remember that clear fluids will be *VERY* slow to render (far too slow IMO) and that you can you the raster renderer to get the preview particles.
Hey Bob,
Thanks for the answers - and for the video :o)
Hey guys! Look what I (mostly) did!! :o)
I've got a dual-core machine, so I'm not afraid of long renders :o)
However, my first one will be with the regular texture.
Thanks again mate, this is awesome.
Cheers!
Nik
Nik
>>I love the render of the water splashing into a bowl that was posted by someone on your blog.
Bob
>>Remember that clear fluids will be *VERY* slow to render (far too slow IMO) and that you can you the raster renderer to get the preview particles.
I'm the one who posted that picture of the water splashing in the bowl. It didn't seem to take as long as you're suggesting, Bob. I think the final render time was only 12 minutes. Although, if someone was to try animating something like this, 12 minutes per frame is border-line too slow.
12 minutes is slow for production, but not bad if you're just doing stills...I just read an interview somewhere (can't remember the site) with a production animator who said he tries not to exceed two minutes for a single frame. In my own test animations I've gone way above that (especially with GI)...but it's worth considering.
Well I say too slow for mainly the reason that its probable 4-5x slower than it needs to be. If you use the implicit surface plugin you can get a idea of how much of a slow down I'm introducing. This will be fixed later by "baking" the density field to a sampled grid (oct-tree probably.. but we will see). With these simple scenes about +90% of the time was evaluating the density.
Also nothing that i have used is quite as fast as the renderman renderers with animation. There is a *heap* of stuff you can keep between frames and they seem to do best. I don't know how much photon maps etc are cached in AoI, but with GI it can make or break it.
Hi Bob,
Well, I left my animation render running, and it completed 300 frames in 2 hours and 45 minutes.
Result is here (2.5Mb):
http://nik.homelinux.net/files/fluid-demo.mov
There are some odd "flashes" in the latter stages of the video, as if the lighting has suddenly increased. I'm not aware of anything in AOI which would cause this, so I *guess* it's caused by the fluids plugin. The only problem is that it seems so *unlikely* that the plugin could cause this.
I'm using the regular Raytracer for this render, not AR.
> There is a *heap* of stuff you can keep between frames...
For better of for worse, the AOI renderers don't currently cache anything between frames. (At least, nothing that I am aware of.)
I have investigated a number of ideas for optimising both still and animation rendering, a number of which involved reusing data.
Hopefully once I've cleared my current backlog, I can get a few of those released for review.
Cheers!
Nik
Flashes are a complete mystery. I have never had problems like that. In fact with rendering there really was only the ones I posted here. But then again, I did almost everything in 2.4 so perhaps theres yet another 2.4 vrs 2.5 thing going on. The particle view does look wrong, and it could be related. I will set up some renders tonight on 2.5.
What are peoples thoughts on the coordinate system to use. Should i use only world coordinates or should i stick with the Physics plugin coordinates.
As for the caching thing. Most mainstream cache much less than i thought they would. Blender is only *just* starting to do it, and needs a bit of user intervention to work. The renderman renderers I have used need little more than the RIB file or whatever. Its a good system for top end stuff to be sure.
However the code setup for AoI means that a plugin renderer could be done for some of this sort of thing. AoI modular structure and resonable simple open access to the whole scene data for plugins makes adding this stuff a bit easier than in other apps i think.
Don't forget that you can animate the all the interactive objects. I haven't tried with the bone system, but this should work too.
> Flashes are a complete mystery.
Agreed. I'll re-run the render a few more times and see if a pattern emerges.
> What are peoples thoughts on the coordinate system to use. Should i use only world coordinates or should i stick with the Physics plugin coordinates.
I would make the default behaviour that gravity works from up to down in world coordinates. I found it quite counter-intuitive that the water went some other way. Part of this was that the mini-tutorial was specific about the orientation of the objects, so I had assumed that this was to do with gravity.
I can see that having object-specific gravity could be useful as well, for simulation of acceleration, special effects and for numerous spaceship scenes.
So failing a concrete decision, I would suggest gravity from up to down in world coordinates with an ability in the GUI to override that to use the local coordinates of that particular Physics object.
Regarding data caching, you are correct that AOI's structure makes it quite easy for various optimisations to be built as plugins.
Cheers!
Nik
I haven't posted a render with transparent liquid for two reasons:
1. It it living up to Bob's predictions in terms of render time
2. I have not managed to get a transparent material that doesn't render with lots of ugly black and grey specks *sigh*
I'll work on the material more over the weekend.
Cheers!
Nik
Nik - this might be unrelated but have you tried increasing the Max Ray Tree Depth ? If you have lots of transparent particles, you might be hitting problems unless you increase this accordingly.
Julian
I had a nice go with the fluid Plugin.
http://freenet-homepage.de/vidiot/AOI/Splash_raster_Xvid.avi
Rendering was 7 min in 640 x 400 (resized here) - on my old Athlon 3200
http://freenet-homepage.de/vidiot/AOI/Splash_raytrace_Xvid.avi
This took 2 hours - at 320 x 200 surface error at 0,05 and raydepth 3.
Baking was about 30min - but I´m very unsure as I didn´t watch the time.
One tip: I realised that initially I try to reduce partikel size so, that those partikels would go down
in the "heightfield". Without success.
Then I made the "swimmingpool" larger 4 times each direction - and leave the particle size at 0,1.
That worked for me!
I´m pretty much impressed of the possibilities and already know that I rather scratched the surface.
Please give us more hints about the parameters Bob (or deltor).
Harald
AA will totally kill any chance of a render in some reasonable time frame with transparent fluids as well. Bascily ray marching through the fluids needs *lots* of work. because the fluid is a max density in these parts a lot of fluid elements need to be considered. This makes it real slow. But if the ray only gets to the surface, then most of the time the ray is moving though empty space that needs few or no fluid elements to be evaluated. The plan is to cache the "voxels" that are "full" and empty.
> I don't know how much photon maps etc are cached in AoI, but with GI it can make or break it.
In most cases, building the photon maps isn't a major speed issue. Watch the status messages when you're rendering an image, since it will tell you when it's building the photon maps. Although there are exceptions, it's usually a small fraction of the total rendering time.
Peter
> Nik - this might be unrelated but have you tried increasing the Max Ray Tree Depth ?
This did help, but I think my main problem with rendering the transparent tecture was not enabling caustics :o/
Thanks for the help folks!
Cheers!
Nik