Next-Gen 3D Software Part II: The Day is Darkest Before the Dawn

So we’ve all heard the news.

Autodesk has bought Softimage. There is a mostly useless webcast here.

I have no love of Autodesk, but I am giddy at this news. Why? Because the Autodesk acquisition puts to rest once and for all the fantasies we had of eventually learning XSI and pushing aside Max and/or Maya. We’ve spoken about it forever, how we ‘really going to learn XSI because I can’t keep using this broken piece of software.’ But I don’t think I’m alone in losing hope for an Autodesk-developed Softimage. Nothing I’ve seen coming out of Autodesk makes me excited for the future of its products, I see no innovation, or at least proportionately little innovation for their talent and money and resources. I see a business model of buyout and rape the competition, and it is now complete. If in my last thread about 3D software I tried to be forgiving to Autodesk, I abandon all restraint here. I am absolutely sickened by this move by Autodesk.

I am guessing most people who had dreams of a greener pasture are equally disturbed. But that is what I am excited about- there is no greener pasture right now. Your dreams must cease being dreams. They must vanish or you must work for them to become reality. We are here at a time where the industry is in tremendous change, where the technological power of individuals is increasing at an exponential rate. The power of our pocketbooks has been effectively stripped from us- whereas we could have influenced our studio to switch to XSI to get away from Autodesk, it seems pointless or impossible to go to Lightwave or Cinema4D. If our studio switches software, our money is going to go into the same fat pockets. The only power we have left is our minds. We have the power to make a difference now. We do not need to sit idle and wait for Autodesk to change, or something to appear that we can hope will rescue us. We can start working on the solution right now, right here.

I’m looking for people who are passionate about this, developing a solution. It is not for the timid and it is not an undertaking we take on lightly. We have the opportunity to make a difference to our entire industry, we are here at a unique and powerful moment. It will be a difficult and slow process for sure, but we cannot put it off any longer. We can be the ones that we are looking for.

Fired up and ready to go.

What happened to the Anti-Trust laws??

suddenly blender is looking more and more interesting…

Yeah that would be some funny shit… we all agree as a large mass group of tech artists to just switch to Blender and just run it with a screen shot of MayaMaXsi we can flip up of some one sees.

kidding or am I:)

In all seriousness though, Blender is the perfect platform for such a move. They already have a established development team that is working on improving the software. I think we can all agree that the main downfall is probably lack of “production readyness”, but say if several production tech artist would suddenly join said project and help direct the product towards production it can be a major win.

The other main thing that Blender has going on for it is it’s native python plugin development, so it would fit neatly into most pipelines, even if it’s just from a backend/export time tool. Plus considering the price, I find it hard to believe that any director would oppose adopting it if all the users are comfortable with it.

If they can learn a lesson from Houdini and Mayafy their UI they would be a definite contender.

Just my 2 cents…

I was saddened when I read the news as well. XSI suddenly lost its sheen.

On the topic of Blender’s UI, from my understanding they’re doing a pretty big overhaul with Blender 2.5 and making it a LOT more customizable along with making hotkey and navigation schemes more customizable as well.

i’d be very interested in a tech-artists.org effort such as this. Count me in Rob!

-R

Im surprised no mention of Houdini. When I worked at CORE I saw how amazing houdini’s pipeline can be, and more interestingly, it’s great for video game pipeline integration. it’s innovative, it’s amazingly flexible, and the data is easy to manipulate.

Anyone else taken a look at houdini? talk about power!

I dont think Blender focused enough, I think you would need to strip it back down to make a new tool. Its a massive task to develop a totally new tool to do all these jobs and please everyone at the same time,

Its sad now that Autodesk controls all these packages, but did they ruin Maya when they bought it? Did they stop developing it? maybe this will help XSI - you never know.

Rob: It sounds like you are considering developing a new 3d app… or are you thinking more of supporting something like blender?

I would be curious with so many people in the gaming industry what a 3d app would be like from us… maybe even be built from a game engine (no I’m not suggesting torque)… that would be extremely exciting imo.

I’m also interested in hearing more about it. Are we talking about designing at app that’s open source? Would it be specifically targeted at handling only the tasks that game artists need? What’s the scope of our project?

That is the future Autodesk needs to compete with and fear imo.
Game engines have already taken over tasks that a few years ago we were all doing in their app.

I.e. the unreal material editor or mega texturing in Ids new engine, etc, just to name a few. I’m sure the next generation is going to see completely new innovations that game studios have come up with outside of Autodesk.

Realtime facial animation, physics based animation like natural motion, are a few more examples where game engines are starting to adopt these technologies and Autodesk is struggling big time to keep up.
(We all know they are building some of this in-house at Autodesk now, but it will be delivered a few years after we all needed it, like in true Autodesk fashion)

All those things no longer require Autodesk applications right now.

That is the real competition and hopefully we will see a small revolution here for the next generation of game engines/consoles. Wouldn’t it be great never to have to touch an Autodesk product at all? :slight_smile:

I’ve looked at something like ShaderFX a few times now and I’m still very confused Autodesk has not build something similar in what is years by now.

I know they will probably eventually get the mental-images mental mill stuff in there since they are pretty tied to them with Mental ray, but seriously how long do they make us game artists wait for something like that?!

Ridiculous really and I just can’t imagine that the next generation engine programmers/tech artists are going to sit and wait for a few years for Autodesk to get their act together and support their new innovations.

The thing that might save Autodesk is if a lot of game studio refuse to use one of a few well developed engines (like unreal, id’s engine, torque, etc). Those smaller teams will not have the ability to build all the sophisticated tools that say Epic can build.

Or maybe the larger game companies just don’t want to build more tools around their engines, who knows?

I know that I’m personally not to worried anymore about Autodesk slow progress. Game studios have far more programmers and larger budgets available then Autodesk and we’ll simply take over that role if Autodesk continues its snails pace.

So either we’ll get something awesome from Autodesk in a few years and we’ll finally see some results of our years of paying subscription, or game studios will take over. win-win :slight_smile:

-Kees

I think it would be very difficult for someone to come up with an App that can be used by many companys. As soon as you start making it more useful by intergrating it with your game engine it will probably become quite unique.

Also you have many artist that do offline rendering and animation that are a good supply of talent between games and film. These people are likely going to want to hold on to using packages that will gain them employment if they switch to doing something else.

Blender is probably the closest thing to what you want, it certainly impresses in terms of features, but maybe not in terms of UI.

To start a modeller from scratch would be an undertaking, adding animation would be heroic. To create a whole package that everyone agrees is great would be a mission to mars.

Regarding Blender: I said this in the Blender thread as well- I think it is a great program and I like what they’re all about. But what I’m talking about is fundamentally different than Blender on lots of levels. Blender is more feature rich than any other 3D program- what I’m proposing is something almost ‘feature-free,’ in that its core principle is non-source development by programmers and technical artists. Entirely modular and very lightweight.

Regarding Houdini: I have to investigate it some more. I don’t know enough to say one way or the other.

Regarding what I’m blabbering about: I don’t know if I’m talking about a new 3D program. I will have to look more seriously at Houdini, Blender, maybe some others.

But what I know I’m talking about is that it is time to fundamentally change the paradigm that we develop games and game pipelines with. Since their inception, 3D programs have been trying to outdo each other in what features they can add and what bells and whistles they can sell to people. Well, the industry is fundamentally different now, where this sort of mindset is now extremely counterproductive. Because any AAA and often any AA studio is going to need to do things differently than what the program does out of the box. And the vast majority of their pipeline development time will be spent working around the ‘default’ way of doing things, and then fixing the bugs that arise.

Kees is right- Game studios now have budgets and talent and programmers and technical guys that can do what needs to be done, if they have the tools. But autodesk doesn’t give them the tools, Autodesk gives new features to marketing that they can then convince artists and consumers they always needed.

Programming has become object oriented. I can download a Vector3 class for C# and use it out of the box with what I’m writing. I can download PIL and use it in my Python scripts, and not have to worry when they update and I know PIL isn’t what is causing my bugs. But the environment we work in, as technical artists, isn’t fundamentally object oriented. Sure, we can use a language inside of Max or XSI that is semi-object oriented, but the programs themselves are not.

It is about encapsulating data, and there is no reason 3D software can’t be like this. It isn’t like this for very valid reasons- namely, the softwares were designed at a different time for different uses, as discussed in another thread.

As a program like Crosswalk shows, there’s no reason there can’t be a seamless integration between 3D programs and, yes, your game engine.

mikiex: I think you’ve really misunderstood what I’ve been saying. “To create a whole package that everyone agrees is great…” That is impossible. The key is allowing everyone to use what they want to use, then have a way to tie it all together. It would be a pipeline hub program- all content would filter through it at some point, and be hooked up to it. If someone wanted to write a modeling package in it, they surely could, but creating a great modeler… there are numerous ones already.

Creating an animation and rigging component would be necessary but not fundamentally difficult. In fact, none of this would be fundamentally difficult. Because the ‘features’ needed have been around for years already. On one hand, the program I’m thinking about is behind the times- but its design allows anyone to write cutting-edge features for it and it doesn’t carry with it all the overhead and baggage of existing programs.

Does any existing program have this philosophy? Probably not, as it is not a philosophy marketing and corporate would like to hear (“Why add the ability to expose everything needed to do any kind of custom shadow, when we can just add in a way to do canned shadows?”). Which is exactly why this endeavor would be new and refreshing and is the advantage a small team can have in this.

Hmm interesting… So for game development I imagine this would be a “last step” program… you do everything that pretty much finalizes the model for game integration… animation, shader assignment, physics, and export… though from the sound of it, it wouldn’t be so much exporting to the game as much as just saving it and it’s already in the game.

I suppose it might also allow for some pretty good external referencing… being able to adapt to major changes in the files it’s referencing…

Aha! You are talking about the end of feature packed bloatware. I rarely use mental ray or dynamics in my day job of building and rigging characters. I don’t need all the advanced lighting features - except when I need to do beauty renders, and then I enable that feature from a feature list menu.

A modular 3d package, with all the modules being run in a sandbox that won’t kill the core app?

You get a data manager that loads and saves and then you add the 3d modelling module, and a UV module, and an animation module, and a lighting module, and a rendering module, and a dynamics module?

All these modules would be written in the core API so that we can script then to do whatever we want to make them talk to each other.

Some people wanting the rigging module would be happy with simple bones that store animation using XML, but then you get an FBX module? That’s not powerful enough for some people so they use the Puppetshop module that builds entirely on the simple bone system?

Well yes and no. Interoperability is important, and if someone did want to use it that way they could. But I would more expect it to be used for the more technical tasks (say, for setting up cloth), mass/batch tasks (such as exporting), and preparation tasks (such as skinning, material assignment, etc.). The potential should be there for anything- actually, this would probably be a result of the design whether we want it or not- but what it would be used for would be up to the studio.

Rick: Sort of. But yeah, the key word is ‘a’ module, not ‘the’ module. Modules need a pre-defined way of talking to each other. One of the core modules, like animation or meshes, have their data, their ‘hooks’, and you can do with them what you will. Any studio can write their own curve editor, for example, if they find something is lacking. A good studio may compartmentalize their curve editor even more, but that is up to them. Basically we would write a core, and developers can interact with it however they need.

Sort of related to all this- in the first thread there was the issue of C# vs. a scripting language, like Python. Assuming the program is written properly, there should be no limitation for what you want to use. Exposure of a module is like exposure of a class- just like all .NET languages can work together, why can’t parts of a 3D program. If my animation core is written in C#, my curve editor can be written in Python. I just need to be able to access the data from the core. And likewise, if I want to do something with my curve editor in C# or whatever else, as long as those hooks are exposed, why shouldn’t I be able to? We see this sort of abstraction in other programs at a lower level- think about Max’s controllers, for example, they ‘do their thing’ and are called to update at certain times. As long as the program can understand the language, the program shouldn’t care whether the script controller is written with MXS or lolcode. And likewise, it shouldn’t matter what the script controller is written IN- people should be able to write their own controllers how they want.

I just thought, I dont know exactly how you guys have your pipelines at the moment.
How much work is done in Max/Maya in terms of setting up for game.
I mean you might go
Max - Game Engine, or
Max - Internal program - Game Engine.
etc.

http://river-valley.tv/conferences/blender_conference_2008/ some interesting new things coming up for blender including new UI improvements and other fun things. check out the videos.

@Rob: This sounds really awesome… seems like the most effective way to go about allowing artists to use what they want…
I personally would like to see some form of animation editing in this… as it seems like the thing that usually ties me down to an app… once animation is on a character, it’s pretty unlikely I’m going to be able to move between programs and still be able to tweak the animations.
I have some ideas for flexible animation editing… that should allow for editing imported animation with baked keys… and provide a better way to fix up motion capture data. I’ve been wanting to make a mock up of this… and this talk might have given me a good enough reason to.

@mikiex: Currently we go from 3d App directly to engine. I doubt that this could work for much longer though (well really it hasn’t been working even now)… so something like rob is talking about is exactly what we need over here imo.

@bclark: ah wow yeah. looks like they are going in a good direction. What they were saying about how Modo’s buttons are colored is a very good point.