Despite the interesting title, this has nothing to do with swollen derrieres. Please make note that I am using Poser 4. Not Poser 5, not no Pro Pack, just plain old CL updated P4. I was messing around with things and stumbled across something I kinda didn't expect... And I think I came up with a new way to package things with BUMPmaps withut having to include a big BUM file or to force the user to rebuild the BUM. For the halibut, I bumpmapped something I was working on to a plane. Then I opened the BUMpmap file in Photoshop (Open As->BMP on a PC, on a Mac select the filetype as BMP and open it). I'd already stumbled across the fact that a BUM was just a BMP, and that if you draw on it in blue weird things happen (see my tron lighting thread below). Other people knew this, but I only found this out after hacking at it. So anyway, what I did was to save the BUM/BMP as a JPEG. Then I edited the square I'd made use the BUM file to point at the JPEG instead of the BUM file. The content, aside from super minor JPEG compression (I saved it at '12') was the same. It worked. P4 read the JPEG as if it were a BUM file, didn't ask to convert or say it couldn't find it or anything. Soo, anyway, the image I'm posting in the followup (I didn't want it on top of this text) shows both squares. You can't tell which is which, of course, so I'll tell ya. The one in front/on your left is the JPEg bumpmap. THe one on the right is a normal BUM. Here's the thing, though... this WON'T do what you expect when you open it in P5 or PPP. Because those are designed to create the BUM on the fly from anything other than a BUM, it will create a bum from a bum, which will look really weird. It's not good to have a double BUM. Instead, my proposal for packaging P4/PPP/P5 compatible things with textures is to include two ZIPs INSIDE the main ZIP, alongside Runtime and the README and stuff. One of these ZIPs would be the P4 JPEG bumpmaps. One of these ZIPs would be the PPP/P5 bump jpegs, which would be the original greyscale bumpmaps you made the BUM from if you're using P4. Instructions in the README and sensible names for the ZIPs would explain what to do: if you have PPP/P5, you unzip the PPP_P5_bumps.zip to Runtime. If you're using non-PPP P4, you unzip the P4_bumps.zip to Runtime. This allows you to use the same CR2s for P4/PPP/P5, but to simply place the appropriate files in the appropriate places to do what is expected by the program in question. Make sense? Anyway, on to the image proving this works.

If nothing else, I'm going to start doing this!

I should add this for those who do not have Photoshop, since I don't know if and how other programs can open one filetype as another... On a PC, just change the extension of the BUM to .bmp and open it in whatever as a BMP. On a Mac, it takes a little more work. Open the resource fork in your favourite resource editor (ResEdit, for instance), and change the TYPE to 'JPEG' and the CREATOR to probably about anything, but '8BIF' will work -- that's Photoshop (I don't know what it means, but since it goes WAAY back, it's probably something like '8-bit Image' something).

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=454108&Form.sess_id=1950301&Form.sess_key=1

Read over that post, but I am significantly uncertain of the corrected-ness ofthe bumpmap shown. Black isn't supposed to be high.

Allow me to amend my proposal: For convenience's sake, it's a better idea to simply ZIP everything up side by side so the that the PPP_P5_Bump Folder and the P4_Bump folder aren't seperately compressed. That way you can include the original greyscale bumpmaps in a subfolder in the 'normal' Textures subfolder, and not increase the filesize by more than a few bytes due to the way file compression works. Here's the scoop: When a file is ZIPped (or Stuffitted or tar.gzipped or RARred or whatnot) it's stuck into a single file which is then compressed as a single file, which saves space over seperately compressing them. If you have a ZIP file inside a ZIP file, it doesn't compress any further. However, if you have two identical files inside a single ZIP, the result isn't much bigger than compresing only one -- you just double the symbol table entry for the uniques inside the file sector. Thus if you ZIP up all the PPP/P5 Bumpmaps and also include those same JPEG bumpmaps in the main section in a subfolder, you're getting twice the size for those files that you otherwise would -- because the already ZIPPed compressed binary isn't the same as the not-yet compressed JPEGs in the original bumpmap folder. In simpler terms, since JPEGs don't compress, they only archive (already being about as compressed as you can get and more compresssed than the non-lossy archiving algorithms allow) a ZIP containing only a 60kb JPEG will usually weigh in around 61-62kb. A JPEG containing 2 copies of the same 60kb JPEG will weight in around 65k, because the contents are duplicate and can be compressed to 50% plus the symbol table. A JPEG containing a 60kb JPEG and a ZIP of that same 60kb JPEG, however, isn't two copies of the same thing, as one is 'compressed' or at least archived with a relatively useless symbol table. Thus it will weigh in around 125-130kb generally. I think RAR does better and outsmarts this, but no one uses RAR here.

I just had to mention that a chic black dress always works...

This is a great discovery!

Les: My proof-of-concept is online... I'm distributing my Han Solo Blaster (RFS/DFS) in this fashion, and I'm additionally using handmade p4 bumpmaps, avoiding the invert-green problem.

::kisses Dodger:: (Don't worry, I'm cute. ^_~) I thought surely there had to be a catch, at least some slight difference when rendering that might matter in some cases, so I tried it out. Opened a bump map I already had on the drive in Photoshop, saved as a jpg, made a Poser scene with two figures, applied the original bumpmap to 1 and the jpg to the other, and rendered. I then switched the bumps, rendered again, overlaid them in Photoshop, and changed one to "difference" mode so I could see any differences between the two renders. And there were none! Except that the original BUM is 3037K and the JPG is 698K. The only problem is that if I try to load the jpg from the material dialog, it wants to convert it. I tried changing the extension to BUM, but it still wouldn't load it. However, I know from past experience that jpg bump maps can be applied in P4 with MAT files (it's usually an oopsie) or referenced in the model in the library. So I think this definately has potential!

At higher JPEG compresson levels there will be a slight difference. At max quality, however, there shoudn't be any, because the algorithm isn't lossy at max quality. Basically, how JPEG works is this: For each colour channel, all the even gradients are found, while edges are left as-is. These even blocks of gradient are changed from pixel information into equations describing the gradient, which are generally much smaller than an even gradient. The 'lossiness' or 'compression/quality' ratio is simply a rule that decides what an edge is. JPEGs use 16-bit colours, which means that there're (I think) 256 shades of grey available for each channel including black and white. If pixel 1A is 128 and pixel 1B is 129, then at 100% quality those two pixels become one jpeg coordinate describing a gadationn from 128 to 129 between those two pixels. Doesn't mean a lot in terms of two pixels and doesn't help at all for one, but when you have 12 pixels in a row that form an even gradient (say 128 to 140), you have seven bytes of data for those 12 bytes -- start 1A @ 128, end 12A @ 140, gradient angle 0 degrees. And when you have a 12x12 block that starts fades in an even gredient across the entire thing, then you have 144 bytes covered in 7 bytes of data.