CompuServe Messages

Hi Tim, True, what you mention about those listed tools not having third-party plug-in developers. Then again, the only published API in that list that I'm aware of is from Specular, and no one (to my knowledge) has taken them up on it. This seems to be the limiting factor… can't plug into an app if there's currently no SDK for it! <g> This seems natural to me… new technologies are first spearheaded, and only then have a wider impact. Has to start somewhere. The pressure is certainly on plug-in developers to get a wider possible market than any one 3D tool can offer… this is incontrovertible. And this next year will be interesting, when DOS and Phar Lap are left behind and PC development is forced to move to 32-bit Windows…. I hear what you're saying, though… porting to different APIs is expensive, and it would be more pleasant if there were a standard exchange format. An exchange format and discrete apps would disable callbacks to the host, however, and that's a *big* disadvantage compared to plug-ins. fwiw, most 3D APIs I've seen have a great deal of functional similarity. I'm hopeful for the future. Not sure I understand your next-to-last paragraph — the failure of texture maps is exactly the same failure of polygon-based modelers, and that's resolution-dependence. Procedural textures and parametric surfaces are resolution-independent and also offer additional flexibilities. If other apps only offer the ability to texture through bitmaps, well, that's their problem. It's sort of like, should NewTek be faulted for supporting general polygons, because 3D Studio can only handle triangles? RIB can describe polygon lists, but most tools that write RIB default to exporting at the advantageous patchmesh level instead… tools which can only read polylists will be at a disadvantage in RIB, unlike in the least-common denominator format of DXF where everyone is forced to a common ground. Even if we had a more robust common 3D exchange format we'd still have the same problem, even for just geometry: at what level should shapes be described? If a poly-based tool received a NURBs-based file, would it be the receiving app's responsibility to reinterpret this geometry? Or should it be the exporting app's responsibility to include multiple representations of the same geometry? ("Yikes!" to file size!) The RIB spec includes a header line for "Capabilities needed"… this is where optional features, such as procedural surfaces or stochastic motion blur, are listed for quick preview. If a receiving renderer cannot support, say, pixel-based displacement, it should ideally degrade gracefully and just not use that part of the file, while still accepting the features it can support. Anyway, knotty issues, good conversation! <g> I'll bring these sentiments back to the gang at the office, thanks! Regards, John Dowdell Macromedia Tech Support