Peter…
Thanks for the level headed response. The EI community has always been a passionate bunch particularly when we address the future of the software and its various hang ups. I’m sure there are very logical reasons why the package operates the way it does and why it may or may not be able to support certain capabilities easily and those others not so easily.
I’m afraid that I can not comment whether or not the Xcode transition will actually improve EIAS’ framework or not. I’m fairly certain that it was a pretty straight forward port, so what existed as a problem in pre-Xcode, may still exist today. But hopefully X-Code will make it easier to expand EIA’s capabilities. I’m sure the programmers would love to broaden EI’s API and framework, but I think it may be wishful thinking to assume that old legacy code isn’t still lurking around in there somewhere. Anyone who’s programmed can tell you that the further down you go into the base code the more issues you dredge up. Minor tweaks can cascade into major problems if they’re not careful.
I’m also not qualified to determine if EIM or EIA is a better program, programming wise, for framework expansion. I only side with Modeler because of the typical pipeline we tend to work with more often when doing 3D. All 3D starts with modeling. The routines necessary to modify geometry down on the lower level “seems” to be already “there” in EIM. The subsystems EIM lacks, like texturing for instance, can be inserted into EIM easier than trying to pull out and repair older systems in EIA. If we wanted a nodal texture editor, would it be easier in EIM or EIA to integrate? I don’t know.
We’ve been asking for a number of tools all throughout EIA’s history. We need a UV editor… yet we’ve never gotten one. Its certainly not the lack of skill on the programmers to create an UV editor, it just may be that a UV editor in a program like EIAS, that doesn’t have any sort of modeling subroutines, just might be a real pain in the ass to add. I don’t know. But in EIM, the modeling infrastructure is there. The idea of adding a UV editor to EIM seems logical.
Animation capabilities, I believe, are considered “high level” systems. As opposed to modeling which I consider a “low level” system. Each new system, as its added, is dependant on the one below it and as I stated before the lower you go, the more changes are going to cascade up through the system. Adding modeling tools to EIA (in the core)seems to be going backwards…which I think would be harder. I could be wrong.
So which is going to be easier to make modifications to? IF my theory about the two programs is correct, adding modern systems to EIM should be easier than taking out and replacing systems in EIA.
So that brings us back to the original issue. Say EIM is resurrected…depending on EITG’s focus, a decision will be made on how to repurpose that technology. Perhaps some of modelers’ sub-d capabilities can be brought over to EIA easily. That could be a boon for EI users wanting to do character animation in EI…but EITG could decide that CA isn’t where they wish to focus their efforts. In that case, keeping Modeler a separate package makes perfect sense. The current paradigm is fine for the architectural markets and hard surface animators.
My job on the advisory board is to speak for the film, vfx and entertainment industries. For me, finding a method to integrate vertex level animation controls into EIAS is important. But so is better tools to help out Camera Mapping, UV editing, Camera tools, Rigging tools and so forth. Separate modeling and animation environments are a holdout from the early days (IMO) and it makes it difficult to achieve strong character animation. (Also my opinion). But there are other ways to address that too. Perhaps new bridging tools in other applications in addition to continued FBX support can make it easier to bring things into EIA. Problem is… it may be in there, but you can’t really edit it…effectively. Plus it keeps EIAS in a second class status compared to the Big 5.
I just want to think about EIAS’ future. If we are to address new technologies into EIAS, we may have to start thinking about how we’re going to provide that on a 17 year old framework…or we start planning for a new system. Programs evolve. They also die. PowerAnimator gave way to Maya. Wavefront merged into Alias. Kinematics and Dynamation also were absorbed. At some point EIA will need to be put aside for EITG’s next big thing. We can’t do it now because we need EIA and EIM to rekindle the company. EIAS still has some life in it… and who knows, maybe she’ll take us yet another 17 years.
As users, we don’t run EITG. However, its our relationship to the package and how we utilize it that helps shape EITG’s decision making process. I just want to find a way for the users to find their voice.
