White Raven opened this issue on Aug 12, 2009 · 11 posts
bagginsbill posted Thu, 13 August 2009 at 9:55 AM
Quote - I'm one of those fools who has 60 Gigs of runtimes.
Once upon a time, I tried loading all of that stuff into a single runtime to get by the issues that bagginsbill explains with the resourse disconnects and the like. Poser (6, I think it was) crashed mightily, unable to shoulder the load.
Question: Is this fixed in Poser 8? That is to say, is there a limit to the size of a single runtime, or is it still advisable to break them up into smaller runtimes? I see the advantage to the favorites system. It appears to do the same thing I was doing with multiple runtimes for organizational purposes without the pathing errors that seem to creep in with multiple runtimes.
So, will it work? Or do I still need to limit my runtimes to, say, 20,000 items each?
I can't think of any limit for Poser 8, even 1 million items in one runtime is fine.
The Poser 8 library does things completely differently than all previous versions of Poser.
Poser 7 did a considerable amount of scanning a runtime looking at things, even if you had never ever looked at them. I don't know all the specifics of Poser 7, but I think all loaded runtimes were scanned and thumbnails analyzed at startup or something really expensive like that. Maybe it only deep scanned the "current" runtime. Not sure. But it was slow to start and you had to wait.
Poser 8 does a quick swipe of the top level of all loaded runtimes. That is very quick. At this point, you can start using it.
Following that, in the background, it looks over the folders you had open in your previous session, and starts populating them. It is doing this without stopping you from using the UI.
It also does this in a smart way. If you had a bunch of deeply nested folders open, but the top level was closed, it doesn't go down to the deep ones, until you re-open the top one. At that point it says "Well, the last time he had this open, he also had these child folders open. He probably wants to see them again." And then it scans those, also in the background.
Thumbnails are not pre-loaded at all. They are loaded the instant that it needs to show them to you. So if you have 20 thumbnails visible in the tree, that's all it has. As you scroll it will discard those and load new ones. As you open folders, it will then grab the thumbnails, but only for the items that you see. If you open a folder with 1000 items, but only 20 are showing, only 20 are loaded. Again, all this happens in the background.
Because it works this way, the effort it makes is the same whether you have your entire library in just one runtime, or 500 runtimes. Organizing runtimes for efficiency isn't possible anymore. It is the same efficiency whether you have 1 giant runtime or 500 little runtimes.
However, for the user, there is some advantage to separating runtimes. You can use the "Show Library" pulldown to focus on just one library instead of combining
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)