Mikael Pettersén wrote:
I've always thought that the UI was acceptable but it's
annoying that it's crashes all the time
Hum, I never had much crashing, but I know that if you give it too much
memory it will become very unstable.
Although it manages even very big comps fine with "normal" memory
limits.
pet...@skynet.be
(14 hours ago)
I see FXtree mostly used as a precomp tool: test your
renders and ensure what you deliver to compositing department actually
works.
Although I’ve used it a lot for final compositing too – at
those studios that didn’t have dedicated compositing seats. (yes they
exist)
Yes! or that have limited number of comp seats.
pet...@skynet.be
(14 hours ago)
... (directly treating the alpha
channel without needing to swap it to RGB and back, as well as
selecting channels to be used for masking would make me happy )
As long as you’re doing compositing of 8bit/16bit passes from
3D without extensive relighting its quite ok.
For me, it falls down flat on its face when you start using
.exrs or want to use normals, motion vectors and what not. And if your
comps are based on plugins then the FXtree is just not applicable.
Right!
relighting stuff, and
effects also taking into
consideration alpha channels also being a biggie, how did I leave
that out.
But what do you mean by inability to use EXRs? It supports floating
point (values beyond 1) pretty well as far as I used it,
but maybe you know something I don't?
And I would add to that, for motion graphics (or otherwise for general
purpose),
Deeper 3D integration, meaning having unrendered 3D elements
(specifying or creating SI layers in 3D?) as sources in comp,
rendered upon viewing and at comp output. Which would be more than
just 'useful'!
And.. (last one I swear :) already with the ablility to process (or
animate) textures being quite something (and unique),
(which for instance, gives the ability of using single image files, and
*procedurally* treat them for various illumination parameters )
.. In the RenderTree itself, having 2D nodes that can be put anywhere
before the "Image" node,
as oppposed to having all procedural image editing references reside in
the global scene FXTree, would be even more quite something :]
(then also retaining texture edits when exporting models)
and would perhaps be a good opportunity at actually merging nodal
trees? ;)
Although a dedicated comp solution would surely still be desireable
even *with* those changes
particularly for comp teams and departments where extensive 3D might be
overkill,
apart that most of the proposed changes would heavily concern the 3D
creation process itself,
.. having the 2d part of SI (finally) updated or more usable
for final comps (more than it was in 2005),
I don't think is unreasonable, especially given the high feasibility of
(at least most of ) what has been proposed.
Toxic comes with SI, yet has no vector paint(for example)
and in no way can it be harnessed from 3D
though it's 2d can harness some 3D... (through Maya interop....
)
For upening-up to plugin standards,
luceric (8 hours ago)
Now in 2013, it's too late to bother putting work on that, xsi
clients are using other compositors already.
My point exactly, why are they using other compositors?
And if I may, why bother putting work on SI altogether?
Many clients are already using other apps ...
(of arguably comparative versatility)
If it were up to a certain few (perhaps impressionable) people,
SI continuity would have ceased shortly after core dev reassignments.
(or seemingly, after core dev (willful?) assimilation) ...
Sorry don't want to make a fuzz.. but I think it's all the
lingering/underlying (and perhaps unwarranted)
SI deathwish seeping through (from original developers?) that I'm not
particularly fond of.
But whatever...
On 08/04/2013 3:39 PM, Mikael Pettersén wrote:
I've always thought that the UI was acceptable but
it's annoying that it's crashes all the time.
I've always
thought that the UI was acceptable but it's annoying that it's crashes
all the time.
On Mon, Apr 8, 2013 at
10:31 AM, Paul Griswold
We could have done that;
the last time we looked at the OFX API (I was
involved in its early
definition) OFX plug-ins were very expensive, so
nobody would have
bought one for the fxtree. OFX vs AE APIs allows
plug-ins vendors
to set different prices for Studio vs prosumer. Now
in 2013, it's
too late to bother putting work on that, xsi clients are
using other
compositors already.
Note that Composite/Toxik... again... you
know what's coming... wait
for it... . . . supports OFX plug-in.
It does everything except have
a modern UI, that thing.
Wouldn't the solution be to update the FXTree so
it can use OFX plugins?
That opens a lot of doors.
-Paul
It's not a
good question to ask. It's like asking, what's the
difference between
OneNote and EMACS. People use EMACS for a thousand
different
reasons than taking notes, and so do people using AE or
Nuke.
The
low hanging fruits that are missing in the fxtree, for its main
intended
purpose which it could hopes to fulfill are nodes for the
most
common post processing for CG renderers, which includes 2D motion
blur
and lens effects, and a quick text node. All of which is actually
in
Composite, but we didn't have any the FX R&D at Avid (bafflingly, I
still
don't know what the DS fx team worked on). Then again, someone
is
always going to need some specific AE plug-in like "frischluft
lenscare"
for AE, and dismiss the FxTree for that.
