Thu, Nov 14, 1:48 PM CST

Renderosity Forums / Bryce



Welcome to the Bryce Forum

Forum Moderators: TheBryster

Bryce F.A.Q (Last Updated: 2024 Nov 12 7:03 am)

[Gallery]     [Tutorials]


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


Subject: slow render on mac


Melvin ( ) posted Tue, 12 December 2000 at 12:05 AM ยท edited Thu, 14 November 2024 at 5:01 AM

is there anything i can do to decrease render time ....i have 128 mb, and 92000 mb allocated to the app why is it so damn slow......


Melvin ( ) posted Tue, 12 December 2000 at 12:06 AM

opps...thats 92000k


Flickerstreak ( ) posted Tue, 12 December 2000 at 3:40 PM

There are lots of things you can do to decrease render time. first: memory will not help your render time very much at all. The only time it will help is when you (a)have a very large and/or complex scene and (b)you have enough real RAM that the computer doesn't have to swap to the hard drive (using virtual memory). Having more memory will, however, let you manipulate larger scenes with more lights, before Bryce crashes on you complaining about "not enough memory". Make sure you're not running other applications in the background. If you're listening to MP3 music from your computer, for God's sake turn it off! Decoding MP3's is a sure-fire way to slow down your render process. The only real way to reduce render time is to reduce scene complexity (or to buy a faster computer). Often this can be done without sacrificing quality. The big killers for render time are: 1) highly complex textures 2) volumetric materials 3) lots of light objects 4) highly detailed imported DXF/OBJ meshes etc. If you have lots of lights, you can cut down by using 'fake' lights for the smaller/distant lights... just use a sphere with the ambience setting really high. Unless the texture is going to be viewed close-up, complex textures are a great way to bore yourself watching the little render progress line march down the screen. Simplify textures on distant objects. If you're running on anything slower than a G3 you're going to be somewhat disappointed in Bryce's performance, no matter what you do. I upgraded from an old 7200/90 to a G4/400 last year and did test renders: the G4 took under 1/2 hour on my detailed test file, and the 7200 took over 17 hours!


loderunner ( ) posted Thu, 14 December 2000 at 2:58 PM

The reason Bryce runs slowly on any particular computer (be it Windows PC or a Mac PC) is because it does all of its work (the rendering) in the CPU. It's all fractal math, so the better math (FPU) CPU you've got the faster Bryce renders. Fancy GFX hardware and Lots of real RAm are of little use. My laptop (366mhz w/32mb ram) can render some stuff faster than my desktop (333mhz w/128mb ram). Cas in point: its 99% relted to your CPU.


Flickerstreak ( ) posted Thu, 14 December 2000 at 3:36 PM

I would highly discourage anyone from running Bryce on a system with only 32 megs of RAM - you can get away with 64 if you're running an older operating system, like Win95 or Mac OS 7.5. - and 32 megs of RAM can be had for about US$30-$40. If you're running Mac OS 9 or Win ME/2000, you really ought to have 128 megs of RAM anyway... these operating systems just don't perform stably with less than that. you're right though: RAM doesn't do a darn thing to speed up renders - EXCEPT if your system's virtual memory system has to get involved. You always want to have enough real RAM to keep the entire Bryce memory partition in real memory when running, plus a little extra: otherwise, the program will be swapping memory to disk regularly, which can cause huge slowdowns. lots of RAM is needed, however, when opening large scene files. I have a couple I'm working on right now that are over 50 megs, and several postings here on R'osity and other sites come from scene files measured in the hundreds of megabytes in size. If you can't fit the entire scene file into memory, Bryce will either fail to open the file, or crash ungracefully after opening it. Since Bryce doesn't take advantage of the G4's vector processing unit (which uses 32-bit floats: Bryce works in 64-bit doubles), if you want to render the absolute fastest possible, buy a PeeSee at 1.3GHz or more... I think the 1.6's from AMD are out. That should cure your slow-render blues :^D Hopefully Bryce 5 will fully support the G4's vector unit, Mac OS X and multiple-processors - resulting on screamin'-fast renders.


loderunner ( ) posted Thu, 14 December 2000 at 8:51 PM

you're absolutely correct. I have a scene I was designing at school from imported objects and the scene contains over a million polygons and the .br4 file was 16MB. With Win98SE eating up 30 of the 32 mb of ram, the hd was chugging away trying to manage the textures and objects. it couldn't even make a first pass render in less than 2 hours! I've never had Bryce crash on my Windows pc though. It just chews up all my cpu time. (my 333 is overclocked to 416). oh well, this summer I get a job, some investments come through and I is getting a loaded custom system :)


Flickerstreak ( ) posted Fri, 15 December 2000 at 11:05 AM

ah.... the benefits of protected memory. Although I have had Bryce puke out and crash on me once or twice on win 2000 on my laptop. It's pretty interesting: I've got a G4/400 Mac at home, and a P3/500 laptop at work (that I carry with me on a train commute). I can do head-to-head comparisons between the two systems.... and they're pretty well identical for render speed. I rendered the same scene on both machines: the times were 16:54 for the G4/400, and 16:08 for the PIII/500... go figure! One of my co-workers got a new system (at work) with a 1.3 GHz processor... I'm eager to sneak in some time and see how fast Bryce runs on it :-)


loderunner ( ) posted Fri, 15 December 2000 at 11:47 AM

YEAH BABY!!! They redsigned the CPU core for the P4 and the math section is way stronger: 4 operations per clock cycle! PcMagazine sometimes uses Bryce as one of their defacto tests for CPU comparisons. The P4 slaughtered the PIII. YEEEE-HAAW!


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.