Hi

Yesterday I was talking to the design team at work about P5. I told them that CL were working on a release for mac but no release date yet.

Well I was going through my morning mail and a thought suddenly hit me. OSX is based around a BSD unix-like release. I would guess that if CL is going to port P5 to a BSD platform, it should be possible to go a further step and port to Linux.

Oh no! you say- why?. Well two things, Sun are using linux for a base platform for their workstations and servers. The likes of WETA (Lord fo the Rings)are using linux throughout their production cycles (workstation,servers and render farms)

I have a linux workstation at home. I don't really notice it because it sits there and does it's work. Period.
Its been working without any interuption since I first booted it six months ago apart from a powercut (it self- recovered).

The greatest suprise is comparing it to my server (running SQL on WIN2K server). The cost of the software is easily twice the cost of the hardware.

The cost of my linux (Mandrake 8.2) is - nothing. So we have an ultra stable OS capable of running high end graphics (given the right hardware) that is beginning to be used by the pro's for serious work. Should'nt we really all stop and think about this?

If CL wants to really break in to the higher end of the business (and with future iterations of Poser 5 they may well have the opportunity) they should consider modifying the Apple based release for high end Linux workstation in the future.

PaulC

A Linux version of Poser5 would be great, most of the problems that people have with Poser is due the very unstable Windows. CL, remember that Maya 3 or 4 has Linux version

• most of the problems that people have with Poser is due the very unstable Windows * Apart from the big professional apps, which are heavily tested and supported, I have never seen a unix/linux using the level of resources that Poser requires. While there may be some reason for optimism, this is as much unknown territory for OSX/unix/linux (which are also 32 bit) as it is for Windows/NT. What I do know is that badly resource managed programs cause problems on unix systems in exactly the same way as they cause problems on Windows systems. Its always intersting to note that the system configuration/memory management issues that P5 users are having to deal with are very similar to those that DOS users had to deal with with apps that were pushing the 640K limit. P5 is going to push the absolute limits of ANY 32 bit operating system, and while some may handle extreme resource usage better than others, this is always going to be a danger area. Bill

The problem is that the biggest part of the port isn't in the basic platform code, it's in the GUI.

Yes, Mac OS X is a BSD-based UNIX, and Poser could in theory use straight UNIX coding for file I/O, memory management, and all the other utility functions. However, to run on Linux or FreeBSD (or even a straight Darwin) they'd need to build their GUI around an X11 model; while to run on Mac OS X they'd be using Quartz (and ideally OpenGL, but from what we've heard they're not initially doing real 3D screen output).

[You can run X11 on Mac OS X, but it looks really poor next to native Aqua applications, and it'd be foolish for any commercial Mac product to go that way. It does make sense for free Open Source applications, in some cases, but only because it's easier to port the code that way and in most cases nobody's going to invest the time and money to do it right.]

Furthermore, going "UNIX" would mean abandoning support for Mac OS 9 -- or supporting yet another substantially different code base to do it differently.

So far, the writing on the wall seems to be that the Mac Poser (if it ever really happens) will be Carbon, not Cocoa or UNIX -- that is, it'll use the improved versions of the traditional Mac toolbox that can be made to work both on Mac OS 9 and Mac OS X. A Carbon application cannot be made to work on Darwin, Linux, *BSD, Sun, etc. It's Mac-specific just as the Windows version is Windows-specific.

They could certainly do a third UNIX/X11 version, if there's enough demand. If they stick with POSIX and portable X11 interfaces, they should be able to build it for just about any UNIX. It's not a trivial job, though; and adding extra UNIX versions isn't just about recompiling... the big cost is in testing and deployment.

For 3d engines the most important part is system independent, unless you do bad coding that requires the use of lots of dlls. If you use only plain C is also machine independent, if you use C and Assembler for improving speed, the assembler code dependents on the CPU (Intel class for PC, and Motorola for Mac). The parts of the code that dependends of the operating system are: - One part (very small) that deals with requesting and allocating memory, and file I/O can be done with standart C libraries. - For the video you only need that the operating system returns you the video memory pointer. - The last part that depend completely on the operating system is which deals with the user interface (GUI). This part is a very easy one (compared to the 3d processing). So with good software programming is very little overhead in making different versions for different platforms.

Hi Williamsheil. Good points. Some of my frustration with Windows -and I have been running Windows ever since NT3.1 (now there was unstable!) has been the resources the OS actually take to run. Today I have been playing with my latest toy(new PC) It has a Matrox Parhelia 128MB workstation card. The device driver has a .NET interface - it needs huge resources from my system that I need to use Poser. A comparison - ATI radeon driver 3,244K, Matrox Driver 22,148K. I agree that poser puts extra-ordinary stresses on any system. I do not know if Intel Hyperthreading technology or AMD's Hammer would actually improve things as far as bus width is concerned. I am somewhat surprised that CL does not take into account some of the technologies that the graphics cards are beginning to incorporate into their engine (hardware displacement mapping and such) We seem to be reaching a point within the process that Poser is using the CPU/RAM for rendering operations and leaving a specialised,made for the job rendering engine quiescent. dbutenhof Thanks for the update. Sad that is probably going to be carbon based. kawecki That was my understanding of the problem. PaulC

Also sad because a staffer at the Apple Store in Mall of America (Bloomington, MN) told me 2 weeks ago that their software shelves won't stock anything that isn't OSX native. Since their graphics shelf includes other former Metacreations products like Goo and Bryce, this is a damned shame.

Well Steve jobs has declared MAC OS9 "Dead" Apple enjoys tremendous OSX support from the highend 3D and video editing community Newtek,MAXON,Discreet, Adobe Macromedia etc. their is no further new developement for OS9 and this new Alleged Poser like DAZ program will likely suppot OSX so its inevitable that MAC OSX will be the domninant OS on the mac Sooner than later. So CL will be smart to get on board ;-)

"This part is a very easy one (compared to the 3d processing)."

Most people who think that tend to develop really bad interfaces. But yes, in this context my answer was probably overly general. Your statement may be more nearly true for an "oddball" program like Poser, with the Metacreations "unique" style interface. They still define system menus, but virtually everything else is custom, presumably built on lower level graphics operations.

While you CAN use standard ANSI C or C++ runtime functions for I/O and memory management, that's not always the best choice for systems that aren't inherently standard-based. On Windows and Mac OS 9, for example, those functions have to be EMULATED by building standard-interface wrapper functions around the proprietary equivalents. The equivalents are never quite close enough, and often the wrappers end up being complicated and expensive. Not necessarily the best choice for an application that's already resource hungry.

This wouldn't be an issue for a UNIX API app that might run on Mac OS X and other UNIX systems, since they are standard-based; but as I said, the CL statements so far suggest they're likely to go with Carbon interfaces. While they might reconsider that in the wake of recent Apple announcements, they are presumably starting from the Poser 4 Mac OS 9 code, which is essentially Carbon, and they're unlikely to start over again from scratch. (Consider already the complaints that Poser 5 Windows is a "retread" of Poser 4 with some plugins. True or not, it suggests that much of the central code has been retained.)

There's no problem with ansi C in windows: For memory only I need malloc, free and realloc. For I/O: fopen, fclose, fseek, fprintf, fscanf and fread. These are standart functions (stdio.h, stdlib.h) builtin in all C compilers.

"There's no problem with ansi C in windows"

Nor on any platform with an ANSI C compiler environment, if you're only interested in API. But that wasn't my point. It's EASY to port that way, but it's usually not the most EFFICIENT port on any system that's not inherently a POSIX/ANSI C environment. Linux, Mac OS X, Solaris, IRIX, HP-UX, Tru64 UNIX, Free/Net BSD, and so forth ARE, and most code can't do better than the ANSI/POSIX interfaces.

On most other systems, like Windows, Mac OS 9, OpenVMS, OS/400, and so forth, the standard API is usually a wrapper that adds overhead to the basic function and may involve expensive and tedious translation, or multiple native OS calls that are needed to meet the portable API but NOT needed to achieve what you're actually trying to do.

If the call isn't critical to application performance, some overhead may be fine. If it is critical the portable interfaces may be a bad porting strategy.

Again... I'm speaking in general, not specific, and this argument is getting increasingly pointless and off track. ;-)