And now back to our regularly scheduled program. I2M.

Paralumino - 01 May 2009 04:33 AM

And now back to our regularly scheduled program. I2M.

Right, I’ve reviewed the old discussions in other forums and came to the conclusion that EITG is not willing to listen to the common sense. The free help was offered on multiple occasions and was turned down. There will be no more offers.
I will not going to participate in this unless EITG will significantly change their policies, this is all I can say without being sued.
Sorry, it means no UB I2M for EI.

olbicard - 01 May 2009 12:28 PM

Paralumino - 01 May 2009 04:33 AM

And now back to our regularly scheduled program. I2M.

Right, I’ve reviewed the old discussions in other forums and came to the conclusion that EITG is not willing to listen to the common sense. The free help was offered on multiple occasions and was turned down. There will be no more offers.
I will not going to participate in this unless EITG will significantly change their policies, this is all I can say without being sued.
Sorry, it means no UB I2M for EI.

This is no good. Can EITG extend the cooperation? UB I2M is so much need. Pleaseeeeeeeeeeeee.....

foreveryoung - 02 May 2009 01:11 PM

This is no good. Can EITG extend the cooperation? UB I2M is so much need. Pleaseeeeeeeeeeeee.....

Ok, ok, not really. I retract the previous post, I’m giving the I2M source code to my co-worker who will try to compile it into UB I2M. He will want to charge the nominal fee for his work since it is more than just recompiling. I promise to provide the details in about a week.

olbicard - 02 May 2009 01:26 PM

foreveryoung - 02 May 2009 01:11 PM

This is no good. Can EITG extend the cooperation? UB I2M is so much need. Pleaseeeeeeeeeeeee.....

Ok, ok, not really. I retract the previous post, I’m giving the I2M source code to my co-worker who will try to compile it into UB I2M. He will want to charge the nominal fee for his work since it is more than just recompiling. I promise to provide the details in about a week.

Yes, please add in more options. After using I2M for a long time. It is only fair we start paying to encourage a fore-coming Pro version. Thank you for the positive answer. You are a good man

Hi Oblicard, so now you see the commitment of EITG toward the user base. and i am not given any names, everyone in EITG should be aware of these type of situation. These is how an application grows by given support to third party developers for example.

I am very tire of reading nothing but negative news everytime i visit EI site. I hope for the best.

Paralumino - 30 April 2009 12:54 PM

When you’re dealing with a small company like EITG, its difficult to get things updated at a reasonable pace. Money, personnel, and priorities are all taken into consideration on what to do and not to do. .

I think the fact that EITG is a small company is the best reason to have good developer kit. To me EITG’s main application is Camera not EIAS. At this point, I wouldn’t mind if EITG just made improvements to Camera. They could leave EIAS alone as it is and have it be like an empty container for 3rd party developers. Basically EITG could be Camera and the SDK (and Tesla). I could even see developers creating complete stand alone apps the would use Camera to render.

Of course, we all know how hard everyone is working. I own a very small company myself (it’s just me) and know how hard it is to try to do everything with limited resources. But, that’s really the whole point. I don’t think EITG should be adding a lot of features to EIAS, the 3rd party developers should do that. EITG could just focus on making it easier for developers to make better and better plugins.

It seems that most of the additional features of version 8 are really improvements to Camera which for me is great! And this whole debate over what new things EIAS should focus on would be better served by 3rd party developers. I have always been frustrated by how clunky the whole plugin control group thing works from within EI. Like I said before I know very little about programming but from an end user point of view, I wish EIAS could be more open to allow plugins to be more integrated into the existing features.

For example, I use the existing deformations a lot, but the available deformations are limited. I also like NL’s Contortionist to use a path the determine the deformation. Instead of adding a Contortionist object then linking all the control objects the plugin object and having to deal with all of the parent child relationships. I want Contortionist to show up in the list of available deformations with bend, scale, stretch, etc. No plugin object, no parent linking. Or, a developer could come with an entirely new and creative deformation system that could be integrated as seamlessly as the existing one. I also think that a great plugin like Dante is limited because of the Control Group interface. I want to be able to create or import an object then click a button that says “Make Dante Emission Surface” that would access the Dante interface and doesn’t have to be linked to any parent. I have no idea if this possible but it sure would be nice.

I also want to stress that I’m not complaining, I use EIAS everyday and can’t wait for next version and for Tesla. I just want EITG to focus on what they do best, Camera. I did not realize that the SDK was so difficult to deal with. If the SDK worked really well, anytime someone asked for some obscure feature that 90% of the users would never use, EITG could relay the request to the plugin developers to explore whether a market exists. And EITG could stay focused on Camera. (And Tesla...)

brian

You scared me there Alexey, I thought our chances to see I2M was gone again… It is very nice of you to try and fix this situation. Thank you. In french we say “Tout travail mérite salaire” - “All work is worth a salary” and I think it is only fair to pay for the plug-in so it is kept alive…

That was a nice post BWCC, i wish EITG listen to the user base, but how many times ANIMATOR and CAMERA conflict with each other , you get something in ANIMATOR and in CAMERA the same deformation or plug in is doing something different. Is a minor thing but it is just an example that ANIMATOR and CAMERA dont work as a team is more of a couple with divorce papers to be signed.
I understand if Oblicard didnt port the plug in to UB, i know EITG is a small company so what does that mean they are not being able to find the resources or the manpower to make it happened. We have a small company too so dont mentioned that excuse again Paralumino.

I’m not offering that up as an excuse Edgard. I’m just proclaiming reality. Whenever you have limited resources you’re forced to choose what gets updated and what falls by the wayside until the next upgrade. There’s only so much money to spend until the coffers are replenished. Whether EITG is a small company or big company that never changes.  The argument for SDK improvements are the same arguments for enhancing any other tool in EI that has taken ages to update. Users get upset when they don’t see improvements made in their area of expertise year after year. They also get mad when bugs take forever to get fixed. Hey I’m guilty. But whether its SDK enhancements, API updates, Mograph tools, or animation/CA tools the debate always remains the same. Why are we seeing yet another Camera centric upgrade?

BWCC’s idea of only focusing upgrades on Camera would be a great one if EITG was positioning Camera to be a licensable (or open source) product for other 3D application. Yet that never happens. That is a policy decision EITG chooses to make and is the foundation of my position as to why constant Camera upgrades are actually hurting EITG as a company. If Camera is to remain the EITG “Crown Jewel”, then the only way to take advantage of all those wonderful rendering enhancements is to have a front end application (Animator or Tesla) that really, really rocks. Otherwise people will look at Camera with great awe and wonder, but pass on purchasing it because they don’t want to animate in an application that is dreadfully out of date or doesn’t possess the animation capabilities to accomplish what they need. Plus many just don’t want to learn another application outside of what’s currently considered industry standard.

BWCC offered an alternate suggestion that could potentially work. Turn Animator (or potentially Tesla) into an open source application for 3rd parties to pour enhancements into. This is actually a compromise between being a totally closed system and a totally open one. Instead of licensing out a version of Camera to other 3D applications, EITG opens up the front end application instead. The problem, however, remains. Where do you spend your money until such a system appears?

If EITG were to alter its policies and move to a more open source architecture my position on many of these debates would shift. But until then, I’m trying to provide ideas for solutions that work with the current situation.

Within a closed system (as we currently are), resources must be focused on the front end of an application in order to woo new users otherwise we’re just throwing money into Camera (the back end or final result) for the benefit of a smaller group of users...and this ultimately will not advance the program as a whole. There must be balance.

And also in a closed system, upgrade management is critical. That is why I suggested making the upgrade process more public so users can truly see what’s going to be worked on next and the roadmap for development is clear.

So to better understand your position Brian can you mentioned in your opinion some of the ideas that you could see happening with the current situation? I will really like to hear them.
Seems like the best solution is keep using the software and keep upgrading until EITG runs out of business.
What type of incentive are third party developers getting form spending time programing or rewriting for a software in decay?

How does the guys from Blender does it? I have always ask my self these question. Man this is a never ending story.

Hi Edgard,

There are advocates for all kinds of different business models out there. Your example of Blender is that of an open source application where the vendor allows the software license to open up its source code to the general public with relaxed copyright restrictions. It does this to encourage development back into the application. As the program evolves and grows larger in its presence in the CG marketplace, the original developer of this application capitalizes on the various subsequent technologies and products that are generated that cater to the application’s growing user base. Critics argue that Open Source lends itself to a certain level of unreliability of standards and can fight with issues of manageability and potential copyright and trademark infringements. Advocates claim it enhances survivability and creative growth of the application by appealing to the entire world for potential new ideas and growth.

Closed applications are more traditional. In a closed application, the company makes its revenue by selling products derived from its proprietary source code. The source code itself is protected by stronger copyright laws and is not made available to the public for modification. Closed applications are generally intended to be very competitive but rely on various avenues found in the marketplace to define their direction on development. Thus if a need is found in the marketplace, a closed application can create proprietary software designed to meet that need and capitalize off the direct sale of its technologies to fulfill those issues. Standard capitalism. Revenue streams are maintained by keeping the competitive edge and by following the trend of supply and demand.

There can be hybridizations of these two models as well...particularly those that implement a LongTail strategy of business and distribution which appeals to creating various smaller submarkets crowds to sell product too. Companies like Amazon and NetFlicks are examples of LongTail companies. They provide mechanisms to find, sell and distribute hard to find items to the public. Thus sustaining revenue is generated selling more of those items that may be less in demand. The greatest example of a 3D company utilizing LongTail strategies would be DAZ and Poser.  DAZ gives away one of its 3D products while Poser does not. However neither are open source. They both capitalize on selling numerous amounts of 3D figures, geometries, textures, animations and so forth instead pushing a main central product. DAZ also provides other applications for sale to supplement their 3D process. Its this halo of secondary products that actually keeps them in business.

So where does this leave EI?

Right now EIAS is a completely closed system. It doesn’t license out any of its applications or technologies to other 3D companies for a profit and it relies completely on direct sales of its main products to sustain a revenue stream. If they had a number one selling product that wouldn’t be much of a problem. Unfortunately that’s not the case. They do however have Camera. A great rendering application, but its tied to a system that remains closed. If EITG does not want to switch Camera over to open source, that’s their business. However by not doing so, it must shoulder the burden to provide new in-roads to Camera that are in line with what the general market wants and I believe the general market wants kick ass animation tools. Rendering, or the end product, is only as good as what goes into it.  What can it do to accomplish this?

Well the first general approach would be to enhance the front end products that tie into Camera. Namely Animator and Tesla. Strong front end applications will make Camera more appealing and users who want Camera will by into it if Animator and Tesla can accomplish their needs. I like BWCC’s idea of turning these front end applications into more open source programs. Its a way for EI to protect its source code for Camera (if that’s what they want to do) and encourages the type of growth an application like Animator would need to stay competitive. Also EI will need to ensure strong I/O features that utilize industry standards.

Tesla will also be a new mechanism to provide in-roads for Camera provided Tesla is unique enough to survive and succeed in a world of multiple modeling applications.

Finally EITG needs to find a way to generate residual income by embracing Longtail strategies. Ancillary markets are crucial to survival in today’s CG marketplace.

A couple of years ago, I would have defended the complete closed strategy model for numerous reasons...but I do see how finding a compromise between open and closed systems is important for EI to survive.

spending time programing or rewriting for a software in decay?

Maybe not in decay, but progressing so slowly that against everything else they look like they’re going backwards.

constant Camera upgrades are actually hurting EITG

Yep. I have actually come to resent Camera. Truly. And that is sad, but EI’s obsession with it, is doing a tremendous disservice to the rest of the package. There’s nothing wrong with Mental Ray, or anybody elses renderer. The work we’re seeing in the cinema and on television attest to the fact that other renderers work just fine. And projects are easier to set up and manage in other packages, thus negating any so called speed enhancements of Camera.

By the way, BWCC’s ideas on having add ons appear directly in the menus, not as hierarchically mandated plugs is a very good one. I LIKE! As I approach teaching myself C++ I found out that Photoshop was perhaps one of the first softwares to offer an architecture that was expandable via filters and plug ins. It helped Photoshop become the top rated product in graphics, and created revenue opportunity for thousands of small developers.

I think Animator has too much legacy to offer plugs that appear within the menus. As I understand it, Animator plugs fall into two general categories - Model Generation and Shaders. So for instance, you can’t write a plug in to change the gnomon manipulator, or write a new rendering camera that is a full 360 degree renderer (or bakes out lighting/textures to uv maps). This is too limiting.

Tesla (or EIM) has the potential of being different. But this kind of foundation will have to be put in now, at the very beginning.

So let’s hope EITG is listening, and creates a product that 3rd party vendors can extend massively. As Blair has pointed out in other posts, we need an API that hooks into EVERYTHING.

As far as extra revenue for EITG (i.e. the longtail business model) they could offer model to fact conversion services, sell libraries of fact models, sell plug ins (which they’ve started doing) training materials, perhaps even offer computer graphics services - although that’s how they got started, all those years ago.

Paralumino - 03 May 2009 09:24 AM

There are advocates for all kinds of different business models out there.

It may be a bit of stretch but I was thinking more in line with 3d Studio. I remember back 10-15 years ago, 3d Studio was one of the first 3d apps ported to Windows NT which really separated it from the others at the time. Back then the application really didn’t have much to offer. I think it was all polygonal modeling, basic animation features and lousy, slow renderer. But, they did have a very good sdk and seemed to really encourage outside developers. It wasn’t Open Source but the plugins and shaders flourished because of the growing user base (due to the NT port) and the straight forward development process.

They were able to add huge improvements like integrated nurbs modeling, SDS, character animation tools, hard and soft dynamics, particles, and many others all through the plugin development. Since then 3ds has become very a different thing and most of the more successful plugins have been built into the base application. There was a time when like 90% of application was plugins. EIAS has more to offer than 3ds did back then mainly because of Camera.

When developers make decisions on what to develop, it’s a balance between how much of a pain in the butt is to deal with and the accessible user base (market potential). Even if there is small user base it might still make sense to a developer to take an existing plugin and make it work in different application, but only if it is quick and easy to do. I think this is what Northern Lights did with Blaster, Psunami and Psyclone, these were originally developed for other apps. Since EIAS’s user base is small, the process to develop plugins has to be very easy. I think plugin developers just want to sell their software, they don’t care what app you use it in.

At this point, if it’s even possible, EITG could have SDK’s tailored to certain developers. Like, if you are company that develops plugins for 3ds, download this particular kit, and follow these steps to convert 3ds plugins to EIAS. I also think that developers would be looking for avenues to sell their software. Apps like 3ds are always folding in plugins to the base application which effectively ends the revenue for the competing plugins. It wouldn’t apply to every plugin though, if you ever get frustrated with EIAS, check this out.

http://bigrender.jimdo.com/

lame…

All these integrated modeling, mograph and character tools that people want already exist. We just need to reduce the pain in the butt factor to encourage more 3rd party development. In a perfect world it would great if EITG could deliver on every request, but they can’t. It’s too much for the available resources. Just think how great it would be go to EITG website and see dozens of 3rd party developers offering hundreds of plugins to create your custom version of EIAS.

brian