the only test that has blur (vector) is stylized particles 04. Its helped a little.
the only solution to getting rid of the graininess when working with particles this size, is more particles. Thats why a lot big studios render 100,000,000 or 300,000,000. Blender is not capable of this.
maybe it will in the future, but I speculate…
many users a hobbyists
many devs don’t have the ability to test such things because they don’t have machines built for vfx.
particle system has been ignored for a while, mainly because of 1 and 2. Its not a feature that the general user will use (at least not to that extent), so it probably won’t ever get priority. Unless I become a studio and make lots of money and pay for it myself.
januz, I think that has a lot more to do with viewport performance then rendering itself. I could be wrong. Even so, I’d rather wait for it to get into trunk, than use gsoc build.
Though, the limit will still be 10,000,000 per per particle system, that would have to change before I could test such things.
I just did a test with 4 * 10 millions of particles.
My config : linux mint 14 processor I3770K Memory 16 GiB Swap 45 Go
It took 1 hour 44 minutes, and used 16 Gib of memory + 30 Gib of swap, but didn’t crash so I think the blender code is strong.
For good performance I used (4 *) 2 particles system for each emitter: one for only preview with only 10 000 particles, and one for only rendering with 10 millions particles. With this config the preview is fast.
I think that a simple cube is better than an icosphere for rendering, because in the range of small particles you won’t see the difference.
Perhaps with 32 GiB of memory and 100 or 150 GiB of swap you can reach the 100 millions particles.
Hi
I did a very simple simulation, only 4 cubes as emitters, frames 1 to 20 for simulation and I rendered the frame 20.
It took 1H 44 minutes, or 104 minutes. Not fast but as soon as you use swap the performance slow down but you are not limited by your memory size.
For swap file I configured it when I installed Linux mint 14. Always put it on a SSD.
I don’t know how to configure it in Windows.
ok well the tests have to be done on something more significant.
A lot of users have had issue with certain parts of blender, and these issue have been responded to with “hey i tried it on suzanne and simple cube, it works great”
It needs to be used in more of a “real-world” situation. Thanks for your input though. I’ll try to figure out on windows. I have windows running on SSD here, but not sure if have enough swap memory allocated. I don’t think I had a frame that took 104minutes anyway.
furthermore, this is what i’m talking about, houdini can render 10mil at about 2min per frame, 2mins vs 104minutes? blender is not competing here.
also, bare in mind that my tests are about 250 samples max, and at half res. This is quite disturbing. If we talk about sending to renderfarm, we are then talking about very expensive renders, literally. This why I say blender (at the moment) is not built for “high-end” effects.
I think rendering a cube as a dupli object instead of icosphere is a good idea though, i’ll try and do a test soon.
I just did a quick test: with 42,5 millions ‘cube’ particles (instead of 4 10 millions icosphere particles) , it took only 3 minutes 8 seconds,and 14 Gib of memory and 7 GiB of swap, so not far from houdini. I think the difference with 4 * 10 millions particles is due to swapping.
I agree with you that it would be better to have a real-life example.
It would be interesting to have a ‘Mike Pan’ benchmark for particles with an interesting scene, and with times for 10, 100 or 300 millions particles depending on configuration.
Sorry to quote myself, but bolded is the reason why i gave up on my experiments (almost 2 years ago), but now that cycles has point density, the problem should be solved (at least for the shader).
Before I design a sim, i’m working on the shader itself.
[ATTACH=CONFIG]405706[/ATTACH]
So this gives me a good approx of what I want the shader and lighting to look like. This is only like a 5000 particle system, but the particles size is large so I could obviously see the absorption effects. In order for this to have a smoother, less lumpy appearance, the particles need to be smaller, and as a consequence, there needs to be more particles so there are no “gaps”
so thats why people generally use millions anyway. Also as I increase particles, naturally, the shader is more dense, so gunna have to tweak the shader anyway.
The Goal is a nice 10million particle sim. Probably only about 4 secs though, volumes are generally “expensive”
Wish me luck!
edit: I wish I could just use one of the old experiments, but I deleted all the cache files (GB’S of data)
Hey guys, I did some pretty thorough tests last weekend. Pushing my computer to its limits and what not.
I decided to experiment with particle children with 10million parent particles. The most my pc can handle is 16 particle children, which I think would make the final render appear to have 160million particles. However, most of the rendertime is taken up by “loading point density”
but, it is possible…
here is a frame from a particle sim I tested it on. This however, is only 8 particle children , the most optimal on my machine (so far)
[ATTACH=CONFIG]407528[/ATTACH]
and this is a close up render of the bottom so you can see just how many particles there are.
[ATTACH=CONFIG]407529[/ATTACH]
The metadate has been pixelated, because i accidently didn’t change some of the notes, and it stamped the same information on every test I did haha, rendertime is accurate though.
