CompuServe Thread

Am I the only one who is majorly disappointed in the Release 4 announcement? When I see a new version of a product in which the integer portion of the version number is incremented, I expect MAJOR NEW FEATURES added to the USER-VISIBLE portion of the MAIN PROGRAM ITSELF. I do not expect to see a few new developer's interface features added plus a heap of sample apps that make use of those features, with a few token users improvements in the main program, NOT when the INTEGER PORTION of the version number has changed! As far as I can tell from R4FEAT.TXT, there is only ONE new feature in R4 itself that is directly visible to and usable by end-users without involving IPAS plug-ins, and that is the ability of the Keyframer to operate in field mode (as opposed to just being able to render in field mode), so that keys can be set on a half-frame boundary. That's a major improvement, but so was anti-aliased text in Animator Pro and THAT didn't even justify incrementing the DECIMAL portion of the version number (it went from 1.3 to 1.3a), let alone the INTEGER portion! Also using AniPro as an example, when it added major new capabilities to its POCO language and some nifty new features in the main program itself, it only incremented the DECIMAL portion of the version number, albeit by a heftier jump than usual (1.0 to 1.3). I expected R4 to implement several new features within the main program (such as object cameras, infinite mapping, etc.) and whole new classes of IPAS routines (such as .RXPs for Rendering eXternal Processes such as Raytracing and Radiosity) which couldn't easily be implemented via existing IPAS capabilities. R4 may be able to fake object cameras via its new Keyframer Scripting .KXP, but that is a kludge. REAL object cameras would've been much better for just about everyone concerned. As for Raytracing, I just don't see that as being possible on a per-material basis (so that one need not raytrace a whole scene just to get some water droplets on a tabletop to refract) without something like .RXPs. I suppose Microsloth started this trend with Messy-DOS 3.x, which wasn't anywhere near as much of an improvement over Messy-DOS 2.x as 2.x was over 1.x (the latter was warmed-over CP/M-86, while 2.x added XENIX-compatible handle-based heirarchical file structure such as subdirectories and I/O redirection), and the change from 5.0 to 6.0 was a joke! It added only a very few user improvements to the DOS itself, and instead added a pile of utilities such as the third-party had all along. Speaking of DOS, by tying R4 to it still, I feel 3DS has dug itself into a pit which will spell the end of its dominance in this field. With Real-3D, Caligari TrueSpace, and a host of others out or coming out for Windoze, and with 3DS's flat-out inability to run AT ALL under Windoze Empty (even in DOS emulation mode! — and remember, under Windoze Empty and Windoze 4.0 aka Chicago, there is NO MORE REAL DOS ON THE MACHINE unless you're willing to resort to Dual Boot or Boot Manager or booting off of floppies or some such!!), people who are trying to get away from DOS will be a much harder "sell" than they were. Yes, I know the main reason for this is that existing IPASes are tied to the Intel/DOS/Phar Lap architecture. But working on means to allow IPASes to be re-compiled with minor modifications would lower that hurdle. Of course, Real-3D doesn't have this problem since its extensibility is done by an actual programming language included in the system rather than a set of developer APIs. IPAS's power helps keep 3DS competitive in power and features, but its dependence on Intel/DOS/Phar Lap may offset that by keeping 3DS tied to an obsolescent — dare I say downright obsolete? — architecture, at a time when the rest of the industry is abandoning it in droves.