Sun, Nov 24, 8:35 AM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 21 6:06 am)



Subject: Poser 5 memory usage?


Gromit ( ) posted Thu, 08 January 2004 at 9:38 AM ยท edited Sun, 24 November 2024 at 7:26 AM

I recently bought a new Micron PC with a 3.2GHz processor, 2Gb of RAM and 300Gb of hard disk in a RAID 0 array, running XP Pro. It's a real breath of fresh air after my old dual-200 MHz workstation. Now here's the question: I also recently got Poser 5 and I've been rendering some animations. It renders a simple 1050-frame 320x240 using Firefly in about 55 seconds. But when I check the performance monitor during this render, it looks like only about 500Mb of my 2Gb of RAM is actually getting used. The processor is running at about 50% usage. I thought Poser would use all of the available RAM, but that's not the case. Is there a program configuration I'm missing here? Gromit


biggert ( ) posted Thu, 08 January 2004 at 9:51 AM

show off.... think about this....if it takes you 5 mins to get from your house to the closest neighborhood walmart going 30 miles an hour (the speed limit)....would that time change if you go from a V4 1986 Toyota to a 2003 BMW Z4? heck no! assuming you follow the speed limit right? so why would the rendering speed decrease to 1 second just because you pump up your computer with 2 TONS of memory n CPU?


FishNose ( ) posted Thu, 08 January 2004 at 10:52 AM

biggert, I think you missed the point totally lol... Poser uses only as much RAM as it needs. The space it occupies mostly has to do with the number of and the size of the textures you are using - and of course the numbers of objects/figures using them. So try doing a scene with 5 Vicki 3's with all their MTs loaded and big textures (different ones) on each - plus bumps. And render. THEN we'll see how much RAM it can occupy! And the speed of the CPU means a LOT in Poser rendering times. :] Fish


Lawndart ( ) posted Thu, 08 January 2004 at 11:02 AM

biggert: Using your analgy I would say that Gromit wants to get a speeding ticket. LOL Gromit: You can also increase the size of the bucket in the render settings. This consumes more memory and should speed up the rendering a bit. It may buy you a little time on rendering but I don't know how much. In the rendering world any time gained is less money spent. What it is doing is increasing the pixel size of the block that Firefly renders. I have a Dual 2gig with 2gig of ram and was thinking of an upgrade. It sounds like you noticed a big difference yes? Cheers, Joe @ 3-AXIS


Gromit ( ) posted Thu, 08 January 2004 at 1:09 PM

Thanks very much for the information, Fish and Joe. The render I did was pretty basic, actually an old animation I had around from Poser 3, one figure with one texture. I just wanted to get an idea what this system with Poser 5 would do. As I've mentioned in some other threads, Joe, I'm working my way through your video. This is great stuff and I expect to be doing some much larger animations soon when I get on my feet with this version of Poser. I'll do some playing around with the bucket size and see what difference that makes - sounds like a good idea. A big difference from my old system? The old one is a seven-year-old Intergraph workstation, dual 200 MHz Pentium Pros and 512 Megs of RAM. As I recall, this same render took about 45 minutes on it, so yes, there is a big difference. And yes, as you said, time is money. Gromit


narsil ( ) posted Thu, 08 January 2004 at 1:17 PM

Hi there The 50% cpu thingy is probably the Hyperthreading - if you press crtl alt del and bring up the task manager- tab to processes and look for poser.exe highlight poser.exe and right click - on the menu look at set affinity - you'll probably see two cpu 's cpu 0 and 1 this is hyoerthreading working. You could switch off the HT - I found no real difference.You could set the affinity for poser to work only on CPU 1 , if you have problems with other programs slowing down.I do not and an calculating dynamic cloth in the background as I speak. set the bucket size to 64 instead of 32 - it really does make a difference, use the bucket size in octets (8,32,64 etc) it works then. thats all folks


Drew2003 ( ) posted Thu, 08 January 2004 at 1:27 PM

I am running an Athlon FX-51 with 1GB of memory on a dual-channel mobo (nForce 3 chipset). It sounds like I might be able to gain a bit using this "bucket size" setting, also. Does this make sense or am I missing something? - Drew


Gromit ( ) posted Fri, 09 January 2004 at 12:19 AM

narsil, Yes, this is a hyperthreaded processor. In the task manager it displays as two processors, both of them working at approximately the same level, roughly 50%. I was just a bit surprised at that because I've seen multi-processors run at 100% for extended periods, working to their limit to process a task. If you screw up and install Microsoft's Findfast on a server you can get to see that happen as it brings the whole system to its knees while it tries to do its automatic indexing of every last file. I haven't had a chance to try it yet, but I suspect that this bucket size may be the bottleneck that's limiting the throughput to the processor, but we'll see. Thanks also for the info about the bucket size increments, that was my next question! Gromit


Gromit ( ) posted Fri, 09 January 2004 at 12:26 PM

Ok, I made several tests, raising the bucket size first to 64 then to 128. I couldn't see any difference in the render times or in the processor/memory usage. I then tried increasing the render size from 320x240 to 640x480, keeping the bucket size at 128. As hard as it was for me to believe, the render time was still almost exactly the same, but the processor usage increased to about 60% and the memory usage went up by maybe 30Mb. Evidently this particular animation is so trivial that it's hitting some kind of fixed overhead of the renderer that has a much greater influence than the actual computation involved. I could probably render the same number of empty frames in essentially the same length of time. Gromit


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.