It might interest you to know that Blender2.45 renders 3X faster than Blender 2.49, (in my tests.)
I haven’t made renders with blender in a long time since I started playing with the game engine, and I felt that blender was taking an extra long time to render a simple scene.
So I made some test and these are my results.
Minutes:Seconds.Splitseconds
Blender 2.41
0:28.40
0:30.25
Blender 2.43
0:30.02
Blender 2.44
0:28.19
Blender 2.45
0:28.34
Its all been pretty good up until this point, then something happens
It would be cool to see your own test file and render times.
If you are rendering a huge scene and it take a long time, try it in blender 2.45 and see how much faster it is and post the results.
Your ray transp gloss samples are set to 18, try resave in the oldest version of blender you test with, load in the new blender and see how fast it renders.
Here are my results comparing 2.45 and 2.49b on XP32 Q6600
I’ve chosen 2.49b for obvious reasons and 2.45 because it is the last version before the jump in rendertimes.
For each I’ve switched RayTrace Transparency for the blue material on and Off and AO on and Off
no AO, no RT:
0.70s / 0.62s 88% The only case where 2.49b is quicker
AO, no RT:
3.11s / 5.02s 161%
no AO, RT:
2.02s / 2.55s 126%
AO, RT:
6.20s / 38.3s 617%
As soon as Gloss is set to 1, changing the number of samples doesn’t make a difference (logically) on 2.49b.
Setting AO to adaptive QMC helps but it is still 400%slower…
[Solved]
Thanks Ideasman42, I did that and found the AO rendering method had changed from “Conant QMC” to “Constant Jittered”.
Thanks for the Results Gwenouille, did you try setting the AO to “Constant Jittered”?
Pre 2.46 versions of blender don’t have the different methods to render AO, and the equivalent in 2.49b apperes to be “Constant Jittered” based on doing what Ideasman42 said. And that’s what Adrix89 noticed.
I’m glad I know this now, for when I’m baking AO maps for my game.
BTW, welcome to the forum Adrix89!
(new this thread wouldn’t be a complete waste)
Setting AO to constant Jittered doesn’t fully eliminate the problem.
2.49b still completes the render on 4 threads in 7.60’’ instead of 6.20’’
Where are these 1.40’’ ?
On ly RayTrace transparency might play a role here, and gloss is set to 1 so 18 samples shouldn’t play a role…
Constant Jittered gives AO results that are a bit more noisy than constant or adaptive QMC. Remember you needed high numbers of AO samples to reduce noise to almost nothing in 2.41, but adaptive QMC reduces the number of samples needed for that.
BTW: Play with the threshold setting for even faster results, having it at 0.001 doesn’t give you as much a speed benefit as say, having it at .050.
It has been created with 2.45. There is no AO in there, but some basic transparency.
It is only a glass Suzanne (why is she called “monkey” nowadays ?)
4 threads: no gloss (1.000):
it takes 23 secs to render on 245 and 39.8 on 2.49b !!!
Another question: in the viewport, both 2.45 and 2.49b find 31489 faces. OK
But the render window of 2.49b tells us that 52515 faces have been rendered, while 2.45 has rendered the 31489…
Can someone explain both the differnent number of rendered faces (the file has been saved in 2.45) and the different render times ???
Id guess some of the quads are being triangulated for being non-planer. edit, confirmed, Comment check_non_flat_quads() in source/blender/render/intern/source/convertblender.c and youll get the original number of quads.
Likely check_non_flat_quads() was added to fix some reported bug on faces overlapping themselves.
The faces ARE non-planer so converting them to tri’s ins’t incorrect, though the tolerance could be changed - currently its 0.999995.
Consider that not all scenes would have more faces or be slower due to this.
for architectural models its not likely to change the quad count. Suzzane just happens to use a lot of non-planer quads.
@ ideasman: thanks for your explanation of the variation in the number of faces.
But I dare to raise a question about these render-times.
I mean what is the improvement between 2.45 and 2.49b (the 2 I’ve used to test) ?
The result is more or less the same and yet the render-time doubles (using the same number of threads of course). Is the quad-to-tris function you are mentionning the only source of this decrease in time-performance ?
If yes, maybe there could be a way to switch it on/off ?
I don’t know, I am just curious. I find a bit disappointing that such a simple scene takes almost twice as long to render in the most recent version of the 2.4x series than with a 18 months old one…
@Gwenouille, you can build blender and see how much difference it makes commenting out check_non_flat_quads(), who knows, maybe this is the main slowdown in some areas, maybe not.
