Sun, Nov 24, 4:52 PM CST

Renderosity Forums / Bryce



Welcome to the Bryce Forum

Forum Moderators: TheBryster

Bryce F.A.Q (Last Updated: 2024 Nov 21 4:12 am)

[Gallery]     [Tutorials]


THE PLACE FOR ALL THINGS BRYCE - GOT A PROBLEM? YOU'VE COME TO THE RIGHT PLACE


Subject: The official Bryce 6 performance thread


madmax_br5 ( ) posted Fri, 20 October 2006 at 1:21 AM · edited Sun, 24 November 2024 at 4:50 PM

Creating this to avoid crowding the forum, please post any performance related comments/questions/concerns/bugs in this thread. Please include the following with any performance related figures: processor type? single/dual/quad cores? operating system? running by itself or with other applications open?


madmax_br5 ( ) posted Fri, 20 October 2006 at 1:41 AM

My initial observations: Tests performed on: Dual processor 2.0Ghz PowerPC G5 Mac OSX 10.4.8 (current) running with web browser open Processor usage at idle: When Bryce is not the active application, i.e. is not the active window, CPU usage is negligable, in the 1-2% range. When it is the active window, processor usage jumps to 50% per core, or 100% total. I consider this a bug, there's no reason it needs to use a full core if I'm not doing anything in it, regardless if it's the active window or not. It is, however, more even than with bryce 5. Bryce 5 would use 100% of one core and zero of the other, while this uses 50%/50%. I'm not sure if this is due to upgrades to bryce or upgrades to the operating system. If one processor is disabled, bryce hovers around 80% usage of the single core when made to be the active window. Processor usage while rendering: A test scene used 100% of both processing cores and took 0:47 to render With one CPU core disabled, the rendering used 100% of the single core and took 1:23 This equates to a multiprocessor speedup of 76% Interestingly, the rendering process performed one final pass with both cores enabled, and did two partial final passes with only a single core activated. Rendering to disk does not utilize dual processors, and is slower than rendering to screen with a single processor (80-85% usage versus 100% usage while rendering to screen). I also consider this a bug :) Let's see what you've got to share!


CorwinRathe ( ) posted Fri, 20 October 2006 at 1:51 AM

I'm not sure I would consider rendering slow to disks a bug. Think about it. Speed to the hard drives is the slowest part of the system. This would naturally slow things down.


madmax_br5 ( ) posted Fri, 20 October 2006 at 2:00 AM

True, but the amount of data being written is so small it shouldn't be stressing the disk at all, and it shouldn't effect the processor usage either. Plus, the data is being rendered to the RAM first, and then to the disk later. If the total image size is 4MB, and it takes a full minute to render, that's 68k/second of data that's coming out. Modern hard drives have read/write speeds of at least 50MB/sec, so I doubt that the hard drive is a bottleneck here. But then again, could be, can;t tell for sure :)


omac2 ( ) posted Fri, 20 October 2006 at 2:41 AM

another quirk i been noticing is memory usage.

On small scenes theres a slight increase of 4-10Mb more being used by B6 BUT i loaded some big 150-200Mb scenes and this memory increase went to 150-200 Mb more.

This is in comparison with B5.5. I opened the same scene on both versions and the difference is huge. (this scene in B5.5 was showing ast 400Mb used by the taskbar but the same scene in B6 was using 500-550Mb)

Not a big deal but something to look out for.

My pc,

x2 4400, geil 2Gb, WD 75Gb, win xp home.

 

 

 


pauljs75 ( ) posted Fri, 20 October 2006 at 7:36 AM

Maybe they're assuming that you'd use the computer for other stuff while rendering to disk and want to leave part of the processor free so other apps won't slow down? But if this is a case, there should be an option to toggle it.


Barbequed Pixels?

Your friendly neighborhood Wings3D nut.
Also feel free to browse my freebies at ShareCG.
There might be something worth downloading.


CorwinRathe ( ) posted Fri, 20 October 2006 at 10:17 AM

I know when I did some test a couple years back on Bryce 5, I think it was it was always slowing when you did the write to disk option it was always faster rendering to the screen only.


madmax_br5 ( ) posted Fri, 20 October 2006 at 11:33 AM

OK, just tested Bryce 6 on a quad processor Power PC G5 (quad 2.5ghz), and it does indeed use all four cores when rendering. A sample scene took 12:30 on my dual processor 2.0ghz G5, and the same scene took 5:00 on the quad processor 2.5ghz model. Woweeeee


Rayraz ( ) posted Fri, 20 October 2006 at 1:28 PM

how much faster is it per core compared to b5 and b5.5? Like 1 core b5 versus 1 core b5.5 versus 1 core b6?

(_/)
(='.'=)
(")
(")This is Bunny. Copy and paste bunny into your signature to help him gain world domination.


ariannah ( ) posted Fri, 20 October 2006 at 1:44 PM

It would be interesting to see the performance comparisons if everyone rendered the same file.  Anyone wanna pick one that was perhaps included with Bryce 6?  I'm still working on getting mine installed (am upgrading from B5 to B5.5 to B6), so don't yet know what all was included in the package and the bonus content.

I dare you, while there is still time, to have a magnificent obsession. --William Danforth


Mahray ( ) posted Fri, 20 October 2006 at 7:59 PM

There are a couple of sample scenes included in the B6 release, showing off the HDRI.  The other option is the desmon-thingy file in the 5.5 release, which would give a comparison between 5, 5.5, and 6.

Come visit us at RenderGods.

Ignore the shooty dog thing.


fpfrdn3 ( ) posted Fri, 20 October 2006 at 9:12 PM

Preliminary B6 results on the desmonema.br5, which use high rays per pixel for a simple scene/object, suggest a 30 to 40% increase in speed on the same machine setups for dual cores. I haven't seen the single core results yet, and I haven't D/L B6. Will be watching though. 😄


Mahray ( ) posted Fri, 20 October 2006 at 9:26 PM

On a single core machine, with desmonena.br5 -

Bryce 5     - 19:57
Bryce 5.5 - 13:43
Bryce 6     - 13:27

Come visit us at RenderGods.

Ignore the shooty dog thing.


fpfrdn3 ( ) posted Fri, 20 October 2006 at 10:24 PM · edited Fri, 20 October 2006 at 10:25 PM

Hi, ...According to Mahray's benches;

Bryce 5.0 -->B5.5=31.3% increase speed.

Bryce 5.5 -->B6.0=1.19% increase speed.

Single core... Thanks Mahray  😄


madmax_br5 ( ) posted Sat, 21 October 2006 at 1:00 AM

I get a 76% speedup in rendering when using dual cores.


Mahray ( ) posted Sat, 21 October 2006 at 2:21 AM

76% sounds about right for dual cores, you won't get 100% due to various overheads.

Who wants to buy me a quad core for Christmas?

Come visit us at RenderGods.

Ignore the shooty dog thing.


eyeland ( ) posted Sun, 22 October 2006 at 9:09 AM

One more set of benchmarks to add. I don't have 5.5, so can't run the desmonema scene. I created a simple quick scene with default B5 sky with 5 large metaballs,  4 of which used transparency.

My config: dual pentium4 3.00GHz, Windows XP Pro, Bryce running standalone

B5:

Normal anti-aliasing, fast preview mode 2:13

Normal anti-aliasing, regular mode 4:02

B6:

Normal anti-aliasing, fast preview mode 1:26

Normal anti-aliasing, regular mode 2:16

That works out to 35% increase for fast preview, 56% increase for regular. CPU was at 48% for B5 & 99% for B6. Also noticed that file size decreased - B5 was 135kb, B6 was 74kb. I'm not particularly interested in using Bryce for creating realistic scenes, so I'm not sure that HDRI will have much value for me, but for the rendering speed improvements alone, I can't really think of a better value for $6 (and I also pick up the vastly improved preset library management - which I believe was introduced in 5.5?)... 

"Every child is an artist. The problem is how to remain an artist once we grow up." - Picasso


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.