One of my biggest reasons for getting a new computer put together is for Poser. I'm tired of being limited in what I can do in a scene. Tired of lock-ups. Tired of waiting.

I'm going from an Athalon 800 with 380 megs of memory to the following:

Athalon XP 3200 Barton, 400 Front system bus.
Gigabyte 7nnxp Motherboard (Which can do 400 bus speeds)
Matched pair of 512MB DDR 3200 400FSB for 1 Gig of memory
Hard drive, down the line, will be a SATA 120-220 Gig 7000RPs.

What I expect with this configuration is this:

I click on Poser, and within 3 seconds my 50Meg PZ3 is opened and ready to go.

I can load up to 4 Millenium figures with clothes and props in a scene without any problems whatsoever.

I can render as much as I need to, and even the biggest renders take only a minute or so.

Are my expectations realistic, or will I be disappointed?

I really want Poser to cook...the technology should finally be there, yes?

-WTB

OH dear :( It'll still take longer than 3 seconds to load a 50Meg pz3, even with a gig of ram on my machine it takes 20seconds just to load poser & that's without a default figure. (Athlon XP 3200 runs at 2.6Ghz, got one of them myself) You'll still get slow down if you load more than 2 figures with accessories but it's not as bad as you'll get with your present machine. No chance in hell of getting it to render in under a minute with 4 figures loaded, but it'll be faster than now. The only way any of us will ever get performance like you want is with a Cray or something like that. Don't forget to shut off all the crap XP loads up in the background when you get it ;)

Not totally non realistic, but somewhat optimistic about render times. Are you using P4/PP or P5? Even with P4/PP you can expect some of your renders to take considerably longer than a minute or so. With Firefly, 30 minutes is not uncommon if you're rendering reflections. If you really, really have the need for speed why not take a look at an Opteron rather than an Athlon?

With 2G of Ram, 1.6 processor it takes PPP at least 2 minutes to load up....I think all has to do with how big your runtimes are in the loading up factor. I think your expectations are way to high. However you will see some nice improvement, just not as grand as what you have listed.

I'd recommend 2GB of RAM if using P5, and bear in mind that your new computer will be almost as slow as your old one, if not as slow. No - I mean it. You WILL load up Poser and scenes to the point where you cn only just bear it. It's human nature and it's certainly been the case for the last 20 years worth of computer use - the faster computers get the more or better you do with them, by using the available speed to do more/better in the same time. Cheers, Cliff PS but never go back. Never ever go backwards. It's impossible to cut back on quality again, and the waiting times...gnurgh!

Whether there will be joy or disappointment is largely a function of your own expectations..... Especially when the expectations meet up with the reality.

I'm using P4 Mostly. I have P5 but really can't do much with it with present configuration. Also, I'm using Win 98 for now, and for a while after getting new system set up. That is, until I get the new Hard Drive, I'm going to stay with 98. -WTB

What exactly goes on with computers? I mean, I'm going to almost triple my processor speed, Memory and quadruple my system Bus. THe SATA drive can transfer something like 500 Megs per second if memory serves. Where is the bottleneck? Why would Poser still be so bloody slow to load? Thanks. -WTB

The bottleneck could be Windows 98, with it's notoriously defunct memory management. Upgrading to Windows XP or Windows 2000 may resolve some memory issues.

98 is absolutely awful with memory management. It's notoriously flakey with more than 512 MB too. If you're getting 1GB or more RAM, you really, really need to ditch 98.

Okay, forget about 98... What I want to know is why, when the hardware capacity is tripled/quadrupled, why isn't performance??? -WTB

William what you need is to get things into prospective. Try Bryce or Vue! When you get used to how long they take to render, you can then go back to Poser and go "WOW! This is FAST!". ;) LOL!

I agree with Who3d. I went from a P3/800/512MB and 20MB HD to a P4/2.6 with 1GB Ram and 240MB HD 12 months ago and don't regret it ome bit. The bottom line is that for small Runtimes and simple scenes it is a lot faster, however you can do a lot more with it as it doesn't choke on on 2 Millenium figures with large textures any more. My Runtime is now 40GB and it does take a long time to load but I can have lots of figures and/or better lighting and I don't have to downsize texture maps any more. If you want fast loading and renders just do one figure/prop at a time and composite the pic in a paint program. I mainly use PP and ocasionally use P5.

I use Vue Pro (multiprocessor enabled) on a dual Xeon 2.66GHz (large L2 cache), 533MHz FSB, 1GB RAM, 3 80GB 7200RPM drives, NVidia GeForceFX 5900 Ultra (256MB and AGP 4x/8x) system running Windows XP Pro SP1. Vue Pro is slow as molasses in renders and even slower in interactive adjustments - it is worthless to do even a mildly complex scene on something of a super computer. Poser 5 isn't much better (but definitely better than Vue Pro). Runtimes definitely effect Poser startup. And more memory will help using large scenes (but don't forget about the memory limitations and leaks of Poser 5).

The main reason is how the code is written; and what it has to do. If the code is written to hit the processor with everything it's got, then that can slow things down. If you have a bunch of libraries of items, those have to be searched whenever you want to add or modify somthing (I'm assuming..;) If you're adding a lot of lights, reflections, details, characters, etc., it has to calculate all of them and how they interact. It will speed some things up, but never underestimate the ability of software to tie hardware up in knots..it's been my bread and butter these last 17 years..;)

Pretty Unrealistic expectation. I have a 3ghz P4 with a dual SATA raid 0 and 2 gigs of RAM. I saw a dramatic increase in performance over my Dell 1.9ghz with a puny 256 megs of ram, but It's not quite what you want. :D

William, You asked why, when hardware capacity has risen, why wouldn't performance? Pakled pretty much nailed it - all of horsepower in the world, in terms of hardware, won't help run bad code - it just makes errors faster. Since you will be doing the obvious (ditching win98), which will help dramatically with Poser's performance, there's not much more you can do. Perhaps when Poser 6 comes out, Poser's speed will become a function of your hardware speed. Right now, it's not - Poser's current speed is a function of it's own (at times, bad) code. Certainly, some things will help, and you WILL notice a performance jump with your new machine - and an even greater one when you get WinXP - but you need to tailor your expectations somewhat. Jack

Additional: Computers are rarely actually as fast as you think they are. For example, if you get a PC with a CPU three times the speed of your current CPU, it won't be three times the speed of your current CPU. That is to say, on paper, executing code already in the on-board cache, your new CPU may be three times the speed of your old one. It MAY execute commands at three times the rate/frequency - but that is far from the end of the story. For example, the CPU has to communicate with the RAM. RAM is, whilst hugely faster than a hard drive, notoriously slow when compared to CPUs. We've been "stalling" our CPU's to slow them down when dealing with RAM since at least the days when we had 386 processors (back even further if my dim memory serves me correctly). RAM has come along greatly - indeed it's often quoted now in terms of frequency rather than response time, to make it easier for people to judge the comparative speed of RAM when compared to CPU (or motherboard). Of course, it doesn't help that there are several speeds of "Double Data Rate" RAM, but that's an aside. You'll probably have RAM that's rated as being about 400MHz, yeah? Your CPU has to slow down to that speed to access it - so whenever you load a figure, or post it, or...well, anything really the CPU is likely to have to slow down to RAM speed for chunks of time. There is an excellen chance that you won't be thripling the speed of your RAM and the speed of your IDE controller (it was probably a UATA already) and the speed of your graphics card and even if you did there's a bunch of other stuff on the motherboards chipset which hasn't tripled in speed. Windows98 in particular sucks (though not as much as Windows Me!). I love it dearly, but it's not for 3D and not for modern software :( If you triple the size of your RAM you ARE going to load more into it. If you have managed to triple the speed (I doubt it) then effectively you'll have stood still... if you haven't then that aspect (the RAM) could even feel slower at times (but only because you're doing more). Change OS. If you stick with P4 and don't put too much RAM in (I had some odd memory-related issues with Poser and P4, ESPECIALLY when I had Win98 - that was really bad!) it should fly in doing what you currently do. But I'll bet you 100 that you end up doing more and better with it until it feels slow again.

I have run 3d software on an Amiga, PC, and Mac's and I can give the first rule and only rule. No matter how fast the CPU No matter how much RAM No matter how large the Hard Drive IT IS NOT ENOUGH!

As who3D indicates, the memory bottleneck is one of the biggest performance hits in any machine. This is particularly true in graphics apps, which tend to be very memory hungry. Instructions are executed in pipeline in a CPU. The number of pipeline stages varies between architectures, but a grossly simplified version is something like: fetch instruction, decode instruction, fetch data, perform instruction, store data, update program counter. Each stage will take some number of clock cycles. Modern CPUs can execute multiple instructions at once because they stagger the instructions by pipeline stage. When the first instruction moves from the fetch to the decode stage, the next instructon can enter the fetch stage, and so on. Thus, the more deeply pipelined the architecture, the more instructions can execute at once. However, sometimes a stage like fetch data can take a LARGE number of clock cycles because of the relatively slow access to memory. When this happens, the entire pipline will wind up stalling until the fetch is completed and that instruction moves on to the next stage. This a major reason that CPU makers try to squeeze larger and larger on-chip caches onto CPUs. The cache stores the most recently accessed data, so that hopefully the next time the CPU needs a piece of data, it will be in the fast-to-access cache and the CPU won't have to go get the instruction from main memory. Generally, a system has multiple caches, organized in levels. The fastest to access are the smallest, and they get progressively larger and slower to access. So, there may be up to 3 levels of cache before you get to main memory. Unfortunately, most people's use of modern graphical applications overwhelms on-chip (and even off-chip) caches pretty quickly, so there is a lot of main-memory access. This is where algorithm designers can do a little to help. If you can design algorithms that have good locality of memory access, then caches will help more. In graphics apps, you are still going to have to access much more memory than will fit in a cache. But if you have multiple operations to do that will hit a particular memory location, you want to try to design an algorithm that will do all those operations at once to each piece of data, rather than doing one operation to all the data, then the second operation to all the data, etc. For example, in 2D image processing, suppose you are performing a simple emboss operation and converting to grayscale. You could do that faster by iterating over all the pixels in the image and for each pixel, calculating RGB values for the emboss operation and the grayscale operation, rather than iterating over the pixels twice and doing the emboss operation in the first pass and the grayscale operation in the second, for a number of reasons. One, you will not have the loop overhead twice, but more importantly, you will probably have to load each pixel's data from main memory only once instead of twice (assuming the image is larger than will fit in the cache, of course, which it likely is). OK, wow, I just rambled on a great deal about that. Hope it was interesting to someone :) -Jeremy

gad..and I was trying to keep it simple..;) next thing we'll start prattling out about branch prediction and machine code..;) In other words, your speed is limited by the slowest components used by the software. More and faster is better, but don't expect miracles..;) It's like taking a long trip on a highway.. you go miles at 65, but then there's 2 blocks downtown that you can do 300..;) speeds up things some, but doesn't make much difference on the whole trip..;) just get the best system you can afford; that way it stays current longer. Good luck.

You guys are just way too spoiled. I remember rendering my first Lightwave 3d picture, 320x200, and I think it took 36 HOURS to render. No image maps, no bumpmaps, no reflections, no lensflares, we didn't know what those were back then. And it's not becuase poser is poorly written. turn everything on in a lightwave scene, and then wait a few hours for it to render as well. The real problem, is that we keep doing MORE with our faster hardware. Try something simple with P5, or lightwave, and each render fine.

What's the fun in that? ;0)

Hey! Dancing Demon etc on the TRS80 - Model 1 (Tandy Radio Shack) was great, and if you wanted to be really creative you could write code (basic or Assembly Language if you were lucky enugh to have an assembler) to turn green pixels on and off to create a "picture"...... ah memories... I love what I have got now.

Well, I think I get it now. I wish I didn't. The computer industry is misleading. Thanks for all the explanations -WTB

One further thing to note: Poser was originally a port from Mac. Hence I sincerely doubt the coders put much attention into speed-related issues of the code - they just needed to port it to Win. It's not the fault of the computer industry in general if the software designers can't/won't take into account the possibilities offered. Poser in particular is not well known for it's capable code - on the contrary. No matter if you got Radeon9600 and 2 gigs of RAM... if the code can't take advantage of it, there's nothing you can do about it. Contrary to many others in this thread, I believe (and have seen it many times too) that, say, tripling capacity can increase execution speed to 10 times that of original. It all depends on the quality of the software used, hardware used and the weakest link of the said hardware. Many here are Windows-only users ... in many cases Windows itself is the cause of slowness and trouble. I've heard "upgrade to WinXP" comments, but I'd never upgrade from Win2k to WinXP in hoping to get better Poser-performance - it jsut won't happen - probably the other way around. I'm currently working with a 3-processor HP-UX Mainframe ... and I can tell you that using "grep" to find out text from a 500Meg text-file executes about 7-10-times faster after the system memory was doubled a while back. If I'd be using Poser in this environment, it probably would be slower ... :D

Assembly? Bah! OK for those of you spoiled with an assembler I suppose - I used to have to enter my code into a "hex loader" into a ZX81 - so I'd write the assmebly by hand and convert it to hex in a notebook before typing in the hex code. Now THAT is programming! (wrote a couple of games that way, among other things). WTB: The computer industry tells the truth in much the same way as politicians do. They tell the parts of the truth from the angle which will make such "truths" most effective/appealing to you. They simply ommit any facts that would be unappealing. The overall effect is much the same as if they lie big time. I'm in the industry, and they lie to me too :( I've really enjoyed some of the stuff you've given the community for free WTB (Buffy, Spike) so I want you to enjoy your new PC and do more with it, happily - I do NOT want to devestated and going "well yeah it's faster, but not THAT MUCH!". A realistic appraisal beforehand should hopefully have you enjoying the new speed instead of cursing it for not being what you'd like. Windows is A cause of slowness, as is the Mac-ported code for Poser. It's not up-to-date and frankly doesn't benefit from even the optimisations in newer compilers. Even using newer compilers presents problems, as optimising for the newest, fastest CPU usually means that a program wil lrun *even slower) on an older CPU - so should a programmer optimise for slower CPUs and have a slower top-end but a more level playing field, or should he compile to produce the fastest results on the fastest computers and leave legacy users "in the lurch"? Problems, problems... certainly if you triple the speed of various components AND upgrade the software to a model which makes use of updated CPU instructions/optimisations then one can see more than a tripling of speed. The general case however in the real world of Window suse is that just replacing the hardware does not perform miracles - not even the ones that simple math suggests should happen :( Upgrading from Windows 2000 Pro to Windows XP Pro would not result in speed improvements - quite the reverse. A number of people who have done so have stripped XP down as much as possible. While Win2000 is a very different beast from Win98 (one is basically Windows NT 5 while the other is basically Windows 95 ver E). If you strip enough out of WinXP is basically becomes Windows 2000 Pro, so you have improved memory management etc... but as far as I'm concerned there's not a huge benefit in upgrading from 2K to XP just to downgrade your XP installation - especially given the Pace-like copy protection built into all XP products. Cheers, Cliff

Hey, you missed one! Memory bandwidth is one bottleneck; the next bottleneck is the Hard drive access. And that one impacts speed more as you hit the swapfile. William, you -might- want to consider moving from that XP-3200+ over to an Athlon 64 2800 or 3000. The reason is simple; the memory controller is -in- the CPU itself, not in the northbridge. That alone improves the memory access time, as you do not have to step the signal down. The cpu accesses the controller at it's native speed, and the memory is free to run at -its- best speed. The price is not that much higher, and you can run in 32bit native mode, and have a ready to run upgrade path to 64 bits when the OS is finalized and the porting starts. Giga-byte has a nice board, the K8-VNXP, that has dual SATA raid channels, 4 EIDE ports (two are standard, 2 are for RAID...and they all can be used for stand alone drives. I'm running this board now, and have 4 varying Ultra 133 drives on the EIDE, and a 120gig SATA drive that I'm running my hog apps on, like VuePro. Basically seeing how well they perform on a serial drive), lots of USB 2 ports, and a nifty little plugin power regulator that doubles the power smoothing for your system...or in case the motherboard's regulator fails, can take over for it as a backup. One thing that can speed up P5's launching time is by tricking it. Create a runtime called 'null' and get into the habit of setting Poser for that one whenever you shut down, so that it is the runtime you access again at startup...and install =nothing= into it. P5 only reads the runtime active at startup, and this can get the program up and running quickly. Switching still takes time, but the switch is faster, since Poser isn't trying to initialize itself and read and multigig runtime at the same time.

Get rid of Windows98 second ED, I have windows 2000 and can loaf=d lots of stuff. When I had 98 with 512mg ram it crash 3-4 times a day. I still use the 98 for the internet, but do not have my new computer on the internet.

Yep like Turtle Win98 crashed all the time for me, but in the last 2yrs since I got XP it's crashed maybe a dozen times & most of those crashes were caused by me doing something stupid ;) Dale the null runtime is a brilliant idea, thanks for the tip :)

I have Win 2000 pro on the art machine, and except for the fact that I can't run Vue 2 (it says so in their tech support..:|), I haven't had any problems..

Your ram is useless with 98-- upgrade to 2k or XP and pare down every piece of crap tht loads with the system-- like use classic windows rather than "pretty" xp windows. I haven't loaded my 3G puter yet, but on my 2.4 Pentium 4, 2Gs RAM, it takes 10 to 15 minutes to load Poser. This is my fault. I haven't optimised it. With P5, the 5 Runtime should be as lean as it can posssibly be-- that means Daz Injects/Rem files and Rdna Microsm files are the only ones that really need to be in there along with geometries. Then, P5 looks for objs in it's own runtime first-- you can and should consolidate all your geometries in one-- same with textures-- but put them somewhere else. run Correct reference, it no longer has to search every single runtime you have. These tips and more are all over on PoserPros tips for Poser 5 [poserpros.com] I hope SR4.1 works for you because it made all the difference for me-- very fast renders, though I still can't get it to do a Firefly one. I'm hoping that's because I haven't cleaned up the texture files. 2 3 generation models in under 5 minutes-- 1800 by 1500. I have every hope of getting three unimeshes in one render. Usually I eke out the rest in Mike 2 and Steph the original.

Win2k Pro is probably the best of the Windows OS's out there so far as graphics programs are concerned. All the eye candy that they shoved under the hood in XP can get into some serious virtual pissing matches with things like Vue, Poser, Max, Truespace, etc. Yeah, I was kinda surprised when I didn't -need- anything in that null runtime folder, actually...not even the directory tree for the libraries. And P5 comes up in about 16 seconds with it. I did mis-state one thing, though. -Switching- the runtimes doesn't involve any time delay; P5 will only read a new runtime library when you =open= it for the first time that session. So there is no delay in switching runtime banks, and if you only open, say, the character library, then the only read time involved is for -that- library...so you don't have the time penalty for the whole runtime read that you get starting with a loaded runtime.

If you want speed, ditch ALL operating systems and electronic hardware. Go pencil/paper or paint/paper. Loading time <1 second, rendering time <1 ms, only bottleneck is users hand-eye coordination. Cost is relatively low, enviromental friendly. No constraints to your immagination. Instant gratification. .

Instant gratification? I want some. NOW! Gimme gimme!!! Slight bottleneck. I've drawn the first few frames of my animation, on the paving slabs in the garden - but I'm not sure how I'm gonna play this one?

Addendum the 2nd; And if you use PBooost to parse out the libraries into multiple libraries, it speeds the actual reading up a little bit more. The only gotcha is that if you install something and P Boost is set for other than the default directories, your content will go into those selected directories. Very easy to loose things that way..... :