published on in .

Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Softimage did shine in more than one’s heart until it met its fate with Autodesk. Our dear software is now dead but not our experience nor our vision. Up to us to make the future brighter.

Softimage the Great

When I started to learn 3D on my own as a teenager, I used to play around with Maya 2.5. It looked complicated and unintuitive, which paradoxically excited me. Everyone within the online community that I was frequenting found it hard to use. I liked the challenge. And the splashscreen too.

I kept reading good reviews about the recently released Softimage|XSI and decided to try it out one day. I gave up 30 minutes after opening it. I didn’t like the default shortcuts, I didn’t like the UI. I didn’t give it a chance.

It’s only when I got in touch with Action Synthèse in 2005 (read the full story: How I Got to Work in the Visual Effects Industry) that I got back into it. I had no other choice if I wanted to land an internship anyways. For that reason I took the time to setup my own shortcuts, to get used to the UI, and to get some sensations going.

It didn’t take long, it was a blast. I realized how stupid I was to give up so easily before.

My goal was to learn rigging and it was the best tool for that. There was nothing preventing me from applying my ideas—Softimage had a fast learning curve, it was intuitive, and made perfect sense. Thanks to that in no time I felt comfortable to get some rigs going.

I never wrote any line of code before then but I thought it would be a good idea to also learn how to develop. That’s how I started to use the Softimage SDK. I struggled quite a bit at understanding how to write my code in the first place but the API itself was no problem. Here again, everything made sense, even for a total beginner, and I quickly got my first scatter tool going.

Some softwares are simple to use but don’t get you very far. It wasn’t the case with Softimage. Thanks to its well-thought architecture, it never got on the way when complex work was required.

On top of the quality of the software itself, both the developers and the community were forming a great symbiosis. That was a bunch of active, friendly, helpful, and innovative souls. Softimage was driven by its users. Everyone was involved.

With the implementation of the nodal graph ICE in July 2008, things quickly became out of control. More power at the reach of every artist. Everyone had a blast using it, countless of inspiring demonstrations of the tool kept emerging on the internet. It also quickly became indispensable.

screenshot by Benjamin Paschke
screenshot by Benjamin Paschke

The Struggles

Eventually Autodesk felt the threat coming and perceived Softimage as a strong competitor to Maya and 3DSMax. Four months after the public release of ICE, Autodesk bought Softimage from Avid. A that point, they owned the 3 major all-rounded 3D softwares on the market. No more competition on this front.

As soon as the deal got rumored, things started to change. The community grew concerned and unsecure about the future of its software. The Softimage public mailing-list became the place of numerous heated debates on the subject.

But the community was stronger. It regained optimism when seeing the work accomplished by its users. Two of them mainly ended up doing the show and managed to open the eyes of those living on the planet Maya. They both developed plugins for ICE: Eric Mootz with his Mootzoid nodes and Thiago Costa with Lagoa Multiphysics.

test of emTopolizer2 by Tim Borgmann
test of emTopolizer2 by Tim Borgmann

We were proud to be Softimage users even though we started to feel more and more abandoned by Autodesk after each new release. Softimage was marketed as a plug-in for Maya, had less features implemented, the developers eventually moved to the Maya team, and always more debates were being fired up on the list.

Meanwhile I was dealing with my own struggle in parallel.

I landed a job at Weta Digital and had to learn Maya. I tried hard to approach this transition from an open-minded pespective and there was no big issue in transferring my rigging skill set. The concepts in rigging are pretty much the same everywhere. What dumbstrucked me was the process to get to that same result.

I felt like I was back to stone age. I found many of Maya’s daily tasks and the design of its API to be retarded. I spent my first weeks (months?) asking my teammates how they could possibly work with a such software. Even now, I still refuse to do in Maya a task as simple as painting some skin weights. It drives me crazy.

My colleagues wouldn’t understand my frustration. All they knew was Maya, they couldn’t compare it to anything else. I was being just annoying to them. I sometimes wished to be ignorant too—it would have helped with my zen.

But at the end of the day, let’s face it. As good as Softimage could be, it was a battle lost in advance. They’ve been trapped.

The Proprietary Do-It-All Trap

One size doesn’t fit all. All-rounded 3D softwares cannot please the specific requirements of each studio and each user, and that’s fair enough.

Keeping a such package up-to-date is not guaranteed neither. Developers cannot afford to focus actively and simultaneously on each area covered by this kind of software. The large codebase, the deep dependencies between each internal module, and the unique core architecture and data structures trying to accomodate each discipline are all not helping much here.

Specialized softwares are more likely to remain competitive by implementing the latest technologies in their field and even define new standards themselves. But then those all-rounded 3D packages allows for a smooth pipeline out of the box. For a company just starting its business and not having much resources yet to invest in RnD to connect the dots of a more flexible pipeline, this has always been an attractive feature.

I believe this was especially a game changer back in the 90’s when anything must have been a struggle. If a unified pipeline with a single software could make the life of its users a bit simpler, then what could be wrong with that?

That’s how most studios ended up buying a single package and decided to fill the holes by developing in-house tools. This task was furthermore eased with the developers not having to worry about implementing math, geometric and other complex libraries. It was already all there, available directly within the APIs built-in into the softwares. Developers could focus on getting their tools to work within their tight deadlines.

But that’s also where the bottleneck lies. Using those APIs meant that all the code being written would be gravitating around a proprietary software, creating deep dependencies with it.

Once a studio has invested years in developing tools, workflows, and a pipeline for a specific package, it becomes difficult to change ship. They’re stuck with it, for the best and for the worst.

In this context, there’s no point for a studio to move from one package to another, especially if it is to end up in the same situation a few years later. Since Maya has always been on top of the film industry market, there was no hope for Softimage to gain much more seats from the large studios.

Hence the decision of Autodesk to discontinue it.

That’s life but I can’t help thinking that they’ve planned it all since the begin because it kinda make sense from a business point of view: buy Softimage to get rid of the competition, move its features to Maya who’s leading the market, and kiss goodbye to everyone relying on it for their living because Autodesk can’t afford maintaining its development.

Nice hypocrital move after repeating years after years that they wouldn’t kill it.

The Modularization Has Already Started

Some studios grew tired of having their invested development being so closely tied to the unknown future of a software that they didn’t own.

They started to cut their bounds and to regain some control by creating their own file formats or using standardized ones. The main idea being to store their data in a generic way to make it easily transferable onto any software. The native software’s file formats were only to be used by the artists to save their work in progress before publishing.

With this in place, it was then possible to split the pipeline into logical chunks. Each department could work on the software(s) of their choice as long as they could output the data in the expected format. I’ve even seen 3 different softwares being used in the FX department on a same show. The right tool for the right job.

The way to write tools itself has also changed to be done in a more modular and portable fashion. If you’ve spent years to develop a full-on muscle system but made it highly dependant on Maya’s API, then you’ve exposed yourself to rewrite pretty much the whole thing if you decided one day to port it onto another software. Instead, the goal here is to split the core with its gateway connecting it to the target software. Got a new software? You’ve only got to write a new gateway to plug the core in.

To take full control over the destiny of a tool, some of the largest studios went for the next level. They developped stand-alone fully-featured applications. It is a tremendous work in terms of development and maintenance but in a world of closed-source softwares this is after all the only viable solution to ensure a long-term vision with an active development focused on the specific requirements of a studio.

That was it. Some pioneers did their first steps towards independance.

TDs Can Now Shape the Future

Ideally each studio should have adopted a such modular approach to tools development. The trend being to implement deformers, simulation nodes, rigs and other involved developments into an in-house stand-alone nodal graph platform to then glue its content with different softwares.

Of course, not everyone could push for that. Not until now.

That’s where new solutions such as Fabric Engine comes in.

Fabric Engine shines at abstracting the complexity of writing portable code. It allows any developer, including TDs, to write their tools in a stand-alone nodal graph and to painlessly make them usable in every software. Code it once, use it everywhere. All this with maximum performances out of the box.

Now, imagine the talented community of TDs and developers joining their forces to build a library of tools and making them accessible to everyone on an App Store-like platform.

Tools such as Gator, Lagoa Multiphysics, emPolygonizer, Unfold 3D, and more, would be available to everyone on every package. And ICE? Well, that’s already part of Fabric Engine 2.0.

If that library of tools managed to encompass the needs in each area of CG, then the one requirement left to buy a software would be to have a hosting environment for Fabric Engine. It would become used simply as a shell where the main selling argument would be a good UI/UX to perform efficiently daily tasks.

With Fabric Engine also providing a set of extendable modules to assist building applications, including a powerful real-time renderer and a set of extandable Python UI widgets such as an OpenGL viewport, an animation timeline, and so on, another choice would be for the users to assemble themselves their own hosting application.

How much more powerful and dynamic would our toolset become if it was directly driven by its community, if we were all contributing to shape the future of CG softwares?

If the entire userbase started to break its dependencies with today’s softwares, Autodesk would lose the control of the market and it would be our turn to kiss them goodbye.

The only issue with Fabric being that... well, it’s yet another closed-source proprietary software, with a proprietary language making the code even less portable. But they try to minimize this and to not turn it into yet another black box.

I’d say it’s the way to go anyways. Theorically it opens the doors to a longer-term vision and its team is made of a good bunch of passionate souls. It’s worth giving it a go, let’s just hope that Autodesk won’t buy them out.


Have a look at the comments. Paul Doyle from Fabric Engine kindly clarified a point about the closed-sourceness of their platform.

Comments (19)

  1. #1

    I wrote to Christopher separately, but I believe he might be travelling. Here's what I wrote (with a bit extra on the language comment):

    "I’m working on a few ideas that should help with the last few paragraphs of your post. One comment would be that the _only_ closed source part of Fabric is the execution engine, which is generally uninteresting. It doesn’t help with the proprietary bit, but that’s a tougher nut to crack and still be a business. On that note, we have made deals with studios to give them rights to source code, so there is some security there.

    With regard to the proprietary language - that's necessary for us to hit the accessibility ('dynamic like python') and performance ('as fast as C++') targets for the platform. Plus the GPU compute stuff we're showing at GTC later this month will show why it has paid off. Anyway, I digress.

    I would be fine if people want to contact me to talk about how things can be structured to deal with the understandable concerns that the industry has about vendors and software. We are open to being innovative about this, so please do contact me. My email is

  2. #2

    As a very early user of Softimage (I started in 1994!), I am very saddened by this news. However, there is hope on the horizon. For the last 10 years, until their demise, I was a rigging sup and Rhythm and Hues Studios. Since their bankruptcy, the new owners are going to be taking R&Hs in house software and making it availbe to the public. IT is brilliant software that FAR out paces the capabilities of Maya or Max.

    • by Brad Hiebert
  3. #3

    Hi Christoper. I may be one of the people that can't understand why you're frustrated with Maya. :) I've worked 2 years with Softimage XSI before learning Maya, and in my experience it was the opposite.

    In Maya I saw myself free from some basic limitations that Softimage had, like the bones with automatic IK creation, and non-linear deformers that don't have handles/transforms, just attributes. Not to mention that in Maya you can literally change -anything- in the UI, whilst in Softimage I had the impression that it is somewhat limited (didn't went to far in this matter).

    In a very constructive manner, care to share some points? Maybe I am trapped in a inefficient workflow and never knew. :(


  4. #4

    Hi Richard!

    You're right, everything is not perfect in Softimage neither and I've got to agree that I had a preference towards Maya for some aspect of rigging. But only a few.

    In my opinion, I see 3 main advantages to rig in Softimage over Maya:

    - Maya is missing a modern toolset with a modern UI. It has similar tools than Softimage but are often not as powerful or as efficient to use.

    In the article I've been complaining about the skinning of weights. I had difficulties with the one in Maya to achieve clean, precise results. It was also extremely buggy. The one in Softimage just flows, it works like you expect it to. The locks, the removing of influence of one or multiple joints theb reassigned back to the other joints to preserve weight normalization, the awesome smooth, the friendly spreadsheet, and I probably forget some. It's simple, I could get exactly what I wanted in no time in Softimage, when I would have to spend way longer in Maya to achieve a result nearly not as good. I definitely was lacking experience with the skinning process in Maya, which didn't help me in learning the workarounds, but to be honest I just couldn't be arsed. The difference between both toolsets was obvious. That's why I ended up creating a small workflow to do all my skinning work in Softimage and reimport it back in Maya. Same as soon as I had to create corrective shapes on top of a skinned geometry.

    Maya is also missing life-saver tools such as GATOR to transfer attibutes—the one in Maya doesn't compare—and ICE for... well, everything. With ICE, any artist can set up within minutes a node graph to create a simple deformer without a line of code, when with a traditional coding approach you would just have prepared your project files in that lapse of time, not even talking about writing the actual code, compiling it, loading it in the software, only to realize that it doesn't work and that you need to do this all over again each time. In ICE you can even visually see what's going wrong. Turn on the display for this Vector3 and you'll understand why this deformation not going in the right direction. It's a crazily fast iterative process.

    Then you're right with Softimage's joints coming up by default with an IK effector. It's annoying even though it never has been an issue because in Softimage joints are only to be used to create IK chains anyways. If you want an FK chain, then you create a hierarchy with normal controllers. You can give them a joint appearence if you really want to. Also don't forget that any object in Softimage can be used as a deformer for a weight map. Not like Maya who can only use joints for its skinCluster. So really, no problem here, especially when we compare it to Maya and its black-boxed nodes. For example, I wanted to develop a nice spine for my creatures at Weta, and I naturally tried out the splineIK solver provided. Of course it didn't work the way I wished, so I wanted to tune it. And of course it was impossible, so I had to create my own from scratch. With ICE in Softimage, every TD can come up with its own IK solvers—which many did—and you can probably find some on the internet. If something doesn't work the way you want, you open the graph and change it, that's all.

    Once ICE showed up, it was such a step forward that I started to wonder how we could even get the job done before.

    - out of the box, Maya is lacking a nice, modular, coherent and finished set of nodes.

    As with the splineIK solver previously mentioned, many complex nodes are being provided as black boxes. Either you're happy with them or you're good to develop your own. The best example would actually be the FX fluid solvers and such: “here's your one node that defines the entire solver, and here are the 999 attributes. Good luck.”

    Then you end up with a set of nodes who don't make any sense. You want to do a simple arithmetic operation? That's simple. For an addition, you've got the choice between `addDoubleLinear` and `plusMinusAverage`, for a multiplication you've got `multDoubleLinear` and `multiplyDivide`, for a division I guess you're stuck with the x, y, z channels of `multiplyDivide` even if you just want to divide a single value, and same for the subtraction with `plusMinusAverage`. Seriously, there's no way to make things simpler and more consistent? A node for each operation that could take a variable number of inputs for example?

    Unfortunately I haven't used Maya in 1 year and don't have any access to it, but if you would have asked me this question before, trust me the list would have been long. Between the poorly designed nodes and the elementary features missing, I pulled my hair more than once.

    Of course, this can be fixed with some development, but do you really want to waste time developing such basic things when you have to get some rigs out quickly? And that's where the contrast lies with Softimage: it has mostly everything you need available out of the box.

    - it's a nightmare to develop for Maya.

    Maya's architecture is object-centric and you'd expect to have its programming interfaces exposed in a such way. So why the heck did they release a command layer built in MEL—its port to Python is not any better—that is a language derived from UNIX command shells? Dealing with object names instead of their actual object representation is the poorest and less-robust approach possible. It actually makes more sense when you understand that MEL is not really made for coding. It is made to describe Maya ASCII scenes. How about the huge list of functions available contributing in making you never sure where to start looking for the one thing you need. Maybe what you need is to be found somethere in the 99 flags available in that function? Should you use `attibuteInfo` or `attributeQuery`? Aaaarggh.

    That's why you ideally want to use the Maya API. The Maya APi is object-oriented. Cool. But then, should you transform an object through its `MFnTransform` object or its underlying `MTransformationMatrix`? Why did I have to spend weeks to write functions that were missing or not working as I would have hoped, only to make the API slightly more usable? Examples: easily creating a new DAG node and returning its MFn object fully initialized with the MDagPath instead of a MObject that we won't use otherwise in our code, recursively finding a children below a transform node, recursively counting the number of childs, returning only the shapes of a transform node, adding a child with an option to preserve its global transformation, returning the nodes created when importing a file, and so on. That's all I can get from the top of my head now but once again the list would have been longer if I would have wrote it down earlier.

    Not even talking of the port of Maya API to Python. It is a real shame. I'll skip the non-Pythonic aspect of it, and instead I'll just tell how much fun it is to retrieve the scale value of a `MTransformationMatrix`.

    Anyways, I'll stop the bashing here. I'm not into starting a software war because at the end of the day each has its strength and weaknesses anyways. But since you asked, in short I believe that Softimage behaves better our of the box. It is more artist-friendly, doesn't require much development for expected day-to-day features, and its tools and UI allows to work efficiently. Yes its UI and API might not be as flexible as in Maya, but I've never minded it, and it never stopped me from working way faster than I've ever done with Maya.

    Cheers! :)

  5. #5

    Great article. I feel the same way in a lot of ways, and it is very fascinating how web DAWs and cross-platform frameworks will be taking strong root in the next few years (months? days?). In a sense, when some people are looking at this in a negative bottom-line driven context, it makes sense that this type of giant all-encompassing software is going to struggle in a future of small, specialized, agile, easily adaptable tools. The UNIXification of CG tools.

    I learned Python in XSI and when I went to script in Maya, PyMEL helped ease a lot of the OOP pain. I face-palm when people try to advise people to learn MEL first, but I look at the regular Python implementation and don't see the difference. But yeah, we are lucky we can extend Maya so freely, because frankly, we have to. ;)

    Ultimately the point of this blog post is that the role of TD to act as glue between a wild new set of cross-platform systems is going to be vital. That's exciting for us.

  6. #6

    I love the liddle introduction about the Fabric Engine. Sounds very good!!!!! I am also pissed of about the Decision of AD to keep Maya and drop Softimage.


    one year ago I started with Houdini .... and I learned to love it. I believe Houdini loves you too.... ;-) ... it just does what you want....all developments are well done and robust, working very effective. Its a mistake to believe Houdini is a software for particles only....!!!! the procedural approach and the posibility to access data at every! point of the software makes it one of the most (if not the most!) powerful software on the market. Also for Animation and Rigging.... Mantra its render engine, a production render engine also very powerful... other software to feel good with: Zbrush , Silo, Modo, Blender....Mari

    • by gerids
  7. #7

    True about Houdini! I played around with it for more than 1 month when I got sick of Maya and I loved it. I can't say that the learning curve has been the quickest that I've encountered but being quite technical I liked the logic and modularity behind it. Its architecture and core sounds robust and I'm impressed at how reactive, friendly and passionate the developers seems to be.

    I didn't try rigging but overall Houdini didn't seem to be very artist-friendly, which gives me concerns on how efficient it would be to do some production rigs with it. As powerful as a softwre can be, it's a bit useless if it takes 10x more time to do something, and this is where Softimage was/is shining.

    Anyways, the truth is that I'm actually thinking of reconverting myself into a FX artist and I wouldn't mind at all using Houdini as my main tool! :)

  8. #8

    I found strange that you did't mention Blender a single time, specially after
    "How much more powerful and dynamic would our toolset become if it was directly driven by its community"

    It's more and more TD friendly, python and soon nodes (ice) for everythings.
    And best of all, AD will never buy it, ever.

  9. #9

    The goal here was not to encourage switching to any specific 3D package but to promote a new DCC agnostic approach.

    I don't know much about Blender but I guess there's no reasons why it couldn't be an host application for a framework such as Fabric Engine.

  10. #10

    Just signed to say that your post was really good and very eye opener. And if you decide to be a FX artist, that will be cool! We are needing more Houdini masters now that Houdini Indie exists.

    • by MauricioPC
  11. #12

    Here is a video I have made to present advantages of softimage:

    I plan to make one more because there are really a lot of advantages in comparison with Maya...
    Thank you.

    • by Martin
  12. #13

    Similar videos showcasing the advantages of Maya over Softimage could be done but at the end of the day I'm not sure what's the point for you in making more? This certainly won't bring Softimage back to life, get over it!

  13. #14

    Really like your general point about software agnosticism. To be honest I hated Maya at first, but with Maya 2016 I'm quite happy. I'm more of a modeler/texture/compositing centric person but I came from a tech background professionally (UX/Front end) and I'm very interested in eventually getting more into python. I def. agree that a modular software agnostic development is the future.

    It's funny actually, everyone says MODO is the best for modeling, or some say 3Ds Max, but I've tried both and honestly I find the new maya tools best, easy to configure with the new hotkey menu (that they took from soft image I think), and the mud box inspired sculpting tool set.

    I only have a bit of a year of CG experience, so from a modeling perspective how does MODO and Soft Image compare to Maya 2016? I tried modo for a bit but I could not get used to the what I felt were less quick/less powerful selection abilities in modo... this is totally subjective, if I'm wrong please enlighten me!

    I also wish maya had that "select adjacent" feature from XSI, for mechanical detailing, it seems really nice.

    • by Deepak
  14. #15

    I think that the one mistake in 3d community is to think about Maya as a 3d software. It is not.
    It's a programming language to create 3d-softwares. Everything built around the core is disunctional, by starting with the command engine and moving to the infamous api python binding with its ugly problem with pointers...

    Autodesk convinced us that you could easily use Maya as a tool. But You can't.

    It's like comparing programming with bare C against playing with python. I think it's really unfair:)

    If you need a stable, easy to use software, without the need of developers, Maya is the deadly choice.

    But I believe that seeing it as a software instead of what it is in reality (a programming language) creates a strong bias invalidating almost all comments:)

    • by Guido Pollini
  15. #16

    To think of Maya as a programming language, I'd first like to see its core exposed as a solid API on top of which I could plug additional modules (OpenGL viewport, scene description, geometry API, animation tools, solvers, ...) on demand rather than having to deal with a giant, proprietary, black box.

    As of now, Maya is cluttered with (unintuitive) tools made to be directly used by artists, which is what softwares usually provide, not programming languages. Fabric Engine doesn't provide anything for artists, it only lets you build your own tools for them. That's still not the definition of a programming language but it surely gets closer to your idea.

  16. #17

    I've used almost all high-end software over the years.

    My first software for 3d was turbo-silver
    then sculpt/animate 4D, Lightwave/Toaster, Vista Pro and then Imagine...all on the Amiga.

    I got the opportunity to get into 2.62 Softimage in 1994.
    I then went on to work for Mainframe on the show Reboot.
    Then cross trained on Softimage XSI when it was released.

    The modular approach of ICE is genius. It's very powerful and makes things so much simpler.

    Open source for Softimage was taking off with ICE.
    So many kind people uploaded powerful compounds online for free. And not just ICE compounds, but rigs, shader libraries, mo-cap files, full models with full assets...etc. There's more than enough free stuff online to make a feature film.

    For me, open source is the way to go.
    With open source software, there's no corporation, no profit motive, no stock holders to please, no useless (cracked a week after release) licensing software or dongles to make life miserable. Open source is free to everyone and driven by the passion of the community. Just look at how far Linux has come.

    Open source is like an empty book. Anyone can open an empty book, fill it with a story, sell it, and make money.

    Blender is an amazingly powerful stride for open-source. Powerful enough to create a feature film. It's amazing that such a powerful piece of software is totally free. For small studios, money saved on seats can be ploughed into other areas like workstations or whatever.

    To me, the writing's on the wall. Open source is the future.


    • by flek
  17. #18

    Our studio purchased Softimage 5.11 and I was hooked almost immediately. Other 3D software that I had tried was not near as intuitive. Softimage was so natural. Loved the simplistic menus. Was not cluttered in fancy icons and flashy pop-ups--truly Softimage was an artist's playground...and ICE--wow; talk about a powerful node based simulator that can do complex simulations at over 200fps (real-time)!

    Currently, we are using Softimage 2011 while we were attempting to make a switch to about confusing. Am I the only animator that reads? or does everyone need fancy icons and menus? The interface is horrible (and I am being mild), whereas in Softimage the menus are categorized into what you are working on. Going through Maya's learning process is a bit overwhelming because it seems like we have to do twice as much work to arrive at the same destination. And so before we make any decision on whether or not to switch, we are wondering if it would make more sense to simply acquire Softimage 2015 and wait for Maya to catch up. Thoughts?

    • by
  18. #19

    Hi Tim!

    I think the reasoning for deciding whether to switch softwares or not is pretty simple: if you are confident with getting jobs done efficiently and don't have troubles hiring Softimage artists, then maybe there's no reason for changing anything. Especially if you are working in animation.

    Now, you also mentioned simulations. For that area you'll definitely get a lot of value from switching over to Houdini. Many Softimage artists seem to have done the jump without regrets.

Say Something!