Since the rumor/news broke (and to a certain extent, before that as well), I've been putting some serious thought into plans for the future, and I want to share a few thoughts, as I think this storm will be best weathered together. Every studio is different, of course, so what works for me right now may not work for everyone. To be clear, these are my own speculations at this time, and NOT any kind of formal plan for my employer. The community discussion will have a big impact on our own internal discussions, though, so I think it is important to be part of the dialog.
As we all plow forward, the hope is that we will leave a trail that makes it easier for anyone who eventually finds themselves on the same pathway. -- SCENE ASSEMBLY For us, the biggest hole left by Softimage's demise will be lighting and scene assembly. This, and FX, are the main areas where we currently utilize Softimage, particularly in our NY office, but in LA as well. I'm going to run through some of the options I've looked at, leading up to what I think will be a good solution at the bottom. Process of elimination style. - KATANA I've spent some (non-hands-on) time looking at Katana, and while it is a solid, powerful, scaleable solution to scene assembly, I feel it is actually too open-ended at the surface to address our needs. I'm also not satisfied with how it presents shader networks to the end user. I appreciate the flexibility of a nodal system at the core of an application, but what I actually want is a simplified UI that exposes all of that procedural power in a direct and consistent way. I could see where Katana would work well for larger scale projects, but I have major concerns about how it would fare in small 1-10 man operations for commercials. A key requirement for me in a scene aggregator is also the ability to have an ICE-like procedural layer passing data directly to the renderer without caching to disk. Caching is great for things with a certain data to computational complexity ratio, but in so many cases, you're better off either with a procedural callback, or data in memory. Simple grass systems, feathers, hair, fur, rocks, leaves, fuzz, etc. Largely with the help of ICE, we have graduated to an era where surfaces that need it can have more than just high res textures and displacement. The issues above are likely fixable in Katana, but getting a procedural FX framework is far less likely to happen in the timeframe we'd need. For us, Katana being Linux only, also happens to be an issue (though one we could work around with enough motivation). - MAYA With my last two jobs having been mostly in Maya studios, I don't consider Maya an option for scene assembly. The big beefs I have here are essentially the same as what I mentioned with Katana, plus the frequency of instability, and the lack of compartmentalization in the data model. Not being able to group sets and namespaces being nothing more than a naming convention are also big issues. Obviously, people, including ourselves do some great work lighting in Maya, but I work with some of the smartest and most talented Maya people I know, and it is a simple fact that their days are longer and harder than they should be because of Maya, and that situation hasn't changed at all in the last 5 years, aside from the work that's been done by Chaos Group and Solid Angle and the MtoA community. One would think that Maya would actually be a pretty good choice, which I suppose is how we've ended up in this predicament we're in now, and people thinking they've chosen a winning horse with Maya. But the fact is, there has been little done to improve the situation for far too long, and some of the problems seem to be far too deeply rooted in the software to get fixed. It's not entirely negligence on AD's part, as there are a lot of big studios relying on certain things in Maya NOT changing. - HOUDINI I'm not actually finished assessing Houdini's potential for scene assembly and lighting, but I'm already aware of a couple of big issues there. First, Houdini's pricing model is not structured to be conducive to in-process rendering. This means that any run-time procedurals need to be specially built for each renderer. For example, if you wanted to avoid writing a grass system to disk, you would need to use something special purpose to generate the grass at render time (in the best case scenario leveraging an existing hair procedural) or simply write every blade of grass out to an ifd/ass. With the work SideFX is doing on Houdini engine, maybe there's some hope to get a swiss army knife Houdini procedural into the renderers, but it doesn't seem like that's the usage case they have in mind for Houdini engine. Price is the other big issue with Houdini for scene assembly. I have every intention of making use of Houdini as a core FX package, and the price (while still high) is more tenable in that department. As a studio, we already own a smattering of licenses and make use of them regularly. For lighting however, we would be facing an uphill battle for years to come, trying to get enough seats to keep up with our needs. Especially since doing any procedural "gravy" would likely require the more expensive license flavor. - MODO I honestly haven't looked at Modo enough to say anything here, but off the cuff, it doesn't seem like they're targeting large scale scene assembly as their focus. Render plugins are also a bit an issue. - CLARISSE There are a few interesting tools out there that are worth mentioning -- Clarisse is probably worth a harder look, as they are specifically looking at lighting and scene assembly in a new and interesting way. However, not being able to use a 3rd party renderer means they would have to meet a whole other category of demands. The choice would be between Clarisse and Arnold, which is a whole different can of worms, and the fact that it forces that discussion with no options is already a problem in this case. - CLARA.IO, LAGOA Clara.io and Lagoa are both interesting technology, but like switching renderers, switching to a cloud-based rendering model opens a very large can of worms. It may be the direction things are heading down the road, but in the medium term, cloud rendering with Zync/Amazon seems more feasible. - MAX There are a variety of reasons to rule out Max, but since it's on everyone's mind, a lack of trust of any promises made by Autodesk about keeping a product alive comes to mind. - XSI Still the best tool for scene assembly at the moment, in my opinion. It's important to remember that the software isn't going to stop functioning right away. This means that we can make a decision based on 2-3 years of lead-up time, vs making the decision based only on what is available today. - FABRIC ENGINE This takes me to Fabric Engine, which I feel is the right answer going forward. The one negative thing about Fabric Engine is just that it's still really early days. None of the software I would like to use built on Fabric Engine actually exists yet, so there's a development cost that will be required in order to make it happen. However, this can also be a strength, as there's an opportunity to shape the final product in ways that are impossible with some of the more long-established players. Even Softimage had many things that I would have done differently in hindsight. Streamlined offloading, lighter and more portable shaders/shader assignments, per-renderer materials, multiple partition sets, rule-based partition membership, to name a few. The timing for making a new scene assembly tool is also pretty good right now, as USD is on the near horizon, and is aiming to provide a standardized data format for this specific task. I'm also very encouraged by what we saw with the Stage demo earlier. While it is not currently available for testing, the ease with which the Fabric guys put that together speaks to the quality of the framework they're building, and really shows that it should be possible to build a standardized scene assembly tool fairly easily. Last, but certainly not least, any scene assembly tool built on top of Fabric will naturally have native access to all the proceduralism of Fabric Engine. Although with splice, you don't specifically "need" it to be native, it does mean that there's one less SDK getting in the way of getting raw Fabric Engine power. ALSO, the fact that Splice already exists for Maya, Soft, and soon Houdini, means that we can start building our procedural tools now, and benefiting from them before we even finish moving to a Fabric scene assembler. In the meantime, both our Maya-centric LA office and our Soft-centric NY office can continue on their existing lighting pipelines without losing nearly as much development time as we would if we had to re-write all of our tools when we made the change. -- FX As I mentioned above, the obvious choice for any heavy ICE guys seems to be Houdini. FX guys generally know multiple packages and can fend for themselves, though, so I'm not concerned about calling a shot here. I suspect Fabric Engine will become a bigger and bigger player here over time, but it will take a while to get all the robust general-purpose FX toolsets in place to actually supersede something like Houdini. In the short term, I'm more interested in seeing Fabric Engine tackle the overall CG framework stuff like scene assembly, rigging, non-linear pipeline, and robust custom solutions, than trying to become the full-featured FX suite. -- ANIMATION/RIGGING For animation and rigging, we have already been on Maya for quite a while, so there's no change there for the moment. However, I am very intrigued at the possibility of eventually moving to Fabric Engine rigs. For animation, I'm less interested in specifically getting off of Maya, and more interested in allowing a more flexible animation workflow, where animators can actually work with a tool of their choice, rather than being locked into the lowest common denominator due to how ubiquitous Maya is in studios. Once the rigs are portable, moving FCurves or caches should be very doable. -- MODELING/UVs/TEXTURING/LOOKDEV With the exception of look dev, this area has already been fully democratized. The only wish I had here is that we had a better centralized data format for moving meshes and UVs around. Alembic is the obvious choice here, but the existing implementations of Alembic don't really focus on this area enough. Having the ability to move UVs, normals, and other object attributes around the pipeline would be enormously beneficial. Instead, the workflow here is fairly linear, and ends up back in Maya as a sort of clearing-house for all assets. Once we have a scene assembly tool, we would want a per-asset shading view in that same tool that has the ability to combine various objects and attributes into a single asset, and create shading metadata that can live alongside the asset to be used in the scene assembly task when needed. There needs to be a seamless transition between working at the asset level, and working at the asset level in the context of a particular scene/shot. As always, I'm looking for new information as much as I'm looking to share it. So if anyone has corrections to what I've said by all means set me straight. I also welcome a discussion about any packages I've missed that people think are serious contenders. On Tue, Mar 4, 2014 at 10:43 AM, Jonah Friedman <[email protected]> wrote: > I think a united Softimage community could be kingmaker. I nominate Fabric > Engine as King. > > Here's some facts as I see them: Some of us will continue to use Softimage > for the next few years, others of us will unhappily be forced to use Maya. > The realities of production, studios, and freelancers will dictate this. > > Softimage gave us ICE. ICE has made us smart, because ICE is a ladder. ICE > is a magical place where the slightest bit of linear algebra is immediately > useful. If you can add two vectors together you can make useful things in > ICE. And if you learn a little more, it's a little more useful. And in so > doing, ICE has elevated many us from people who use 3D applications to > people who create our own tools in 3D applications. Our community is not > totally unique in this matter, but I think our community is remarkable in > its knowledge of the core math of CG. That combined with our formidable > production experience, self-sufficiency, and early-adopter fearlessness is > unique. It makes us mighty. > > I think Fabric engine is the way out. That's because Fabric Engine is also > a ladder. For the moment, nothing changes. We may continue to use > Softimage, or we may be forced to use Maya, depending on each of our > circumstance, but the important thing is getting behind Fabric and trying > to get as many of our tools as possible into it. There's no giant painful > leap that's needed, we can start small without breaking existing workflows. > As a bonus, if we open up our tools as much as possible, this will go > exponentially faster. Softimage will remain frozen in time and Maya will > continue to crumble under the weight of its terrible design, and all the > while Fabric Engine will be eating. > > Here's how I see this playing out. > > 1. First Fabric Engine replaces what we used to do in ICE. There's a > lot of work to do to make this a reality, but this one seems like a > no-brainer to me. > 2. The next lowest hanging fruit is rigging. Fabric Engine creations > eat the deformers used in rigging, and then become the rigs themselves. > 3. Once the native rigging in these programs is eaten, Fabric Engine > also eats animation as a natural progression. The animators must go where > the rigs are, and will be happiest where the rigs play back the fastest. > 4. Lighting and rendering is a tough one, but it won't take very much > to be better than Maya here. Being competent at scene assembly and having a > pass system that isn't obviously terrible is enough. > 5. We unceremoniously kick the desiccated husk of Maya into a storm > drain. > > Honestly if we do nothing, I think this might happen anyway. But I think > together can make it go much faster. > > 1. Embrace open source and put as many of our tools as we can out > there. > 2. Keep making stuff- this is natural for us, as we have, after all, > all become toolmakers. > > No giant painful leap is needed. We liberate ourselves, and empower > developers who have passion and care about the right things. > > This is the only road I see that leads somewhere that I actually want to > be. > > -Jonah >
