This is a tricky issue: I’d love to have EIM back, but I just bought Amapi+Shade for about $180 (there was an special offer some weeks ago, so I decided I’d try to adapt to its 3D cursor GUI, which I don’t like very much) and being currently exploring its feature set, I believe EIM ought to get an assortment of new tools (and resolving the outstanding problems in some of the current ones) to be able to compete with the Rhinos, Concepts and Amapis out there.
Getting to the questions:
1.- Would you want a UB version of EIM?
Yes! Yes! Yes!
2.- What kind of upgrade price would you pay for it?
If it was just an UB port with no new features… Let’s say $70. It is just that I hope to be able to run it on either Rosetta or Parallels, so there is not so great an appeal.
If we are talking some new features (the easiest to implement as derived from the latest ACIS engine tricks, perhaps) and a bit of GUI renewal (there are some really small things that would help a lot, for a start), then I think these $200-250 would be pretty decent in exchange for your commitment to further develop the app.
3.- Would you want it offered standalone?
EIM as a standalone app? I wouldn’t mind EITG selling it as such. Whatever works best. Discounts for EIAS-EIM combo upgrades would be nice, though.
4.- How much would you pay for a standalone version?
I don’t know. One would have to compare it with the rest of the conceptual modeling apps out there, performance/price wise. As it is right now, it being comparatively so spartan tools-wise, it ought to be priced lower than Rhino ($895) and Amapi ($750 including Shade, a complete 3D package posited as its render engine, which is a bit of a mess of an idea, but
). Say, $400. If we are talking an enhanced revision of the app with some significant new features, I guess we could talk $600+.
5.- Should EI go with EIM or create something entirely new?
I like EIM a lot, even if it frustrates me a lot, too. Go for something entirely new? I don’t know: I wonder what such a thing would look like, and how much of a market there is left for each style of modeler (conceptual, CADish, SDS, classical or some hybrid). As I said, I got Amapi because it looked like a possible EIM substitute, but one of the things that attracted me to it was that it looked like being a through-the-looking-glass Alice to Hexagon. Hexagon is a SDS modeler with conceptual design-like tools (Coons, Gordon, sweeps, construction history), while Amapi Pro is a NURBS Surfaces-Poly (no true Solids, I believe) modeler with some SDS-style editing tools (v.8 will get more Hexagon-like, it’s been said). I like the idea of having the cleanliness and precision of NURBS modeling as a nucleus, so whatever gets developed I wouldn’t want to miss that (if anything, I’d kill for being able to not deal with NURBS at all, as I am a Bezier guy deep down. I know, I know… ).
6.- Due to the base differences between EIA and EIM and the way the two handle geometry, should EIM evolve into the next EIA? (In other words, should EIM eventually include next gen animation capabilities?).
EIM as an animation package? Mmmm. If EIM turns into an standalone app, it will need some animation and render options (at the very least, animation ones for doing basic fly-bys and things, say, FormZ-style. Render ones could be a Camera module or ways of interfacing to popular renderers such as Maxwell). EIM as EIAS’ heir, a NURBS animation package? I don’t think it would work without having poly tools or at least poly model importing capabilities too.
Also, your question could be interpreted as: do we want the Holy Grail of full modeler/animator integration into EIAS, like Cinema4D, Maya or 3DMax do? Yes, that would be absolutely great, but is it achievable with your resources?
If this is simply an innocent “do you think having to deal with separate EIM and FACT asset files, model tesselation and such is bad for your workflow” question, then I would say I can think of some ways to improve it, like, say, having some sort of fused EIM/Fact single container file format and some other things.
7.- Should EIM be capable of accessing Camera by itself?
Yes, actually, because it implies that we should be able to texture our models inside EIM. Texturing while modeling is usually easier than only being able to deal with it after the fact. Also, if EIM becomes an standalone app, it’ll need texturing tools and the ability to invoke a renderer, be it Camera or others.
And what if EIM simply gets UB’ed and development gets restarted? Well, I’d be very happy, too. (Has the ACIS licensing issue gotten a bit less insurmountable somehow?)