I would like to nominate Blender in that list for animation/rigging.
While I personally dislike its UI and conventions that go with it, I
feel it shouldn't be discounted as a serious contender...it has every
feature that an animator requires to make great poses. But if only they
would make (yet another) UI overhaul I would be very happy to work with
it...
Yours sincerely,
Siew Yi Liang
On 3/4/2014 10:49 AM, Andy Jones wrote:
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 <http://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]
<mailto:[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
