The only utilities you need to deal with any Poser 5 or 6 content are to decode the RTE and PCF formats (both are ways of distributing modifications to commercial meshes such that they can't be used unless you have the originals). MacConverter handles (most) PCF files, but you can also use the Free Mac port of Objaction Mover (http://www.lamarchefamily.net/nakedsoft/) if you run into them. RTE files are more common, and can be decoded cross-platform by RTEJava (available in free stuff).

Optionally, fmorgan's McPBrowserPRO (or the free subset) will convert old RSR files into modern PNG previews. (The "pro" version provides some minimal but useful library management functions, as well as an easy content installer.)

Poser 6 will not make efficient use of it

Poser isn't designed to use multiprocessing for rendering; however as much of the "infrastructure" of Mac OS X IS so designed, there will still be some advantage in normal and interactive operation even so. (My Poser process has 4 threads and frequently manages [slightly] over 100% CPU usage; even a bit more than can plausibly be accounted by roundoff errors in the display. ;-) ) But having a multiprocessor won't speed your renders -- which is what you would really like it to do. (Or at least what I would really like it to do!)

Don't try to use Poser (or any other heavy video/image/3D app) with less than 1Gb of RAM; and if you can afford 1.5 or 2Gb, go for it. I cannot believe that Poser could efficiently use even 4Gb; it certainly can't use more because it's 32-bit code. Of course if it could use 4Gb, and you had enough additional to support the kernel, daemons, and other apps, then in theory Poser might get its full theoretical maximum -- but I really wouldn't worry about that because there's no way to control memory allocation that precisely anyway

I happen to have a Poser render running in the background now; its virtual memory size is 1.34Gb, of which its got 784Mb resident (in memory), and it's not generating substantial pagefaults at the moment so its pretty happy with that allocation. Of course this is only one textured V3 and a handful of props (including some mirrors)... a more complicated scene might be able to pull down more memory.

Gee; you can squeeze her between bubbles if you try. You can leave her stuck in the middle. "So, so wrong" is so, so correct. Bizarre... but kinda fun in a twisted sort of way.

My first thought (well, OK, maybe my second) is that they should have applied some IK rules. After a moment it occurred to me that if this ever happened in real life, after a couple of those collisions, um, IK might not, uh, exactly work right anymore. That is, I don't know how much effort it took in scripting to make sure that all the parts stay connected... but you have to think the result might have been a bit more realistic if they hadn't bothered. ;-)

IBM hasn't been delivering on the potential of the PowerPC -- which is a far superior architecture to X86. (EM64T is a semblance of a 64-bit extension built on top of what's basically still an 8 bit chip architecture; PowerPC was designed as a true 64-bit machine from the very beginning. PowerPC was also designed for efficient and scalable multiprocessing, another area in which X86 is particularly poor.) With even a small fraction of the level of investment Intel has dumped into X86, the PowerPC would be running 10 times faster and 10 times cooler -- but IBM has no interest. Intel has such resources that they've managed to make a chip design that was obsolete decades ago continue to improve in performance. An astonishing accomplishment, to be sure; and the chip layout, microcode, and fab design engineers should be proud of the technical accomplishments. But that doesn't change the fact that it's an absurd waste of energy. If it wasn't totally fettered by the outdated requirements of the X86 "facade", the core of a Pentium would scream. The true technological wizardry is that these amazing chips can so accurately and completely pretend to be so much less than they really are. (It's a software emulator on a chip, really.) Apple has been building and testing Mac OS X and the bundled apps on X86 chips since the very beginning; only the announcement and public demonstration is new. They've been ready in case Motorola and IBM couldn't deliver -- as they haven't. This is a pragmatic business decision. Nothing to do with PowerPC vs X86, really; but rather with the commitment of IBM vs Intel. While the first Intel Macs are expected to be Pentium M chips, in laptops and/or mini enclosures, desktop and server systems will follow, probably with the next generation of EM64T chips.

I've been using Poser 6 successfully on Tiger; it doesn't always "crash as soon as you hit a button", but it will SOMETIMES get itself into a state where it reliably crashes when you try to select from a popup menu (like the figure or body parts menu off the Pose window). Some people see crashes in rendering, but I generally don't. I had the same popup window problem with P5 on Panther, though generally only in the material room node menus. (Though a more common problem was that the popups were only partly populated... without any node type I might have actually wanted.) And as for "Renderosity has a Mac Forum", kaveman; yeah, it does. It also, surprisingly enough, has a Poser forum, and this is a Poser issue. Makes perfect sense to talk about this stuff in either place; and even, in fact, in both places.

morgan turned me on to his app that overcomes the problem brilliantly...

Yes, the freeware is nice. Fmorgan also sells a "Mac Poser Browser Pro" that does more, in the marketplace. It's always nice to support people who release freeware by buying their products. ;-)

I've had lots of crashes selecting popup lists (as in the Pose window menus for figures or body parts), and many more times when those simply don't work at all. But while I've had a couple of render crashes, for the most part it has been rendering just fine for me. (In fact it's been chugging along for a couple of days now on a complex IBL/AO scene. Slow, yes; but it does work.)

And in general you don't need anything like the old MacConverter anymore. But fmorgan has both freeware for converting Windows rsr previews to Mac form and a marketplace program (Mac Poser Browser Pro) to install runtime packages and browse your Poser runtime. They work well, though they don't do everything I'd like to see. (But then, while I've thought of trying to write such a beast myself, I never have time to get serious about it; and I'm quite happy to support our fmorgan in the meantime. ;-) )

I've used Poser 6 under Tiger. It works "fine". At least, as fine as Poser 6 worked under Panther. Some assorted interface glitches, lots of crashes when rendering anything moderately complicated, etc. But it does run, and I haven't seen any problems with it that I didn't see before.

Much of the OpenGL "software stack" often runs within the kernel for efficiency; but, yeah, that means any bugs in the code can cause computer crashes -- something that application bugs (as in Poser) cannot do for Windows XP or Mac OS X. That certainly is a risk. You'll generally be better off with the most recent generations of video card, simply because those are the ones likely to get the most attention and testing for any version of the driver. And Apple doesn't write the graphics drivers -- the card vendor does. It does appear to be true that ATi and NVidia have paid more attention to optimization on Windows, which is unfortunate. But while the difference in rendering speed is measurable on Doom 3, you're highly unlikely to be able to notice any difference in Poser previews.

Yeah, PCI Express is more or less "another generation" of PCI; it's faster and has additional capabilities. In particular, in this context, it's fast enough to replace the AGP connection on which graphics cards used to rely because the main bus (e.g., PCI) couldn't handle the necessary bandwidth.

And also yes, "Hyperthreading" can indeed slow down a lot of parallel jobs, because the so-called "threads" are fairly simple. Most CPU chips for a long time have been pipelined and parallelized -- they can issue multiple instructions while waiting for others to finish. Hyperthreading lets the chip designers say they can fill more of those instruction slots simply by adding an extra instruction pointer (PC) and some control logic. However, because a lot of the chip logic (including most cache memory) is shared between the "threads", they do interfere with each other.

Poser isn't multithreaded (even Poser 6, so far as we've heard), but much of the OS stuff, including graphics and file access that happens as a result of Poser will run in separate OS processes or threads, and therefore, if you're lucky, Hyperthreading may speed things up a little.

Since Poser 6 can use OpenGL for previews, a fast graphics card on PCI Express might be able to render a little faster than an AGP card. But you're unlikely to notice much difference unless the scene has an enormous amount of geometry and textures... or possibly if it can render realtime animation previews with full texturing.

To get at a drive on your old computer, hook up the two computers via a firewire cable. Start up the new computer. Now start up the old computer in "Target Disk Mode" by holding down the "T" key while turning it on. The old computer will come up as a Firewire disk mounted on the new computer. Copy whatever you want! Shut down the old computer to dismount the disk.

Linking the computers by network is fine; but this is a lot easier. (Note: this will work with any Mac with Firewire back to the early G3 iMacs, but may not on earlier systems.)

Message edited on: 03/02/2005 18:48

First, if there's a 31 character filename restriction in Poser 5, it's Poser, not the OS -- Mac OS X does not have that limit. (31 characters was awfully generous in 1984, and the confusion and headaches of increasing that just wouldn't have paid off... until the major architectural changes of Mac OS X.) Most any Windows Poser 5 or Poser Pro Pack package will work just fine with Mac OS X and Poser 5. Even "" delimited directory paths for textures seem to work in Poser, but I think it requires the standard convention that the file path is relative to the Poser directory. E.g. ":Runtime:textures:..." seems to work fine, or even ":Runtimeltextures". (The leading ":" seems to be a Poser convention even on Windows, which is curious.) The only file paths I've seen problems with are files with something like this one I just found on a search... "C:poser-runtimeRuntimetextures". (On the other hand, I'd be fairly surprised if that worked on a Windows system with the textures in the normal place. Not even getting into whether the Poser application directory is "Poser 4", "Poser 5", or what...) Windows .rsr files don't work in Mac Poser; but the PP/Poser 5 .png files are just fine. There's a program in the marketplace (which I haven't yet tried) that claims to convert .rsr files to .png on Mac OS X ("Poser 5 for Mac - Converter" by fmorgan); I've got it on my wishlist but haven't gotten around to buying it. It's only $5, though.) The remaining trouble spot is encoded geometries: RTE and PCF files. There's an RTEJava utility in Free Stuff that does the former. MacConverter handles PCF, but I haven't seen anything standalone; and rumor suggests that it doesn't support all Windows PCF files. On the other hand, encoded geometry files are fairly rare, and you just need to be a little cautious in evaluating the readme file. Nearly all packages are textures and morph channels, or full geometry. (There's a "Judy Plus" package, by some name I don't fully recall, that's RTE-encoded, but RTEjava worked fine on it.) I tend to still run MacConverter in Classic when I buy a Renderosity package that uses .rsr files. (And there are some .rsr files, particularly many of BATlabs', that MacConverter doesn't quite handle right... but even though the preview image may not appear the items work just fine.) If I get around to trying the rsr converter, and it actually works, I would no longer need Classic at all. (A PCF-encoded package would have to be awfully d***mned good to make me feel bad about passing it by just on that basis. ;-) ) Of course those still using Poser 4 are a different matter: it expects to find previews in Mac file resources, and you need MacConverter to put them there. You're definitely restricted to 31 characters under Mac OS 9 or Classic (funny, just a few years ago Windows people used to joke about how only Mac or UNIX wimps would ever want more than 8 characters in a file name... that's the circle of life for you.) And watch those file paths for textures, morph injections, and such: keep it relative to the poser application directory, and you should be fine.

One thing i also would like to add in the "war" is .. Why did Microsoft build the registry? Whats wrong with cfg files just simple text based files.. its so easy ;-)

Wait a second... Microsoft did it one way. Easy, sensible, reliable, would be a different way... didn't you just answer your own question?

Macs also have serious network issues, a network of G5's will usually only run at about 30-40% max. speed. Beleive me I have used Macs for pro work but they just can't hold up to the tanks that PC's have become.

Ah, more misinformation and ignorance. Yes, that'll help. PCs are "tanks"? Tanks full of what...?

Well, since my earlier comment was 'off topic' I'll share some of the info given to me by a good friend and co-worker, who also happens to be the creative director for Smoke & Mirrors. Mac's operating system is the issue. It's written in a language that has to do something like three times as many translations as Windows, which is closer to machine language relatively speaking. This is the issue first and foremost.

That's just ignorance. The ignorance may not be deliberately malicious, but that's still what it is. Both systems are written principally in C and C++, with some assembly language in the bottom machine-dependent layers. As are all modern operating systems. Your creative director may be trying to contrast C/C++ against Cocoa (Objective C), but without any real understanding of what they are. Objective C is really just C with some object-oriented extensions... the same as C++. Obj-C is more like Smalltalk than C++, with better support for runtime polymorphism; but the runtime costs are small even where the features are used, and nil otherwise.

And even so, this isn't the kernel, or even the low-level runtime libraries, (which are Open Source Darwin/BSD and GNU) but the complex of object frameworks that comprise the Mac's Cocoa GUI environment. Don't imagine for an instant that the Windows GUI class libraries are any simpler or "closer to the machine"; it ain't so. And while the Mac GUI is accelerated by 3D rendering hardware, that's an innovation that Microsoft hasn't yet copied. (Though they've already announced that they will for Longhorn, when and if it ever actually ships.)

In any case, though, Poser, Photoshop, very likely Maya and LightWave, are not Cocoa (Objective C) applications; they're "Carbon" applications. Carbon is a traditional C/C++ environment that's directly comparable to the GUI environment on Windows.

By the way, Mac OS X also supports "Cocoa" programming in Java; this is directly analogous to the use of C# in .Net, and C# after all is just Microsoft's clone of Java since they weren't allowed to corrupt Java to make it nonportable. [Note that this is not to say they don't have some smart people at Microsoft. C# does have some serious technical advantages over Java; but not enough to outweigh the risks of Microsoft's anti-standards philosophy.]

Hey, if you want to use Windows, go for it. Have a great time. The fact is that very few Windows people know much about the Mac (as your friend's comments attest); while most Mac people (and all of them in any professional environment) are extremely familiar with Windows and choose the Mac. We know there are more of you, and while that can be frustrating, in the end we really don't care because the advantages are overwhelming.

And if Microsoft's monopoly marketing machine manages in the end to get you all to kill off the Mac, you aren't likely to find most of us switching to Windows. That would be just silly.