Render times with different version of blender

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.

Blender 2.41

Blender 2.43

Blender 2.44

Blender 2.45

Its all been pretty good up until this point, then something happens

Blender 2.46

Blender 2.47

Blender 2.48a

Blender 2.49b

Blender 2.5 rev. 22956

Here’s the file
It was made in 2.49.

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.

2.46 introduces soft shadows, glossy refl/refraction, new QMC and adaptive sampling… Maybe something to do with that ?

Your scene renders in just over 6 secs here with 2.45 and 38 secs with 2.49b !!!

It seems to be primarily AO-related.

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.

From 2.46 has less noise comparative to 2.45

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%

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…

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…

I try the file with the jaguarandi Gsoc blender 2.5 build.(raytrace optimized)

Linux 64 q6600
Orginal file 8.20 sec
Constant Jittered 2.17 sec :smiley:
Approximate 16.10 sec

So raytraced is faster than approximate.:eek:

By comparison 2.49b 22.49 sec

By mib

What were the settings with AAO vs AO?

I take the default settings.
Pixel cache and sampling error to higher levels (2) helps to get closer to ao rendertime, but
render quality goes down.

By mib

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.

I also noticed that Blender started to render slower in the past versions
and that was without using new version elements like glossy.


Perhaps they are trying to build momentum for the new raytracing core?

“Look! 20x speedup from past (and dogslow) version!”

I hope that’s not the case…

:evilgrin: How cynical that would be !

Sorry if I still bother you with these render time problems, but I don’t get it.

I understand that AO thing: jittered is like old 2.45 AO.

But take a look at the following stupid scene:

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.

report bug?

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.