Most people who've cracked open a Poser file know this, but I thought I'd rehash it since SOME people obviously DON'T know this. Poser files sometimes mention pathing information in them (usually, in fact). CR2s mention figureResFile, lights and props mention object paths sometimes, and anything with a texture map applied has a path. Object references should be relative to the Poser 4 installation directory, and this is where Poser looks for them and where it stores this information in a PZ3 file. For instance, a character's geometry might be in: :Runtime:Geometries:yourFigures:yourPoserCharacter.obj Textures, on the other hand, Poser looks for first in the Textures folder. This means that paths for textures, and only for textures should begin relative to the Textures folder. A proper texture path might look like this: :myTextures:myReflectionMaps:backgroundReflection.jpg A path beginning with :Runtime will work, but is not the most proper way to do this. Any path with a 'C:Program FilesMetaCreationsPoser 4...' in the beginning is just plain wrong, and is just as wrong if it says 'Curious Labs' instead of 'MetaCreations', and not ready for distribution. Likewise, any absolute Mac path, like 'Hard Drive:Applications:Poser 4:...' is also wrong (and worse, in a way, because people have different driver names more often on a Mac, whereas most people on a PC have Poser on C:, in the Program Files directory, and usually in the MetaCreations or Curious Labs subfolder. ANY poser file you buy with absolute paths should be mentioned to the seller and corrected. Any Free Stuff with this sort of path should probably also be mentioned to the owner or distributor, though it's free, so you're still getting your money's worth. Otimally, ALL texture paths should be made relative to the :Runtime:Textures folder, maning you should not see ':Runtime:Textures' in the path, because Poser already assumes that. Further, any textures should be in the :Runtime:Textures folder (although they can certainly be further down and, in fact, this is a good idea). As a further note, Macintosh files have a 32 character limit on filename and a 64 character limit on a single path string, so paths should be kept shorter than this for Mac compatibility. The closer you are to these standards, the higher quality your product is. The further you stray, the lower the quality. If, for some unexplainable reason, you're forced to break away from these standards, then whoever or whatever is responsible for this is forcing you to produce a shoddier item, and should not be allowed to get away with it. If you've purchased a product that breaks from these standards anywhere, I wholly urge you to contact the creator and/or marketplace responsible and voice dissatisfaction with this. Some people may be unaware of this, as has recently come to my attention, so I figured it was important to explain it. Tips and Tricks: Something else you might consider trying when distributing files (I only recently discovered this, so mine don't do it yet). The BUM file problem has been around for ages. Poser 4 uses BUM format files for bumpmaps, and these are huge, uncompressed files. PPP and P5 avoid this problem by creating a BUM on the fly as needed, but will still, as far as I kow, accept a BUM file. The common practice is to include the original bumpmap Poser generated its BUM from and to send this along so the purchaser or downloader can recreate their own BUM files. Al alternate idea: A BUM file is actually only a specialised 24-bit big-endian (Windows Byteorder) BMP file. It's a full-colour Windows Bitmap. If you change the extension, you can crack it open in any image editor I know of, even MS Paint. this also means that you can certainly, with some small degradation, convert it to a JPEG file and distribute it with instructions to open it, convert it back to a BMP, and then rename the extension to BUM.

THANKS A MILLION, DODGER!

I'm getting ready to launch my first project and this is just exactly one of the things I'd bogged down in and was about to leave plaintive little messages about. Now I don't have to.

I really needed to know this. Thanks again.

Bill

Interesting. I didn't realize that Textures was a default path. But it seems more consistent and less error-prone to simply start everything from Runtime, which also works. Strictly speaking, the first place Poser looks for components of a CR2 is in the same directory with the CR2. So a line like: figureResFile Skull.obj or textureMap Skulltex.jpg will work provided these files are in the same directory with the CR2.

Attached Link: http://www.fallencity.net/lore

Yep. Had to e-mail a merchant just yesterday on that. It's a pet peeve of mine. I have P5, but I only use 1 Runtime folder, so the "Runtime:..." works for me. I assume that the ":Runtime:..." works for P5 with multiple Runtime folders, but I haven't tested that out. Can anyone verify this? PPP and P5 do not need .bum files. They use .jpg files to create bumps. You can either give out the .bum files and convert as _dodger described above, give out the .jpg files (have the user convert .jpg to .bmp, then open the file in Poser and point the bump map to the .bmp file. Poser will convert it to .bum), or give out both. One strategy for P4 MATs vs. PPP and P5 MATs is to have 2 sets of MAT files, one for P4 that references .bum files for bump maps, the other for PPP and P5 that references .jpg files for bump maps. Then the user can toss whichever set of MAT files they do not need. MAT files are comparitively small; I haven't seen one larger than 30kb, so 2 sets of MATs are no big deal. Since PPP and P5 can convert .rsr files to .png files for the library thumbnails, you might want to consider only putting .rsr's in. The other possibility is to include both and instruct the user on which to toss out. I have a tutorial on packaging up files for Poser with WinZip, and decided to write up some info on the various flavors of Poser to make it easier to make packages as inclusive as possible. I'll try to have the second one up tonight as well. Cheers!

Actually, from what I've been informed (and I could be informed wrong, as I still use P4, no PPP), BUM files will work for PPP and P5, too -- so including JPEG compresed BUMs should work on all three after the files are converted back to BUM. Photoshop actions and batch processing can be used to batch convert all the files into BMPs and then it's not too hard to rename them all to BUM. MAT files are generally small, but MAT/MOR files are bigger and if they use things like LesBentley's Delta Injection Therapy, they can certainly get huge. Plus, more than MATs use texture pathing -- and a full fledged Millenium-sized CR2 can be pretty big.

I should note that any merchants should check the merchants forum about this subject, which someone may be trying to impose a wrong rule on.

ockham.. Please please please never put a obj in the same folder as the cr2.. People move things around and its easier to have the obj in the geometries where it belongs. a big pet peeve of mine

I agree with StormRage on this seriously. Objects belong under :Runtime:Geometries:SomeFOlderOfYourOwn

When someone specifically differentiates P4 and ProPack mat files, they should use .png for the ProPack ones and .rsr for the P4 ones. I know Poser will make .png from .rsr but it's a PITA remembering to delete them. If you're running NTFS there is a Master File Table (MFT) that can fill up pretty quickly if you have lots of little files (like thumbnails for downloads and all your .rsr and .png files for Poser). The fewer you have the faster your system will run because when the allocated table fills up the rest get fragged and slow down. The only solution is a reformat after changing the designation. It defaults to '1' which allows a reasonable number of files. If you use Poser it should probably be set to '4'. My partition is only 75% full but my MFT is at 98 :< So I delete unnecessary .rsr's religiously. It won't break your machine if it fills up though. Just some trivia.

'When someone specifically differentiates P4 and ProPack mat files, they should use .png for the ProPack ones and .rsr for the P4 ones.' I agree fully here as well.

Thanks for the info Dodger. It really helps when editing CR2 files to know these things, especially if you are a beginner (ME!). What should the path read if the textures are kept on a completely different drive from the program files? I keep all my textures on my d: drive as I have read somewhere that it slows down Poser if it has to load all the textures into memory. Juanita

I used to keep my older textures on a separate partition from Poser for space reasons. In that case the full path (with drive designation) is required and will work okay. I moved them all into runtime:textures in preparation for Poser 5 and Poser started taking twice as long as open. But it didn't affect anything else. (the textures aren't loaded into memory until you load a figure that uses them or apply them yourself.)

Good thread, dodger. I'm constantly amazed at the weird files I find in Freestuff items. Not that I'm complaining. They ARE free. But when I find an .obj, PLUS it's corresponding .rsr, which is usually the same size (ie. BIG), and is completely unnecessary, since, as we all know (?), Poser builds it for you, I begin to wonder. And, of course, the ubiquitous HUGE .bum files, which could easily have been zipped as jpegs. When it comes to Marketplace items though, modellers have a DUTY to be properly informed about these things. After all, they want your money, don't they? mac

jroussel: a full path is needed when the textures exist on another filesystem, but they should never be distributed this way. For instance, if you stick all your textures in D:PoserstuffTextures, someone else may not have a D: drive, or their D: drive may be a CD-ROM, or it may be a floppy disc or JAZ or ZIP disc or a DVD burner or all sorts of things. It may be a mapped network drive. Or their secondary hard drive may be a hard drive, but the name, to the system, could be 'Mac Drive 2:Poser Stuff:Tex' Anything for sale or free download should be defaulted to living inside the Runtime folder. By the way, yes, Poser will slow down if lots of textures are loaded into memory -- like I think it begins to slow down after 40 or more, depending on your drive and processor and RAM. But Poser doesn't load images into memory until a material calls for them, and then it doesn't matter where they are. It should also be loaded that when an image is loaded, it's not really 'loaded into memory' -- instead it's been scaled way down and the small version you see before render is the one in memory. This is why you can change a texture file and it won't affect the preview, but if you render it it will use the new texture. But, as spit said, it does read through what's there during open so it can have a vague guess about it's environment. and that can slow down the program's launch. MacLean: There is some weird stuff out there, and I'll admit openly that I've put some weird stuff out there. Here's the thing: a lot of FreeStuff is put up by people who are thinking about being vendors but haven't gotten the courage together to try it yet, or don't feel their stuff is storeworthy, or whatnot. Usually a person will give something away in FreeStuff months before they are ready to sell anything. This means that their habits aren't always necessarily the most clean yet.

Right, dodger. I made free stuff for 2 years before I sold anything. But it was good training for packaging stuff for sale. Mind you, I have DAZ to test the hell out of everything (even so, I get my own betas done first), and I can tell you, they're pretty damned strict about it too, which is a good thing for everyone. mac

Nods See, I haven't even gotten the courage up to try submitting anything to DAZ.

Dodger-Thanks for the detailed info especially with regards to memory and Poser. Today, for the first time, I actually ran out of memory when rendering an image (it wasn't an rsr problem). I have 768 in my machine and a honking swap file. But I have to admit, the file size is pretty big (70 meg). But my biggest complaint with Poser 4 is if you insert anything in your pic that has textures and then you end up deleting it, the textures stay loaded unless you close Poser and reopen it. And that was my problem today. Once I closed Poser, and rebooted my machine, it rendered just fine. Is there any way of getting rid of those loaded textures without shutting Poser down?

jroussel: No, not that I know of. 'Loaded' textures seem to remain resident no matter what you do short of hacking into your memory addresses using programmer's tools and risking crashing the program and the machine (especially when Poser thinks they are loaded and tells your video card they are -- don't really try that). However, the actual entire file is not in memory -- just a thumbnail of it. That means that if you have a 3000x3000 PX image 'loaded' you still probably only have a small 'thumnail' version resident in memory until render time. I don't know if Poser loads all 'loaded' images fully at render time, or just those actually used in the scene. From what I do know, there are soem thing that if you can afford to skimp on in a Poser scene will make the rendering easier and use less memory in so doing. 1) if you have a lot of small figures, don't use high-res figures -- use low res figures. If you're making a scene of a theatre audience with dozens or hundreds of people, don't use Mike and Vicki -- use the P1 figures. If they are small and far away, it won'r make a lot of difference. 2) some people have developed tricks for making images of masses of people. One of those tricks is to render things in pieces and either composite into the background bit by bit (for an example of this, look in the galleries for my Escape from the Emerald City picture) or to render figures one at a time to TIFF, then extract the alpha channel for use as a trans map and texture these figures onto one-sided planes -- in other words, make virtual 'cardboard cutouts'. Stuff like this is harder to do, of course, when you're wanting to animate. In P5 I hear tell you can use animated textures. In P4 you pretty much have to do it the background-composite way. 3) use smaller shadow maps, especially with more lights. This will give you cruddier-looking shadows, especially if you have a lot of objects, but if you also have a lot of lights it shouldn't be too noticeable. If you're working with 20 lights in a scene, try dropping the map setting of the lights to 32-bit instead of the default 256-bit. Conversely, if you're doing a scene with only one light and a lot of stuff (or a high-poly figure) and your shadows are coming out like crap, raise the map size. For my recent product pics, I have been using a copy of the default Rembrandt lighting that I upped to 1024-bit maps, which makes for very crisp renders. But it takes a lot more time and memory to render those.