2.34 slower than 2.33a

[xand]

the render in 2.34 is much more slower than in 2.33a.
i'm currently under win.
with others french users, we drive some test with pre2.34 versions to make a better report.

+++

[theeth]

Slower how? Rendering? Drawing the interface?

Rendering *is* slower now because of Full image oversampling (better OSA).

Martin

[xand]

i make some test of rendering with the file of raptor with ray and envmap from the 2.34 test zip.
the 'full osa' was off in material panel.
under win98

with 2.34, osa 16 2 min 14s 62
8 1 min 14s 50
off 0 min 20s 87

with 2.33, osa 16 1 min 28s 52
8 0 min 52s 0
off 0 min 18s 72

i've made some tries with a pre2.34 compil, the result are intermediary.
on the forum zoo-logique/blender, others one did tries (under win and linux), the result goes from 1.5 min in 2.33 and 20 min in 2.34.

the 'full osa' switch doesn't change the duration of the rendering.

+++

[xand]

i've just reread the new osa log. and the full osa option is always on with raytracing.

now, it's almost faster to raytrace with yafray or pov or a renderman and with better results.

+++

[lukep]

having full OSA on 16 make no sense.
full OSA at 5 is better than old-OSA at 16.

set OSA on 5 and give results

[ideasman]

If your simply testing the render speed for compile time options, cpu optimizations etc. then turn OSA off for both renders.

-Cam

[kid_tripod]

I have to say that for me this has made the internal raytracing unusably slow. (Mac version . . . don't know if it's been particularly badly hit??)

I am now looking more closely at getting into using Yafray . . . but in the mean time I'm back to using Blender 2.33.

[bertram]

I've also experienced tremensous slowdown of the renderer in 2.34 which cannot be justified by the new AA. I've tried to find out which feature can made responsible for the slowdown.
The results (Where 2.33 was Linux and 2.34 Win32):

Resolution was always 100% PAL
(Code formatting due to unispace-font)

Code: Select all

 Parameters                      v 2.33        v 2.34
NoAA, No Raytracing            0:07:65       0:08:86
AA8, No Raytracing             0:17:35       0:20:41
AA8, Raytracing, NoAO          1:23:84       1:37:20
AA8, Raytr., 12 AO-Samples     7:01:60      28:28:53

In my opinion there's something buggy with the AO. I cannot imagine that this big gap between 2.33 and 2.34 is "works-as-designed"!

[lukep]

I've also experienced tremensous slowdown of the renderer in 2.34 which cannot be justified by the new AA. I've tried to find out which feature can made responsible for the slowdown.
The results (Where 2.33 was Linux and 2.34 Win32):

Code: Select all

 Parameters                      v 2.33        v 2.34
AA8, Raytr., 12 AO-Samples     7:01:60      28:28:53

In my opinion there's something buggy with the AO. I cannot imagine that this big gap between 2.33 and 2.34 is "works-as-designed"!

There is many things which can go wrong beside AO.

Now to really help coders to find the bug :

- test both versions is same comp and same OS
- strip your test scene to only AO and model, no textures, no env, no shadow lamp, etc..
- try different octree size (the 64 def size is often not enough)
- try unified render
- post the results and make your .blend available

then coders have a workable situation to investigate.

[bertram]

Here's my log of tests:

1. - Removed all texture and material (took almost 1/2 hrs. for 218 Objects. Isn't there a method of automating the unassignment of textures? )

2.- Did test Render with AA-Samples=8 and AO-Samples=12 in blender 2.34 for Win32
Rendertimes @ non-uniform renderer stayed almost the same with rounded 30:00:00

3. - Did the same with 2.34 Win32 unified renderer and surprisingly the rendertimes dropped to 7:40:68!!!

4. - Tested the same setup in 2.33 Win32 with very confusing results:
6:47:31 with non-uniform renderer
8:23:58 with uniform renderer.

Also removing a negative point light, changing the only lightsource left from a sun to a hemi had almost no effect on the above results.

Octree Size was always 256 for the reason that this size gave the best results in previous tests. But I will possibly test this later, too!

As before: Test results without AO were comparable across 2.33 and 2.34 also between Win32 and Linux. But when activating Ambient Occlusion...
Is it possible, that the amount of supersampled rays has been changed for the buttons? I can't find anything like that in the changelogs.

[ton]

Found a stoopid typo in 'full osa' caused the wrong mask value to be sent to the raytracer. Instead of only tracing the current subpixel it did all
(or most) of them.
So that's the cause of slow AO in OSA render, but it affected other tracing rendering too. It wasn't in the unified render though...

The fix was committed, I'lll ask coders to upload versions in the testing build forum.

[z3r0_d]

1. - Removed all texture and material (took almost 1/2 hrs. for 218 Objects. Isn't there a method of automating the unassignment of textures? )

create your no-texture material [probably a no spec lambert shaded grey...]
assigned to one of the meshes
select all, and make that mesh [with your new material] active if it didn't become that way
press control+L and choose materials
[this will make all selected objects use that material]

[bertram]

@ton: Reeeespect! I was thinking of the common procedure call within a loop instead of outside or someting similar.... But a "simple" typo... (reminds me of the failed Ariane V launch)

@z3ro_d: That's a good idea for visually removing/replacing all material by one material. But you don't unassign any materials logically or even delete the materials physically.
Nevertheless this reminds me of a missing feature I really desired for during my efforts to clean up the respective scenefile (not the testfile!): Clearing unused materials (number of vertices that use a material that is assigned to a mesh =< 0) that were legacies from copying meshes as sources for modelling new meshes!
How about that?

[ilac]

@z3ro_d: That's a good idea for visually removing/replacing all material by one material. But you don't unassign any materials logically

Actually, you logically do - using the same method:
1. select a mesh with no material assigned (or delete material from current selected mesh)
2. Select all (mesh with no material being the highlit one - light pink)
3) Ctrl+L > materials

All materials now unassigned, all meshes now in their birthday suit - just like mamma Blender makes them!

to permanently remove freshly unlinked(unassigned) material datablocks:
Ctrl+w (be careful, this is a save function!)
Ctrl+O (re-open)

Repeat above to remove ulinked texture datablocks.

[mzungu]

So that's the cause of slow AO in OSA render, but it affected other tracing rendering too. It wasn't in the unified render though...

The fix was committed, I'lll ask coders to upload versions in the testing build forum.

There are significant quality differences btwn the current 2.34 slow render (with the "bug") and the fixed version. See this thread on elysiun to see pix. Are there settings that can be adjusted to achieve the better quality, if desired? Just wondering...