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.
On Mon, Apr 8, 2013 at 4:48 PM, Luc-Eric Rousseau <luceri...@gmail.com
<mailto:luceri...@gmail.com>> wrote:
On Mon, Apr 8, 2013 at 10:31 AM, Paul Griswold
<pgrisw...@fusiondigitalproductions.com
<mailto:pgrisw...@fusiondigitalproductions.com>> wrote:
> Wouldn't the solution be to update the FXTree so it can use OFX
plugins?
>
> That opens a lot of doors
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.
