2.34 slower than 2.33a

Blender's renderer and external renderer export

Moderators: jesterKing, stiv

Post Reply
xand
Posts: 33
Joined: Wed Oct 16, 2002 9:46 am

2.34 slower than 2.33a

Post by xand » Fri Aug 06, 2004 7:14 pm

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
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth » Fri Aug 06, 2004 7:20 pm

Slower how? Rendering? Drawing the interface?

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

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

xand
Posts: 33
Joined: Wed Oct 16, 2002 9:46 am

Post by xand » Sat Aug 07, 2004 3:48 pm

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
Posts: 33
Joined: Wed Oct 16, 2002 9:46 am

Post by xand » Sat Aug 07, 2004 4:39 pm

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
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Post by lukep » Sat Aug 07, 2004 4:50 pm

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
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman » Sun Aug 08, 2004 1:34 am

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

-Cam

kid_tripod
Posts: 35
Joined: Sun Dec 15, 2002 10:52 pm

Post by kid_tripod » Thu Aug 26, 2004 12:54 pm

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
Posts: 0
Joined: Wed Oct 16, 2002 12:03 am

Post by bertram » Sun Aug 29, 2004 12:44 pm

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
Posts: 0
Joined: Sun Apr 04, 2004 1:39 pm

Post by lukep » Sun Aug 29, 2004 1:41 pm

bertram wrote: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
Posts: 0
Joined: Wed Oct 16, 2002 12:03 am

Post by bertram » Sun Aug 29, 2004 5:42 pm

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
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Mon Aug 30, 2004 7:22 pm

:oops:

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
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Post by z3r0_d » Mon Aug 30, 2004 8:35 pm

bertram wrote: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
Posts: 0
Joined: Wed Oct 16, 2002 12:03 am

Post by bertram » Mon Aug 30, 2004 10:02 pm

@ton: :shock: Reeeespect! :D 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) :wink:

@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
Posts: 131
Joined: Mon Oct 14, 2002 8:24 am

Post by ilac » Tue Aug 31, 2004 12:09 am

bertram wrote: @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! :oops: :wink:

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
Posts: 0
Joined: Mon Jun 14, 2004 7:40 pm

Post by mzungu » Fri Sep 17, 2004 6:30 pm

ton wrote: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...

Post Reply