You guys might remember my rant from a few months back, of Poser7 just randomly crashing. Fixing some nvidia settings fixed that right up.

Unfortunately the slowness poser7 has brought me this time is pretty much halting any work/desire to work.

My runtime is only 17gb - im sure about 8gb of that is random texture PSDs, i don't use externals. 

I reboot daily ( Poser will not function if i try to run it after my system's been in use all day )

I do virus checks and defrags and all that so my computer health is great. Everything else runs great. Photoshop, DAZStudio, even heavy games like Age of Conan.

It's just a poser thing :/

It just took roughly 10mins to render a 91x91 thumbnail with V4's head + 4blueeyes lightset (classic)

in the material room, trying to load image maps, it used to be fast, click browse > bam dialog window. now it takes several seconds ( up to 15 ) for the dialog to display, once I pick a texture its another 15+ seconds of "refreshing" the material room view.

Anyone else had this problem and found a fix?

Running:
WinXP Pro SP3
4 GB ram  ( with or without /3gb switch, poser still runs slow )
2.13ghz dual core intel
500gb 7200rpm harddrive

Hi!

Theres a file at:
C:Documents and SettingsYOURSApplication DataPoser 7 (enable show hidden folders)
That one can delete and the Poser builds a new one when it starts up.

YOURS = different for each user

I dont know exactly wich one but maybe someone else can help you with that (maybe its LibraryPrefs?)

Dont delete anything until someone who knows exactly replies, or search this forum for the one suggested by me.

Regards / Joony

you mentioned defrags and virus checks--- may be a stupid question:  However, have you cleaned out your temp, registry, cookie files etc.?  The garbage collected in those files have a habit of doing strange things including slow flile loads, stalling on rendering, or very slow rendering etc.  Jan

Yep I have system Mechanic Pro from www.iolo.com. It cleans all that good stuff up.

 well deleting the libraryprefs fixed the slower loading materials and textures.

rendering seemed ok until it decided to say I don't have enough memory to load a bunch of texture maps.

I have 4gigs of ram, and poser was using 1gig when it gave this error.

What on earth is going on :(

I used to be able to manage 128 bucket size, now every so often I hear it bitching at me even at 64...

Have you updated your video driver lately? If you did,  try changing your poser.ini  line boxpicking to =1. That might help.

out of curiosity, what does that do?

i'm not sure exaclty. If I remember correctly, it helps poser keep up with updates in certain video drivers. I'm not up on programing or drivers, so I didn't understand the explaination. Check out http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3180526&ebot_calc_page#message_3180526 for the disscussion.

It may have to do with the Windows indexing service. I seem to remember that some update during the last couple of months turned it on by default, you'll want to turn it off again. The indexing process itself slows things down.

Another thing that may have happened over time is fragmentation of the master file table. The simple defrag utility that ships with Windows cannot defrag system files, you'd need something like Diskeeper for that job. I'd recommend downloading a trial version of Diskeeper (at www.diskeeper.com ) and use that to do a thorough defragmentation of your drive(s).
A fragmented master file table will slow down disk access by a significant amount.

I, too, have experienced a very slow Poser 7, so much so that I hardly want to mess with it -- even though I have other memory and processor intensive stuff that runs well -- so please keep the suggestions coming for all us me-too-ers. Thanks.

I would look at tasks active by running the system monitor . Anything running in background will affect Poser. Check swapfile(virtual memory ) and make sure enough is being allocated . If you have sufficient disk just switch it to system managed . Then look later and see how much is being used.

Do a defrag in safe mode , you will get a better result, and remember to defrag any disk drives on the system .

you might want to get correct referance , it was a freebie , and make sure your file referances are correct. If poser starts searching thats going to slow things down a lot .

To get around the out of memory error, try reducing the bucket size. It always does the trick for me.

Mike

You should be able to archive your RT (or set up separate ones on a per character or per project basis) and cut its size down to a quarter of what you currently have. That will speed things up enormously because Poser reads the entire RT when it starts to build an image, and giving it 17 gigs to deal with is a bit much. I think the largest mine ever went was 3 gigs, and its rendering speed is just fine.

you could try disconnecting your internet connection from the computer too while you are rendering, as nearly all programs seem to go searching for updates (default settings) when you turn the computer on, so that is probally using a fair bit of resources while it does that, giving you less for poser and such.

in other news, if you can find a decent enough hill, dead snails can move quite fast.

Quote - Poser reads the entire RT when it starts to build an image

Which weird version of Poser are you using that is doing that?

How does Poser 7 behave with Windows Vista?

>> Which weird version of Poser are you using that is doing that?

They all have, from 1 through 7. All a Poser file is, is something that's directing the program to go find things: the geometry files, the cr2 files, the props, the textures, the morphs. They're not saved within the document; they're kept external. Even in Preview mode, all you're seeing is a rough draft of the image because Poser is assembling placeholders.

Then, when you render, Poser has to go back, find the actual files, and replace them to build the render. To do this, it has to follow the paths described in the file... but to follow those paths, it still has to read through the runtime to find the paths. And the larger the runtime, the more information Poser has to deal with in the process.

But thanks for asking. :)

Quote - How does Poser 7 behave with Windows Vista?

Works fine for me.  I was dreading upgrading to P7 and getting a computer with Vista, and to my surprize, they seem to play well together. No problems to date.

The weird thing is that Poser seems to look for the geometry/texture files in an incredibly inefficient way. I've written a small utility in C# that scans for certain files on the entire system, and it is much, much faster than Poser (easily a factor of 100) even when I direct it to do a complete file system search, not restricted to registerred runtimes... I have no idea why Poser has to be this slow.

On my previous PC, which has Windows 98, Poser 4 ran well, but Poser 5 ran very badly, and so did Poser 4 while Poser 5 was in. So I uninstalled Poser 5, and my Poser 4 returned to normal.

On my current PC with Windows Vista, Poser 5 runs OK, but Poser 4 will not run.

Based on the various comments I've read, here -- and elsewhere over the last few years -- I am beginning to think Poser may in fact be the most advanced software ever made

:laugh:,

i.e., if it likes you, no matter what version or operating system or hardware you are using, it works rather well, but if it takes a disliking to you for some reason, no matter what version or operating system or hardware you are using, you're [blank] out of luck.

:: shrug :: It's like anything else in life. Work within its limitations, and it'll do well by you. Try to force anything more out of it, and you're asking for trouble. Look at how the program works, how it reads its own files, how it sets up the tools -- and then deal with it.

Quote - The weird thing is that Poser seems to look for the geometry/texture files in an incredibly inefficient way. I've written a small utility in C# that scans for certain files on the entire system, and it is much, much faster than Poser (easily a factor of 100) even when I direct it to do a complete file system search, not restricted to registerred runtimes... I have no idea why Poser has to be this slow.

I've often wondered about that myself.  In my own experience, if I keep the actual Poser default runtime down to an absolute minimum (nothing in there but the stuff that installs by default and what very little addons that have to b) Poser runs reasonably well all things considered.

So about 98% of my content is in external runtimes, the only thing in the default runtime is the stuff Poser setup when it installed itself initially.  That seems to work ok.  If I start installing stuff into the default runtime at some point I hit whatever magic number of bytes it takes, Poser throws a fit.

It loads slow, renders slow, gives me all sorts of out of memory errors when loading textures, etc.  It's almost as if Poser builds some sort of index from it's default runtime and stores it in memory, because the larger my default runtime becomes the longer it takes Poser to load, the more memory it takes up and the more likely it is it will throw me an error when I'm trying to render.

If I keep everything out in additional runtimes instead, it seems to work fine, loads as fast as I can get Poser to load and doesn't seem to give me these errors when rendering.  Not sure why that is, Poser's memory and file management routines need a serious, major overhaul - hopefully something they will finally get around to addressing soon, since it's been like this since version 5.

I suspect that Poser 4 did not run on Windows Vista because WIndows Vista has a different way for one program to call another.I had the same when I tried to run under Windows Vista my old faithful Borland C++ 4.52 C/C++ compiler.

Quote - in memory, because the larger my default runtime becomes the longer it takes Poser to load

Sure it does, as Poser builds the library dropdown... And Poser uses also uses/follows regualar file/folder shortcuts, so it's not too hard to answer why it's slowing down when the library gets bigger... Poser 7 added a timeout for the build action to its preferences, so those not using that dropdown can change that timeout to 0 to have Poser start up with the same speed no matter how big the library gets.

Quote - > Quote - in memory, because the larger my default runtime becomes the longer it takes Poser to load

Sure it does, as Poser builds the library dropdown... And Poser uses also uses/follows regualar file/folder shortcuts, so it's not too hard to answer why it's slowing down when the library gets bigger... Poser 7 added a timeout for the build action to its preferences, so those not using that dropdown can change that timeout to 0 to have Poser start up with the same speed no matter how big the library gets.

Well, building a drop down is one thing, but not unassing itself properly from memory, that's another thing entirely. 

If my default runtime gets to a certain size Poser will start crashing on renders, throwing error messages about not having enough memory.  Timeout or no timeout, it still won't render properly, it will crash and throw up a bunch of ugly dialog boxes telling me that there isn't enough memory to load certain texture files.

If I place the same items in additional runtimes (which also have to have library dropdowns built for them on the fly, it works fine.  However, if it's in my default runtime and that runtime gets to big,  it crashes and burns - so something other than just a simple "building of dialogs" is going on here.

No matter how you slice it, that's a programming problem.

Quote - but to follow those paths, it still has to read through the runtime to find the paths. And the larger the runtime, the more information Poser has to deal with in the process.

But thanks for asking. :)

You never ever used a file monitor to see what Poser does... It only searches the whole runtime if the references in the files are completely wrong (and search depth is set to deep)...

>> You never ever used a file monitor to see what Poser does... It only searches the whole runtime if the references in the files are completely wrong (and search depth is set to deep).

Whether it's searching or it's replacing the placeholders in the preview image, it still has to follow the paths to find the necessary materials -- which means reading the runtime to do so. Poser doesnt magically transport texture files -- it goes and finds them.

And yes, this is what Poser does. It doesnt retain information; it points to information and then goes and gets it. This is what a lot of 3D programs do, because it keeps the size of the master file down to a manageable size. Otherwise, you'd be looking at file sizes comparable to those in Bryce, which holds everything in one place and creates monster files in the process.

You can stop repeating yourself. I quoted your "Poser reads the entire RT when it starts to build an image". And that's something completely different than looking for a few files according to their paths.

>> And that's something completely different than looking for a few files according to their paths

And your point? It still has to read the RT -- even if it has the correct paths. How else is it going to find them if it doesnt?

Never mind. I dont think I want to know the answer to that.

Well if Poser is doing that.. then the folks that built it are more stupid than I ever considered. There be no reason whatsoever you need to be looking thru folder Z if all my stuff is in folder A ( for a dumbed down example )

At any rate..

I downloaded a great defragger called Auslogics Disk Defrag, as well as Windows Advanced Care v2. ( both free )

I managed to render a 800x1000 scene with full DM props and light settings ( Scene #4 from Mixed Fantasy ) with V4 + Dark Kingdom outfit in 9 minutes. I was positive it wasn't even going to render!

Also, My runtime is character specific. - V4 only stuff. I tossed out all the old stuff once i realized I wasn't ever going to go back.

So hopefully the two tools I mentioned can help you others with your problems. As for now, my poser7 is running in a manageable state.

The path contained in the scene directs the OS to look up the exact location of the file in the File Allocation Table (FAT: Win9x, WinME, sometimes WinXP), the master file table (NTFS: Win2000/XP/Vista) or whatever the system is called in OSX. Then the OS will retrieve the file on behalf of the application.
This is how ALL file retrieval works, in EVERY app (unless the app overrides this behavior, as is the case with low level utilities such as disk defragmenters, virus scanners, disk imaging software and the like).
So Poser doesn't have to be slower than any other app when it comes to file retrieval. Unless it does some very inefficient processing before actually retrieving the file.

Quote - The path contained in the scene directs the OS to look up the exact location of the file in the File Allocation Table (FAT: Win9x, WinME, sometimes WinXP), the master file table (NTFS: Win2000/XP/Vista) or whatever the system is called in OSX. Then the OS will retrieve the file on behalf of the application.
This is how ALL file retrieval works, in EVERY app (unless the app overrides this behavior, as is the case with low level utilities such as disk defragmenters, virus scanners, disk imaging software and the like).
So Poser doesn't have to be slower than any other app when it comes to file retrieval. Unless it does some very inefficient processing before actually retrieving the file.

And the amount of available memory after that process should stay the same, whether the runtime in quesiton was tiny or huge shouldn't matter.  If it isn't actually loading anything into memory there is no reason why available memory should decrease.

And yet, for whatever reason, it' s been my experience that the larger that Posers default runtime gets, the less available system resources it seems to have for other things (like rendering).

It makes no sense of course, it shouldn't matter if the default library is huge, there is no reason whatesoever to read through the whole library at startup and put any information into memory, other than a single listing of file folders/files in one directory for the list you would see in this window on startup.

But apparently this is not what poser does, it seems to be reading in something, perhaps the entire directory structure, and then not unarsing whatever it is from memory.  It's  definate program bug and hopefully one they'll get around to addressing soon.

Quote -
It makes no sense of course, it shouldn't matter if the default library is huge, there is no reason whatesoever to read through the whole library at startup and put any information into memory, other than a single listing of file folders/files in one directory for the list you would see in this window on startup.

As I said, it does need to do that for the library dropdown menu... That triangle thingy on top of the content you're seeing for the current library directory you're in, that allows to navigate through the entire library structure without clicking up and down through the library. So as I said, if you don't use it, set the timeout so low that it doesn't bother reading the library for too long.

Quote - As I said, it does need to do that for the library dropdown menu... That triangle thingy on top of the content you're seeing for the current library directory you're in, that allows to navigate through the entire library structure without clicking up and down through the library. So as I said, if you don't use it, set the timeout so low that it doesn't bother reading the library for too long.

Ok, couple of quick things here just to set the record straight.  First, I am a software developer by trade, so I am aware of how most internal program mechanics work.  I understand you meant no disrespect, however in this particular instance I must point out that Posers "library reading routine" is horribly written.

It does not, for example, have the same problem when accessing additional libraries - they can be examined more or less on the fly without major impact on program performance or available memory.

However, once the primary library structure is loaded into memory, if you are correct and that is indeed what poser is doing at startup, it never relinquishes that memory again.  That is bad programming, no matter how you slice it.

First, there is no need to load the entire structure into memory in the first place, it's overkill and quite wasteful to say the least.  Posers "Library" is split into various sections, Figures, Props, etc..

The only thing required when the program starts or when the library is opened is for it to read the top level listing for whatever directory the library is pointing too at the moment.  It isn't necessary for it to load the entire listing of files and directories in the entire library at that point in time, it could easily do so on demand with almost no noticeable difference in speed on most modern systems.

Instead, assuming your theory is correct, it would seem that Poser loads the entire listing of files in it's default library into memory.  Ok, this in and of itself would be very wasteful and a bad design, however it would seem that the problem compounds itself in the fact that even if you switch from Posers default runtime to a "additional runtime" that memory is never freed up again.  It stay's locked up until you exit Poser.

And that is just really, really horrible code.  If that data is not needed there is absolutely no reason in the world why it should be sitting in memory taking up huge amounts of space and interfering with other program functions like rendering as a result.

Now, this is all assuming that you are correct and that is what Poser is doing, since I haven't seen the source code I can't say for certain this is the case, however it seems like a logical guess as to why a large default runtime would so negatively impact Posers performance.

However it is interesting to note that if such is the case then apparently they used different routines for accessing "additional runtimes" as opposed to the default runtime, as you can load a very large "additional runtime" and have the directory listing for it up and render just fine, so it doesn't seem to need to index every directory and file in it's additional runtimes the way we are assuming it does with it's default runtime.

And that in and of itself should be proof positive that if your assumption is correct then obviously they did not code the routines for handling the default library properly.  If they had simply used the same routines they do for additional libraries it wouldn't cause this problem to occur, other wise having a large "additional library" and loading it would cause the same problem.

Hopefully that clarifies my point.

i am probably lucky here because my Poser 5'sRuntime contains only what came with my Pser 5, and most oif my models etc are in my Poser 4's Runtime which is left over from my Poser 4.

Hey guys, just for the record, if I QUOTE a paragraph, then I'm responding to that paragraph and I don't care about the rest of what you've written...

Quote -
First, there is no need to load the entire structure into memory in the first place, it's overkill and quite wasteful to say the least.  Posers "Library" is split into various sections, Figures, Props, etc..

But not the library dropdown... It allows access to all sections at once... Also, remember when Poser was written... Disks were slow and thus accessing directories on the fly was slow. It even is slow nowadays. Too slow, to buil the library drop down on the fly and have AN ACCEPTABLE RESPONSE TIME. And by the way, that thingy allows access to all the libraries at once... I don't use it, so I'm happy they finally added the suggested means to not have Poser build that stupid dropdown at all...

Quote -
But not the library dropdown... It allows access to all sections at once... Also, remember when Poser was written... Disks were slow and thus accessing directories on the fly was slow. It even is slow nowadays. Too slow, to buil the library drop down on the fly and have AN ACCEPTABLE RESPONSE TIME. And by the way, that thingy allows access to all the libraries at once... I don't use it, so I'm happy they finally added the suggested means to not have Poser build that stupid dropdown at all...

Ok, first of all yes, disks were slower when Poser was written.  However they also were much smaller, able to store far less data, and even back then doing a directory listing in a standard fashion in programming never required building a second index of the entire directory structure in memory, that has always been considered a bad coding practice.

Second, assuming that there was some legitimate reason why you would want to reindex all of those files in memory in startup, not releasing that memory after it is no longer necessary is also a horrible coding practice, particularly if your premise is based on the notion that Poser was writen at a time when hardware was less advanced.  After all, were discussing a time when PC's had far less memory available than they do now.

Third, even if one accepts your intitial premise and disregards those first two points , there is no way anyone can logically argue that given the advancements made in PC's that Posers code should have long ago been updated to take into account this very basic function of it's own inner workings.  Not doing so?  Well, yes, you guessed it, bad coding practice.

Now, setting aside a moment the non-sequiter you made regarding quoting styles, perhaps you should consider the fact that no matter how you try to redirect or obfuscate the facts, the facts are that Posers internal library routines are 1) Poorly written and 2) Badly in need of an update, both of which are the only two points I wished ot make in the first place and neither of which can really be successfully argued against.

So, perhaps we could now move on to something a bit more constructive in the nature of conversation?

>> Now, this is all assuming that you are correct and that is what Poser is doing, since I haven't seen the source code I can't say for certain this is the case, however it seems like a logical guess as to why a large default runtime would so negatively impact Posers performance.

And here's proof.

Open Poser.

Hide it.

Add something to the runtime -- doesnt matter where: geometries, libraries, textures, I dont care. Just put it in.

Un-hide Poser.

Try using the drop-down menu to find the stuff you just put in.

You wont find it. And the reason you wont find it is because the stuff in the drop down is previously read runtime materials -- all of them. The only way you'll find the new stuff is by going up the library tree to the runtime listings, then work your way back down.

That's Poser re-reading the entire runtime, guys.

Uhm, you don't have to go up all the way. One level is enough, Poser rereads the current folder. Switching library type also works.

Quote - Now, setting aside a moment the non-sequiter you made regarding quoting styles, perhaps you should consider the fact that no matter how you try to redirect or obfuscate the facts, the facts are that Posers internal library routines are 1) Poorly written and 2) Badly in need of an update, both of which are the only two points I wished ot make in the first place and neither of which can really be successfully argued against.

All I told you was what Poser does and why it does it... You know, that's why I said, I only respond to the part of the posts I quoted... I even told you that they added an entry to the Poser.ini to stop Poser from reading the runtime. But it's fun to see that you're not interested in any information at all you just want to spread your "facts"... Poser's not utterly slow, just write the code to read directories and directory shortcuts yourself and then come back and tell me how much faster you got it using standard coding techniques... It just takes more time than simply reading directory information...

Quote - All I told you was what Poser does and why it does it... You know, that's why I said, I only respond to the part of the posts I quoted... I even told you that they added an entry to the Poser.ini to stop Poser from reading the runtime. But it's fun to see that you're not interested in any information at all you just want to spread your "facts"... Poser's not utterly slow, just write the code to read directories and directory shortcuts yourself and then come back and tell me how much faster you got it using standard coding techniques... It just takes more time than simply reading directory information...

I am a programmer - facts and hard data are what interest me, not innuendo, back handed slaps, or circular logic.  Posers internal library routines are poorly written, that is a fact.  They need to be updated, that is a fact.  Even though these facts have been very plainly stated and proven by any reasonable doubt, you seem to insist on ignoring them, apparently because they prove your original premise, that there is nothing wrong with Posers internal routines as written, to be incorrect.  However as a programmer I understand that all circular logic leads to is an infinite loop that locks up your system, again an example of very poor code and not something I'm interested in engaging.  

I am no longer interested in continuing a conversation of a circular, repetitive, neverending nature.  I have entirely too many other things to deal with, and this is no longer proving productive. 

Now, you have several choices of your own in this matter, acknoweldge that your original premise was indeed incorrect , continue to press the point that there is nothing wrong with Posers internal routines or that you were right all along despite all evidence to the contrary, or pretend that none of this actually took place and ignore everything you should have learned from the above postings.

Option A would earn you a modicum of respect from both myself and probably from other onlookers as well, because it would prove that you are a person of intellect who respects logic and can admit when they drew a conclusion based on incomplete factual information.

Option B & C, the optiosn you've thus far chosen to implement in your debating of the topic, will simply continue the circular, never ending, "noI wasn't wrong despite the facts" logic loop that you are currently stuck in.

I have no desire to continue travelling such a loop with you, however, as I am far to busy for such things and try to only take part in conversations in which worthwhile information is exchanged and both parties benefit from such exchange of information. 

So I hope that  you will consider this carefully before responding, however rest assured that any further attempts to recircle the conversation will not garner any form of response, so feel free to get in the last word and prove to us all that despite facts, reason and logic you were right and everyone else was wrong.  I'm hoping that I've misjudged you and that you are above such things, but I suppose we shall see in the next reply.

I stopped reading your text after you used the word "fact" again... 

Quote -  I have 4gigs of ram, and poser was using 1gig when it gave this error.

Have you given any thought to adding a Flash Drive and assigning it to virtual memory?  Aside from the other tricks you've done to help yourself, you could add another 4GB USB flash drive to do swapping and it would be much faster than your hard drive.  Flash drives are dirt cheap and extremely handy to have.

I, too, am an Age of Conan player, and I've discovered that AoC has some serious memory leaks.  It doesn't close itself down and clean up after itself well, so after a session of AoC I always do a reboot if I'm going to play in Maya or Poser.

Another great utility to have that's also free is Process Explorer.   It's free, from Microsoft, and is one of my favorite tools when I'm trying to figure out what my machine is doing behind the scenes.

I had a very slow poser 6 7 and pro, so slow it was unusable. Latest ATI video drivers fixed it back to normal.

i have an xp system, about 756 mb of ram, a 30GB hard drive and less than a gig processor
works fine for me, not the fastest shit in the world but im able to animate and render effectively.
i do have to make my objects boxes when i have too many objects but most industry proffessionals work strictly with wireframes/boxes unless modelling or rendering.

the whole lookin for files slows it down thing may have some effect but i wouldnt dwell on it too much,
it sounds like your graphics card dude,try upgrading, you have seen my system specs,
not too great huh, im working on a tablet pc so no chance in upgrading graphics cards but luckily mine packs a pretty strong stink although the rest of my system isnt too hot.

from renderdog2000:

Quote - I am a programmer - facts and hard data are what interest me, not innuendo, back handed slaps, or circular logic.

from Dizzy:

Quote - I stopped reading your text after you used the word "fact" again...

Yeah. I know nobody asked me (and quite likely nobody cares), but I've done a fair bit of programming myself in various languages over the years, and I'm afraid, Dizzy, barring further evidence, I'm going to have to go with renderdog2000 on most points.

But thanks, Dizzy, for your input as well. I'm off to take a closer look at Poser.ini.

Ok, here's my evidence: loading library information using a .Net 2 Framework application takes on my PC about as long as it takes Poser to load that information, if it does what Poser does - read not only the directory structure but also directory shortcuts... I'm still only talking about the reasons for the startup time.