CompuServe Messages

Uh, who's "Bill"? There is no "Bill" at M&M Communications Concepts. As for "flame messages," I guess either you or Compuserve has a way different definition of "flame" than the other systems I use more (GEnie, etc.). To me, a "flame" is a rant that contains personal or argumentum ad hominem attacks against other users, and a "flamewar" occurs when the attacked users respond in kind, resulting in spiraling escalation of insults and pointless attacks. I don't recall ever once, in any of my messages, referring to other _people_ in a negative way. I do refer to _actions_ in a nevative way, such as saying that the people at Autodesk shouldn't do or have done thus-and-so, but I don't, for instance, call them names nor cast aspersions on their character, ancestry, etc. Yet, in the course of this thread alone, I have been called "negative," my "credibility" has been questioned, and I have even been accused of being under the influence of "PMT" (apparently the poster in question meant to say "PMS"). And now I have been accused by you of "get[ting] bent on these flame messages." Unless the definitions differ here, that is like accusing the Jews in Nazi Germany of genocide! Note that even now, I have not said anything negative about you as a person nor made any insults. I have only responded to what you actually said. My original post which started this thread was not negative nor an attack on anyone. It was not a "flame message" by any of the definitions I've known. It wsa a simple informative post aimed at those who don't have budgets of five figures annually to spend on IPASes. It was meant solely to provide data that I wish had been available to us, namely, informing that some IPASes that have been advertised as doing things that could not be done otherwise simply don't do that. We bought Python because we needed to do an animated signature for a specific project. We read here on this forum that the ONLY WAY to do so effectively was with Python. No one suggested animated opacity maps. When we bought Python and I saw what it actually did, I was very disappointed to say the least. The money we spent on it could have gone to some other IPAS, even one from the same company (Schreiber), that did something we needed that could NOT have been effectively done by some other means. Basically, I thought from the description given here that Python was an .AXP that did what it did on a single mesh at render time. That at least would be efficient. But the way it is now, as a .PXP which makes morph targets (one PER FRAME for acceptable results!), is as inefficient as, say, Morph Materials in place of VARY.SXP would be — and far more so. I can see a use for Python: namely, when the _end_ of the lofted object needs to be seen face-on or from a view where it needs to be present and apparent. Animated opacity maps can't do that. But for signatures, that was not the case. Python may be "so cheap" to you, but to some others here, _any_ cost that is not truly necessary is a liability that we don't need. Not just in the loss of cash flow itself, but also in the loss of having some other tool of about the same cost that would have done something more valuable for us. Python really does need to be an .AXP, the more I think about it. Not only is the .PXP woefully inefficient (creating all those morph targets eats RAM in prodigious amounts), but it just isn't powerful enough. Suppose, for instance, you want to have a _rounded_ or variable-shaped end cap such as (in the classic Python example) liquid flowing through a pipe would have. Python can't do that, since lofted objects are _always_ made from flat shapes that are lofted and all it does is move vertices down the path, so the end cap is _always_ flat. End caps of other shapes would require adding vertices, and that just can't be done with morph targets. .AXP has no such limitation. Or how about scaling the animation for more frames, say, if your client says the signature goes too fast? With Python as a .PXP, that means redoing the entire Python process from scratch to accommodate the new frames. An .AXP would simply handle the frames as-is. For the same reason, Python.PXP can't be trusted in field mode (as the documentation itself states — something else that wasn't known to us before we bought it), whereas an .AXP could handle fields easily. There. A constructive suggestion on how Python can be improved to be a truly valuable product. Satisfied?