CompuServe Messages

I'm sorry about not signing my posts. It's not my idea. My boss just doesn't want our names to be used here. It's his account, so I gotta do what he says. If it were up to me, I'd be using my real name. David, your faith in Autodesk is touching, but mine took a serious nosedive when we got in "Release 4" and saw just how little we got in the way of real new features in the program itself (as opposed to plug-ins and an extended API to enable IPAS4 developers to make better plug-ins). We got NOTHING along those lines except for being able to treat fields as frames, and then only by modifying 3DS.SET for all slave machines — it can't easily be set or unset on a per-project basis. Also, that feature seems to have some serious problems in its current implementation, enough so that it's basically unusable as-is, but that's a subject for another post. Also, I'm a programmer myself. I have been programming for decades on a wide variety of platforms. Here're the facts: 3D Studio itself can be feasibly ported. Existing IPAS routines cannot. Period. Would you use 3DS on an Alpha AXP if it meant you'd have to give up ALL your .IXPs, .AXPs, .SXPs, and .BXPs except those that their developers decide they want to port over? And wait for them to get around to doing so, _if_ they're gonna do it? You could still use .PXPs and .KXPs on your Intel machines since their job is done before rendering time, but you couldn't even use Alphas (or SGIs etc.) as SLAVES if your project required even ONE SINGLE unported .IXP, .SXP, or .AXP, and without ported .BXPs you might have to do some serious file conversions before and/or after rendering. IPAS routines are solidly based on the Intel/DOS/Phar Lap platform. Change any one of those to a non-compatible replacement (changing the Intel 486 to a Cyrix or AMD 486 wouldn't count, for instance, but, say, changing DOS to Windows NT or UNIX would) means they won't run anymore. At all. Period. They have to be rewritten AND recompiled. Not just recompiled. Perhaps a few could get away with mere recompilation, but that's still not something the end-user can do. TSE alleviates that by providing a high-level language for plug-ins that is NOT based on any one platform. TSE would have the same keywords and structures regardless of the underlying CPU or operating system that 3DS and TSE are running under (this assumes, of course, that KUB ports TSE itself, but that's a LOT more likely to happen than asking dozens of IPAS developers to port hundreds of IPAS routines.