It sets the distance at which objects become visible; that is, it makes objects close to the camera disappear. Useful if you use extreme camera angles and there's part of a body or prop blocking the view: you can set the hither to make that item invisible without having to move it, which would otherwise mess you up if you were rendering the same scene from several angles, or doing an animation.

Too bad you can't have an animated texture map! Something else for the Poser 5 wish list. Would be the perfect solution for something like this, or a fire effect, or a Vorlon ship...

Macintosh users can use MartinC's plug-in "SpeedBump" (available in FreeStuff) for the shareware graphics program Graphic Converter. Apparently because of the way the .bum file is generated initially, there is some loss of data, so the conversion back is only approximate, but according to the docs the differences probably won't be noticeable in a Poser render. The "green-scale" image is actually two channels of grayscale graphics data, which happen to be saved in a bitmap file as the red and green channels.

Attached Link: http://www.ci.nyc.ny.us/html/nypd/html/transportation/horses.html

NYPD uses a variety of breeds -- as long as they're big! I found a link to their webpage, above.

There's an idea for a utility... a program which takes the unzipped archive and automagically puts everything into the right folders, or the folders you specify! Mac users are familiar with MartinC's utility Macinstaller that does this for them, but looks like a version for PC users would be handy! Macinstaller will also check all the files in the Runtime folder and make sure all the internally-referenced files are in place, and ask you to find them if not. Dewo, I think some artists have their own named sub-folders because they're following Zygote's and DAZ's example. It is one way to make certain you're not stomping on someone else's file name, if yours happens to be named the same.

I can't really blame Lipsinc for not wanting to put forth the effort to develop for a niche market in a niche market, although in their case making a Mac version is probably trivial -- basically all their software does is read in a sound file, analyze it, and write a pose file (which is just text, the same format on Mac as PC). It's not like a game where there are video and speed issues involved. An experienced programmer could probably port it in a week. But there's the rub, Lipsinc probably hasn't hired any experienced Windows/Mac programmers. As mocap said, their stringing along Mac users is what rankles. I would suspect that the way to go in the future would be Python scripting, which could run on either platform, and be portable (with appropriate plugins or support files) to other animation packages as well, but that wasn't available when Mimic was under development (and is available only to Pro Pack users, but people who need Mimic probably also need Pro Pack anyway). No flames, timoteo1, just a simple observation that most people who have used both Windows and Mac systems (including myself) prefer Mac for its ease of use and consistency, although admittedly Windows has come a long way in recent incarnations. True, if I want to run the widest variety of software (90% of which is crud, in keeping with Sturgeon's Law), I'd use Windows -- but if I want to run the best software, and be most productive, I choose Macintosh. Technologies that are now PC standards were widely introduced to desktop computers on Macs: 3.5" floppies, SCSI, USB, FireWire. Apple had the guts to push the new technology so that the peripheral makers started making more products, and the PC makers followed by offering those features on their machines too. And it works both ways, Apple now supports inexpensive PC peripherals: I can buy a cheap IDE hard drive and VGA monitor for my Mac if I want. I'll admit that Macs aren't for everybody. But then, neither are BMWs. Some people are more comfortable driving Chevys, and if they're happy with that, fine.

Yeah, that disappointed me too. With all the PC shareware/freeware utilities for Poser, I think it's almost worthwhile getting Virtual PC to run them. Making a Mac version of a program is somewhat more difficult than making a Mac-readable CD with, say, models and props, which are basically data that can be fairly easily converted from one format to another. Programming for different systems involves different ways of doing things (reading and writing files, drawing windows, etc.) that have to be taken into account in the way the program is written. It would be nice if the Virtual PC folks could provide PC developers with a kind of "emulation wrapper" they could put their program into to make it quickly Mac-compatible (although with a tremendous performance penalty). I suspect the RealPlayer people have done something like this with their product; if you look at the minimum system requirements of their Windows vs. Mac versions, the Mac version needs about 3-5 times the processing power as the Windows version.

Attached Link: http://asu.info.apple.com/

Actually it's Indeo -- a video codec developed by Intel and used in .avi files. Search Apple's software downloads for "Indeo" and you'll find them. At the moment there are versions 3, 4, and 5; later versions don't supersede previous ones, they implement different methods of compression, so you'll need them all to be able to view most of the .avi files out there. They go in the Extensions folder, where Quicktime uses them as needed. http://asu.info.apple.com/

Mighty peculiar. The trick to doing tests like these is to change as few variables at a time as possible, and note the differences. What seems to be happening here is that the falloff is interacting with the **scale** of the camera -- which Poser changes on its own (along with the camera position) when you change the focal length. It must be how they simulate the focal length effect, since the camera doesn't really have a "lens" to adjust. Nance's example file had the camera's focal length at 110 and the scale at 300. Once I set them back to 35 and 100 (the default, and the settings I used in my tests previously), the falloff worked as expected, as shown in the top screenshot. I've added some measuring sticks (stretched square props) to help indicate the distance: 0 is at the light location (z=2.7), the others at whole unit positions as shown. The front of the steps prop is at z=1 (1.7 units from the light), while the "wall" is at z=0 (2.7 units from the light). I've also pasted in a shot of the light settings, which are the same in all screenshots. With Distance Start = Distance End = 2, the light reaches the top couple of stairs, but not the measuring stick at 2. Then I changed the focal length to 70. Poser altered the camera position and scale as shown in the second screenshot, and you can see that the falloff pattern has also been altered. According to the manual, the camera "scale adjusts the dimensions of the studio in the window." That is, it seems to act as a **multiplier** for the dimensions. That's why the falloff is changing: at 200% scale, the falloff settings are effectively 200% of what the dial shows, or in this case, 4 -- as shown in the third screenshot, with the steps moved back by 2 units. As in the second screenshot, the light reaches the top part of the stairs (at 3.7) and cuts off before reaching the measuring stick at 4. In the fourth shot, with the steps back in the original position, I reset the scale to 100, and the falloff was back to the same as in the first screenshot: the light reaches the top couple of stairs, but not the measuring stick at 2. So to get predictable results, be careful to ensure that the scale of the camera is at 100%. If you want to do a "vertigo effect" (which I believe is the name given to Hitchcock's effect, since he first used it in the movie "Vertigo"), as JKeller said, you'll have to animate the distance falloff -- if the falloff is important in the scene, otherwise just set them to 0 to shut off the effect. At least now there's a way to calculate what they should be. So, set the first frame with the camera at 100% scale; set the last frame at the desired focal length, note what the scale is, and multiply the distance falloff start and end by that percentage to get the numbers for those settings in the last frame. Another funky thing I've noticed, if you change one of the default infinite lights to a spotlight, both distance falloff dials are created with maximum limits of 1, so if you have "Use Limits" checked in the Figure menu, it won't let you set them above 1. Just double-click the dial and enter a high maximum value, if you don't want to shut off limits (which may affect your poses). If you create a new spotlight, the maximum limit is set for a very high value already. By the way, I didn't know this stuff before -- I've learned it over the past couple of days in working out this puzzle and figuring out why we're seeing these effects.

Well, it looks to me as if the distance falloff does use the same units as all other measurements. (I read somewhere that 1 unit = 8 feet.) Look at these screenshots: the squares are at Z=-1, -2, and -3, the light (represented by the flashlight prop) is at Z=0. (The red text was added to the screenshot later to label the distances, the lines are approximate.) One thing blurring JKeller's test is the angle falloff he's using; I've set them to be identical so the spotlight gets a sharp edge. First off, if Distance End = 0, the effect is shut off, regardless of the setting of Distance Start. The light is at constant intensity along the entire length. The second example shows Distance End at 3; the light falls off gradually, and the third square is not lit. In the third example, Distance Start is at 2, and if you look carefully you can see the gradation of the falloff between 2 and 3, whereas the light is constant intensity before 2. I forgot to include a screenshot with Distance Start = Distance End >0, but in this case you do get a sharp edge. The "take home message": To get a graduated falloff, Distance End has to be set for a somewhat larger value than Distance Start. If Distance Start = Distance End (and > 0), you get a sharp cutoff of the light at that point -- great for getting a spotlight effect on a figure in the foreground without casting a shadow on objects behind. That's what's happening with JKeller's example above.

Zip files are little problem with MartinC's utilities Maconverter and Macinstaller. (Of course Mac users also need a recent version of Stuffit Expander to expand the zip files to begin with.) Maconverter takes care of fixing the file signatures, converting .rsr and .pcf files. Macinstaller puts the files in the designated place in the Runtime directory, as well as fixing internal file references so Poser knows where the textures are without having to ask all the time. Both utilities are available in the Freestuff section here, for any new Mac users reading this.

As I understand it, if you have the Pro Pack you can import your clothes obj, go into the Setup Room and load the figure it's for, which shows up as the "bones" which I believe is the visual representation for both the hierarchy and joint parameters. I haven't tried it with clothes, but I did import a critter I modeled elsewhere, then loaded the horse figure, and the joint params needed only minor tweaking.

Thanks, I'll try reporting it to Microsoft.

Eric, thanks again, I got the download the last time around and it's pretty slick. (Although unfortunately it doesn't support .obj format directly, so I use .3ds to move stuff to and from Poser.) One question, does having this free version of Amapi 4.15 qualify for the upgrade price discount for Amapi 5? :-)

1. Yes, if you have need of the new features. You can download the manual (in PDF format) from Curious Labs. My favorite new features include the Setup Room, which makes it easier to split up an imported model into body parts for posing; multiple views; and motion blur for animations. I haven't gotten into Python scripting yet, but that has a lot of potential. If you use Poser mainly for stills instead of animation, and aren't interested in setting up your own models, the Pro Pack probably doesn't have much else to interest you. 2,3) For me the biggest "bug" (actually as I understand it, it's an improved file-reading function that shows up bugs in the way Poser originally wrote files) is that some characters with a lot of morphs will load in with polygons missing. The workaround is fairly simple (search the messages here for "missing polygons") and Curious Labs is reportedly working on a patch so all existing characters will load as expected. 4) There are 7 cartoonish figures from DAZ included. You can see them used in many of the web banners advertising the Pro Pack. DAZ has also relased freebies of cartoon kids and a dog, so grab 'em now from their web site.