The average users' Poser directory is incredibly bloated. having folders with thousands of images/files slows down your computer, regardless of your hdd space, and uninstalling a poser product is a nightmare. i try to keep my products organised, but not everyone does. ive always felt that merchants should release products with all of the files in a folder with their merchant name... such as: Blackhearted/Irina Blackhearted/Nia etc etc. textures should be similarly organised, as well as geometries. this way at least users have some hope of removing the product if they no longer wish to use it or if they need the space. people have released poser folder organisers and other apps to fight the poser clutter but none of them really do much to stem the tide. the fight against bloated poser runtimes is an uphill battle -- most people have a poser runtime of at least 2GB, and i know some with over 20. anyways, let me get to my point. id love to see poser be able to work with files within zips. this isnt cutting edge or exotic technology - many programs use it. as long as the zip were packaged in the correct format with the Runtime directory structure, it would be highly possible to program poser to read products from a .zip file as opposed to its regular file structure. think of how much easier it would be to both install and uninstall add-on content. instead of extracting into your directories, you could just drop the product .zip into a general 'product' folder and the next time poser booted up it would be ready to use. uninstallation would be a snap, as opposed to the current nightmare of hunting for files and folders in your poser directories - with most clearly being named on a whim by the merchant, or not labelled at all making associating them with a product hopeless. the only foreseeable issue i see is that extremely large products might take a few more seconds to load... but the merchant can use varying levels of compression to compensate for that. i realise some might not think that this is an important issue as they cry for rediculous features like a physics engine, caustics, a modeller, etc. people need to realise that poser is not, and never will be, on a level with 3ds or maya. would you rather have another face room, or something that actually benefits every single poser user out there? bloated directories and the inability to easily uninstall add-on content is an issue that affects everyone who has ever used poser. if not the .zip solution, id love to see something that helps with the growing problem. it doesnt have to be the ability to add content in archives... but how about some form of integrated browser that can scan for poser file associations and has an uninstall and/or 'cleaner' feature? id also appreciate if, with this in mind, merchants would be a little more considerate with their folders. and even the big ones are guilty: i cannot begin to express how pissed off i was after installing the milennium 3 figures and ending up with dozens upon dozens of !V3, !S3, !MAT V3, !MAT S3, etc folders dominating my pose menu, each with only a handful of poses or mats inside which could have easily been combined into a fraction of the amount of folders. cheers, -gabriel

Attached Link: http://www.renderosity.com/messages.ez?ForumID=12356&Form.ShowMessage=1924219

Btw there was a thread very similar to this one a couple of days ago in this forum, so you might want to check that one as well...

Message edited on: 09/14/2004 09:14

Message edited on: 09/14/2004 09:24

AFAIK, this is already a feature inherent in Poser 5's Content Paradise. Mind you, it only works on things you download via C.P....

I really do agree with the idea that some basic infrastructure improvements are more valuable than fancier render engines, etc. With Shade LE, there are better rendering and modeling tools than we'll ever likely see in Poser itself - at least Poser at a reasonable price. As for the library thing, using compressed files at runtime is an interesting solution, though frankly Java's /jar files are the only application of the idea I'm familiar with. Personally, I've always wanted to be able to place everything in one folder (or folder tree) for a product, character, props, poses, geometry etc. Some files like reflection maps and .objs need to be in a common location and referenced but a whole lot of them don't. I think one main cause of the current situation lies with the original design's insistence on accesing files by location rather than by the file type. The only problem I see with using compressed files is that if you want to modify something, say create a variation on a texture, you have to unarchive it, modify, and then put any changes back in the archive. P3DO already has most of what you want except the uninstall. There are one or two uninstallers available but AFIK, they can only handle what's explicitly referenced in the file they're deleting. To do a complete uninstall, you need to know everything that was installed. That would be easy for Content Paradise or an .exe installer to record but for .zips, you really need a custom unzip application. The zip labraries are free, tack on a database and it should be fairly easy to implement. The trickier part is dealing with the situations where people choose to install files in places other than the zip folder structure.

1. Poser 5 already handles zipped files (e.g., pzz, crz, etc.) It helps keep the disk space from climbing too rapidly, but it doesn't help the organization problem. P.S. Maybe I'm a packrat, but I find that I can do some things more quickly (maybe better sometimes?) in P4 than in P5. Render differences, yes... but also P4 has a memory of which textures have already been used in a scene. P5 does not... so if the same texture image is used for several parts of a mesh, you have to manually enter the same information over and over and over.... Anyway... this means that I keep everything in its uncompressed form so that both P4 and P5 can read it. Which also means.... it's ALL under the "Runtime" directory where P4 resides. YECCCCHHHH 2) If/when I finally decide that P5 is really doing what it was supposed to do when released (stability being a critical element, and the most recent version -SR4 - is actually not bad)... I MAY give up P4. Then comes the real question of this topic string. Where to from here? a) Remember the textures already used and make it easier to remove an entry from the list. As I may have many textures called "wood" (in different directories)... how bout giving me a better way of id'ing which "wood" it is? Has anybody ever heard of image previewing? b) Allow me to group morphs dynamically rather than having to use a word processor to enter the grouping command. Then let me delete all the morph targets in any selected group. This alone, when applied to V3 and similar models with huge libraries of morph targets, will do wonders to minimize the disk space. Once I have defined the shape of a character's head and most of it's features, I will probably never change or modify those morphs again. (I can always re-inject them if I intend derivative characters, or even save them off-line somewhere before the morphs are removed). Yes, I know I can use morph manager and a Python script which lists all the morphs with zero values, but these are time consuming because they are done with general purpose programs. And just think about how much faster it will be to find the particular morph targets you want (i.e., expressions, phonemes, etc.) b) Poser should keep separate "most recently used" directories for render output, scene input, image textures, etc. Right now, it actually only keeps the information necessary to save the scene or the render. As I like to keep my textures in a type-catalogued structure separated from the run time programs, I end up clicking many mouse buttons to get from deep within a D drive to deep within the subdirectories of "Runtime" on the C drive. c) Make it easier to maintain the list of "Runtime" directory tree roots(e.g., to "remove" one) that exists only for archiveal reasons) d) This message is already too long.... sooo.... If anybody wants to continue on this subject, let me know at bmoritz@exis.net.