If I understand correctly, Poser Pro doesn't use BUM maps. What happens if a character or prop is setup to use a bum by the original artist? The same question would apply to figures you've setup yourself according to the instructions of the originator of the figure. Will that result in a bad looking image when loaded into Poser Pro? (You know, black face, whatever)?! PPP doesn't need rsr's in the libraries, right? Do those rsr's cause problems if there are pngs in the libraries? I suppose someone wouldn't want to remove all the rsr's till they've made sure each rsr has a corresponding png file? P3D0 Explorer's rsr to png converter is a godsend here. Are there any other considerations for anyone who upgrades from Poser 4.03 to the Poser Pro Pack? Ron If so, what is the fix?

No problems in any of these areas. So far as I am aware there are no backward compatibilty problems between ProPack and P4.

ProPack doesn't need to use .bum files, it can render bump mapping straight from a normal (.bmp, .jpg etc) file and doesn't perform a conversion. If, however, a .bum file is specified in the material, ProPack will use that in the same way as 4.03.

I think (but can't remember now) that ProPack converted all of the library .rsr files into .pngs on installation. Either way, I now have library directories that have both .png and .rsr files for the same objects, Propack seems happy using either. The main reason that a lot of people delete the .rsrs is simply to save disk space.

The only downside is that if you are distributing objects from a ProPack installation you may have to convert the .pngs to a .rsr format in order to allow P4 users to access them.

If you distribute files made with Pro Pack, non-Pro Pack users will experience the "newer version number than expected" error message, because Pro Pack has a higher version number than regular Poser. It's a simple fix: open the file with a text editor like Wordpad and change the version number from 4.2 to 4.01. The version number is usually near the beginning of the file. Likewise, you have to be careful with MAT pose files; some are intended for Poser, and others for Pro Pack.

Apparently PPP doesn't automatically convert rsr's to png. I had the bright idea one day to do a search and destroy of all rsr's in my Library folder. Guess what? Many of my items had no "thumbs." That obviously meant there were no pngs to replace those rsr's. I just looked through my libraries, and many sections which came from either Poser 4.03 or PPP had no png files! The prudent thing to do would be to scan the libraries, and see which ones have no pngs to replace the rsrs. Then use p3do explorer's rsr to png converter, and then get rid of the rsrs. Yes, I'm aware that some MATs should be used for PPP, and others for Poser 4.03. Here is a screenshot I made to show which ones should be used for "regular" Poser. Ron

silly question but what's the difference in the Mat files for ppp & p4?

Poser Pro Pack converts RSRs to PNG the first time you access the folder the RSR is in, its not automatic for the whole Runtime/libraries section. Ron, any chance you can get the RSRs back from the recycle bin? It would be useful if there was a recursive converter, I dont think P3DO does anything other than the folder you`re looking in. I feel the need for a Python script. Anybody?

C1rcle, there is practically no difference, just that a Pro Pack bump map can be JPEG and the MAT pose file needs to show it that way. Poser 4 uses BUM files only, Pro Pack can use either, but the MAT files can only specify 1 type.

ok thanks :)

In the past few days I've wiped my computer and reinstalled Windows XP a few times. It's a long story. So you're saying PPP will convert rsr's into pngs when I first access a given folder? Wow, I can stop using p3do to convert. I'd already made it through the hands library when I read this message. Thanks for the insights. Just what is the benefit of a png over an rsr? Ron

I also appears that Poser 4 converts geometry OBJ files to geometry RSR files (not to be confused with thumbnail RSRs) the first time you use them. If you later update the OBJ file, the change doesn't take effect, because Poser 4 already has the geometry RSR file. Pro Pack works directly from the OBJ file, and doesn't create a geometry RSR file. (This is rather counterintuitive, since the two programs take opposite approaches: P4 converts OBJs to geometry RSRs, then ignores the OBJs, while PP converts thumbnail RSRs to PNGs, then ignores the thumbnail RSR.) What this means to vendors is that if you develop in Pro Pack and ship the OBJ files, then later you update the product and ship a new set of OBJ files, Poser 4 users won't get the change unless they manually delete the geometry RSR files that Poser 4 generated from the original OBJs. Since we develop in Pro Pack, and since we have heard that only something like 10 percent of the Poser users have Pro Pack, we have started taking our opening our products in Poser 4, taking the geometry RSR files that Poser 4 generates, and shipping them in the product, along with our OBJ files. It makes the product somewhat larger (but not too bad--most of the size in the product is texture maps), but it keeps the users from having to manually delete things in the Poser directories when the install upgrades. Lynn Grant Castle Development Group

Ron... I've never had a problem in any library with the old .rsr still residing there alongside the new .png. I still distribute .rsr files with my recent projects instead of .pngs, because I've tested it over and over, and Poser Pro generates a .png file in the library when you first access it. Doug

One reason we distribute both PNGs and RSRs for the thumbnails is that sometimes Pro Pack screws up when it is trying to convert the RSR to a PNG. This seems to happen in thumbnails where most of the middle of the image is empty. (Imagine, for example, a close-up of a door frame, where you have something like an upside-down, squared-off letter U, with the middle part empty.) By creating an RSR, then letting Pro Pack convert it to a PNG, we know that we have a good PNG. (I suppose we could let Pro Pack convert it to a PNG, then throw the PNG away and just ship the RSR, confident that it is convertable, but I am a little more comfortable shipping my own PNG, and not depending on the user's copy of Pro Pack, at an unknown [to me] service level, converting it properly.) Lynn Grant Castle Development Group

Thanks for that advice Lynn! I hadnt encountered that yet, but it's good to know! I've tested all my on the fly rsr to png conversions so far, but I've never had an empty middle image yet. Doug

I've opened .bum files in PhotoShop and converted them back to jpgs just to cut down file size before. Inspired by Traveler's tutorial for trimming up bum file size.

"taking the geometry RSR files that Poser 4 generates, and shipping them in the product" I never install the geometry RSR when they come like this Lynn. Very frequently when I try to use other people's geometry rsrs I get the dreaded "can't find" error from poser and it either deletes something else from my scene or crashes. I don't know why that is...maybe each install of poser just likes the one's it makes itself best :)

Wow, you guys are full of wisdom and knowledge here. Now let's see if my feeble mind can keep track: 1.) PPP will automatically convert library rsr's to png once you load that library "folder." 2.) rsr's in libraries won't do any damage, but you can safely delete them? 3.) Every PPP user had Poser 4 first, then upgraded over that. This is where I'm a bit uncertain: 4.) The Geometry rsr's from Poser are replaced by those generated by PPP? Or something like that? 5.) This one has me totally confused. What is it about converting bums back to jpgs? Youch. I'm reinstalling everything from scratch (once again). That means I won't have converted any bum.jpgs. I suppose that is an advantage?! Ron

1. Poser doesn't read the text-based obj files in the geometry folders. It creates a binary rsr version of the obj, which supposedly can be loaded faster, and reads that instead. These geometry rsr files often become corrupted, causing various errors in Poser. Pro Pack, on the other hand, reads the obj files directly, and doesn't create binary versions, so it never suffers this corruption problem. 5) BUM files are uncompressed bitmap images that Poser uses as bump maps. Pro Pack can use BUMs as bump maps, but it can also use JPEGs, which are highly compressed and eat up less of your valuable hard drive space. In a way, reinstalling from scratch is an advantage (it's always helpful to clean house). But Pro Pack can't convert images to BUM format, so if you have any figures or props that specifically look for BUM maps when loaded, you'll either have to find a way to supply them, or edit the files to look for JPEGs instead.

OK, thanks. I understand more. I still have a regular but minimal Poser installation on another drive. I did that for possible testing purposes, etc. So chances are I could use it for any bum bummer problems, grin.

Attached Link: http://www.soft-rabbit.com/

This is not meant as a complaint against sturkwurk or anyone else who offered help and suggestions, but .bum files *cannot* be converted into .jpg (or similar) without major difficulties. I'll try to explain - both Poser and PPP need to "convert" bumpmap templates into a different content before they use them, the difference is just the time when the conversion takes place: - P3 and P4 convert them *once* and store the result in a .bum file - PPP converts it *every* time in memory when it accesses the bumpmap template When PPP finds a bumpmap reference, it looks for the type: - if it is a .bum file then it just uses it - if it is a .jpg or similar, it *converts* it and uses the conversion This means that if you use Photoshop to turn a .bum into a jpg and then load the .jpg in PPP, it will be converted *twice* and this spoils it completely. If the bump is nothing but "ripples on a surface", the difference won't be significant, but if the bump is supposed to show specific details, then it gets ruined. The only way to convert a .bum into a .jpg will be to "un-do" the original conversion, and that is absolutely non-trivial. To my knowledge, my filters for GraphicConverter (Mac only) are the only tool so far that is able to do that job, but unfortunately I'm currently unable to release a version for PC.

I just load the bum into photoshop... convert to a grayscale... save as a jpg... then correct the information in the cr2 pp2 or whatever to change it to a .jpg reference. Doug

Look at the 4 pictures, let's call them A, B, C, D from left to right. A is the original template (a huge black hole inside a flat white area), B is what P3 and P4 convert it into a .bum. If you open B in Photoshop and convert it into grayscale, it will look like C - and this is *very* different to A. Instead of a deep "hole" in a high area, both inside and outside is on the same level, instead you get some sort of circle shape that goes both upside and downside the gray plane (darker is a hole, lighter is a hill). Template C would convert to D with P3/4 and this is exactly how PPP will see it as well, if you make the .cr2 to point to C. If this black hole of A is a detail that needs to be seen on a Poser surface, then using C instead will completely spoil it.

Wow, you guys know much more about this than me. I'm just trying to get by, and to make the move to PPP. I haven't created any BUM files, and don't know if or when I ever would. Could you tell me how to handle a character that has an included BUM file? If the character's textures are already set to use a BUM file, will PPP get bummed out and mess up my character's textures? Will I need to learn the fine art of image manipulation or bum creation, magic, or something? I have not yet tried editing cr2 files. Frankly I don't care to do so at the moment. I eagerly await your expert input. Ron

In general, everything should work fine as it is - if PPP asks for a .bum then give it a .bum file, if it asks for a .jpg then give it a .jpg. In other words, if your file worked under P3 or P4 then it will continue to work in PPP the same way. But,... and unfortunately there is a big "but" coming now... What I wrote above is true for the Mac Poser, but the PC Poser obviously suffers from a very nasty bug first discovered by gillan. You can read the full story here: http://www.renderosity.com/messages.ez?Form.ShowMessage=454108 and here: http://www.renderosity.com/messages.ez?Form.ShowMessage=516286 The bug means that the PC Poser creates an invalid .bum file that shows wrong shadows depending on the light angle, and this (of course) affects all .bum files created by P3 & P4 (and used by P3, P4 or PPP).

Ouch, I hope I never run into that bug.
Ron

You have probably been affected many times already without really noticing it... as a matter of fact, bumpmaps are hardly used for details (most of the time), people typically only use them to "roughen" surfaces. In this case it hardly matters if the template is correct, and that's why people won't see the mistakes created by either the Poser bug or stuff like turning .bum files directly into grey .jpg's or .tif's - as long as the surface still looks rough, everything is fine for them. Every now and then when it does matter - like a scar on the body with moving lights - people just curse Poser for not supporting "real" bump mapping. If you have problems with a bump not looking as expected, then it will almost certainly suffer from the inverted channel. I tried to find an automated fix but gave up - this bug is really cursed. To repeat the "Escher" metaphor: telling a valid .bum file from a damaged one is similar to tell a real drawing (that might exist) from an Escher picture - you need to "understand" what it "really is" in order to judge it...

Good points Martin, I hadnt noticed that... but then again, I had only done it few times. Doug