CompuServe Thread

Damn David, you're hot on the keyboard. I'm still sending my message out though, even though its almost word for word the same sentiment. <g> John

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.

No doubt I will. Gary has already mentioned at least one new feature for r"5" that will be an actual new feature in the program itself (even complete with a USER-INTERFACE and not just a 3DS.SET parameter!), not a plug-in, extension to the plug-ins API, or performance increase. Do you know just how many such features r"4" has? NONE! ONE if you remove the requirement that it should have a user-interface, and even that one seems to need a lot of work before it's ready for prime time! I don't blame Gary for this. Gary's a VERY good programmer and an all-round great guy. I blame Autodesk. It is their policy, not Gary's, that prohibits any user-interface changes (however tiny and/or desirable or even necessary) in interim releases. The fact that r"4" has no such changes (other than "Release 4" appearing in the About 3D Studio dialog box instead of "Release 3," but I hardly think that one counts! <grin>) that is the primary basis for my stand that r"4" is actually at best r3.5, an interim release marketed as if it were a major new release. r2 and r3 were true major releases with great new features. I expected similar from r"4". Silly me, both from having such expectations based on both the history of this program itself and the traditions of the computer industry as a whole in reserving the integer portion of the version/release number for MAJOR releases with MAJOR changes, AND for feeling "cheated" as a result. Silly me for accepting the word of an official Autodesk Press Release (one that leaves no legal "out" for them!) on the Spline Patch Modeller, feeling major disappointment at the realization from that Press Release that r"4" was really r"3.5" at best with some add-on goodies tossed in, and basing the decision that the upgrade price was still worth it on the basis of the value of the promised goodies INCLUDING THE SPLINE MODELLER, and feeling "cheated" when it didn't show up. I suppose I should just accept that in these days of politicians who feel that promises are made to be changed on a whim, that corporations who sell software our business depends on should not be held to a higher standard than our elected leaders. I should not feel cheated when they simply do what our elected leaders do all the time. I suppose that if I bought a car that was advertised as including a surround-sound CD system for $XX,XXX.XX, and that said sound system was a major factor in my decision to purchase said car, but the manufacturer of the car lost the rights to include said sound system but still charged me the same price as was advertised, "but, to make up for it, we'll throw in this nifty piece of cardboard you can put in your windshield when parking out in the sun to keep the vinyl of the dashboard from bleaching and turning brittle!" even though said piece of cardboard doesn't even approach the value of the sound system AND I already HAVE one of those cardboard thingies, I should not feel cheated. I should not expect the automobile manufacturer to either lower the price from what was advertised, nor substitute something of at least EQUAL value for the lost sound system. Shyeah, ROIGHT!