What does Poser load at startup from runtimes?

1. Is it just the internal runtimes or external as well?
2. Is it loading just the content library folders, or does it load Geometries and/or Textures also?  (In other words, if I put ALL the geometries and textures in one runtime (internal or external), would it slow down the startup?)

Moving geometries & textures without the other files could cause you some serious problems, when you load a figure Poser is expecting to find the geometry file in the same runtime & may throw a fit & crash if it's not there. Same goes for the Textures, even if it doesn't cause a crash it WILL slow you down when you start loading up content as Poser will then have to search everywhere for it.

Bummer.  So much for that plan.

I could be wrong as Poser8 is a new beast & I'm basing what I said on the older Poser versions that throw hissy fits for any reason.

Lucifer_The_Dark is correct.  Relocating anything manually will create larger headaches down the road; and Poser 8 is not any different than the previous versions.  On startup, Poser 8 will load all your runtimes you have defined in your library.  That will include textures, geometries, materials, etc.  Although many users boast having rather enormous runtimes, I would recommend creating smaller, manageable folders to reduce the startup load.

How easy is it to start Poser 8 with a minimal runtime, add in external runtimes as you need them, then remove them again so the next startup is quicker?  Or is that more hassle than it's worth?

 P7, Pro and or p8, have all my textures, geometries and morphs like the !DAZ folder in the main runtime. Everything else is in their own runtime like figures, hair, poses and props that relate to V4. Makes it easy to break things up and move things around anytime I want, because the geometries and textures never move and have never had a file path problem yet!

 I have several large runtimes, one of the decidedly HUGE, and still Poser 8 starts in exactly 23 seconds (yes, I timed it)

So it's not external - or other runtiems that bogs down Poser.

Poser 8 starts a LOT faster than Poser 7 btw. That one takes exactly 40 seconds to start up.

Both are configured to start with a blank scene btw, in other words it does't waste time to load Simon or Andy.

Quote -  P7, Pro and or p8, have all my textures, geometries and morphs like the !DAZ folder in the main runtime. Everything else is in their own runtime like figures, hair, poses and props that relate to V4. Makes it easy to break things up and move things around anytime I want, because the geometries and textures never move and have never had a file path problem yet!

Okay, so that sounds like I CAN put all the geometries and textures in one runtime and keep the Libraries in separate runtimes.  Does that only work if the geometries and textures are in the main runtime, or will it work if they're in an external runtime?

Quote - > Quote -  P7, Pro and or p8, have all my textures, geometries and morphs like the !DAZ folder in the main runtime. Everything else is in their own runtime like figures, hair, poses and props that relate to V4. Makes it easy to break things up and move things around anytime I want, because the geometries and textures never move and have never had a file path problem yet!

Okay, so that sounds like I CAN put all the geometries and textures in one runtime and keep the Libraries in separate runtimes.  Does that only work if the geometries and textures are in the main runtime, or will it work if they're in an external runtime?

Yes it works in P8 as all my geometries and textures are still in my (linked to P8)  PoserPro runtime. When PoserPro 2010 comes out I will move them there. The only issue I have is my !Daz folder where the readscript calls look.  If a pose inj file to add body morphs uses readscripts, it appears it needs to be in my P8 runtime. Plan to fix that tonight, but will try a symlink first (I'm on a Mac, and symlinks can work sometimes for things like this). 

Sigh.  (I sigh because I've explained this in this forum at least 6 times one way or another.)

Poser 8 Library viewer does not look at geometries or textures AT ALL. That's why I made it say "Show Library" and not "Show Runtime". When you tell it to show libraries, it is showing you LIBRARIES. These are the things in

Runtime/Libraries

Not the things in

Runtime/Textures

or

Runtime/Geometries

You can delete all your geometries and textures or move them to the moon, but it won't save any time.

Poser only reads the first tier of library folders in each category in each library. It does not read past the first tier, unless you left folders expanded. In that case, only the folders that were expanded the last time you quit will be read. If you leave nothing expanded, then startup is fastest.

However, it's not as though you have to wait for the expanded folders to load. They load in the background.

Thanks for the clarification, bagginsbill.  Can you clarify the issue of where P8 looks for Geometries and Textures?  If I keep G&T in a separate runtime from the Libraries which use them, will that significantly slow down loading of those items when I use them?

Quote - Thanks for the clarification, bagginsbill.  Can you clarify the issue of where P8 looks for Geometries and Textures?  If I keep G&T in a separate runtime from the Libraries which use them, will that significantly slow down loading of those items when I use them?

The issue you may run into has nothing to do with the Library, but you run the possiblity of having a bunch of broken References with the CR2, HR2, PZ2, etc.. (The Library Files that look for the Geometries and Textures reference the location of the Geometries and Textures)

I don't really know if separating textures and geometries in a different runtime would break things or slow things down. It couldn't possibly speed them up, that's for sure. Plus, SR1 is probably going to change some of that behavior.

What is the reason for wanting to separate them? For any given product, if you want to use that product, then you want to use its geometries and textures, so adding the runtime containing the product should be desirable. If you don't want to use the product, then removing the runtime that contains it should be desirable, as it will let Poser not bother looking in that runtime for things you couldn't possibly be using.

But separating them, you have a situation where the textures+geometries needed are either found or not found, but never found where it first looks for them. How is that desirable?

In some cases items in one runtime reference geometries or textures in other runtimes -- for example, I've seen a giant which references some of the geometries and textures of the default P5 figures.  If I'm working with my monsters runtime and don't intend to use the regular figures, I still need that runtime loaded so Poser can find those geometries and textures.  If I had all the geometries and textures in a separate runtime which is always included, I would never have to worry about which runtimes were in or out, and since the G&T runtime has no libraries, Poser doesn't have to load anything at startup.  In fact, if I use an external library manager, I never have to have the bulk of my libraries loaded.  Does that make any sense, or am I going about things all wrong?

If I understand what you're saying, for example, you move all your P5 G&T to some generic G&T runtime. Then you remove your P5 runtime, so you the library GUI doesn't have to read it. But you have content in some saved scene that references stuff that was in P5, and now is in your generic G&T.  Your question is will it find it?

I believe it will, but I've never done that sort of thing, so can't say for sure.

Why not just try it? Load some stuff from P5 runtime, save the scene, unload the P5 runtime, move G&T stuff from there to some new TestG&T runtime. Add TestG&T, then try to load the scene. I'd try it myself, but that's no guarantee it would work for you, plus I'm really tired and going to sleep now.