If it is chosen not to continue FXTree development, then at least all SDK hooks necessary should be supplied to keep the "3rd-party backdoor" open.
Is it possible to write new nodes for the FXTree from the "outside"? I didn't search in the SDK examples too thoroughly, but it does not look like it.

Same goes for all other aspects of the software!
I'd prefer SI as an "open framework" above a "black box". Take advantage of "the crowd", so to speak. This can only improve SI's chances on the long run.
How long is the discussion about a better operator SDK going on now? We could be much further, if things were as easy here as they should be.

My first wish for the next release would be a serious effort to improve everything that makes Softimage even more customizable, ICE, SDK, PyQt...


Am 08.04.2013 09:06, schrieb [email protected]:
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)
 
It’s not uncommon to be able to do something quickly and intuitively in the FXtree and then having to do the same thing in the final compositing package and struggling to get it done.
So I wouldn’t argue that the FXtree lacks all that much. (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.
 
 
 
Sent: Monday, April 08, 2013 3:40 AM
Subject: Re: This is what I meant by AE integration
 
What does the FX Tree lack compared to AE / Nuke ?


Christopher

Sunday, April 07, 2013 8:02 PM

Personally I do most of my 2D comps in Nuke,
(only mostly because of the rather short bug/feature section of my post)

So the previously discussed (if only) points that have been made about not needing Nuke -if only- there would be a *bit* of efforts made on it, were quite valid.


But for me when I need to have tranparency mapped grids with comps on them (or on other models in space), I use the FXTree.

When I need to PROCEDURALLY TREAT TEXTURES  (all the time) I use the FXTree

Fo quick previews and testing I use the FXTree (import passes)

When I use SI, I use the FX Tree ( as many more than what magazines may portray )

Historically, many people have always (quietly) used the FXTree.




Sunday, April 07, 2013 7:50 PM
Do you use the FXTree Guillaume, actively ?
Some on the list grew with FXTree while others do there work in a compositing program.  Whatever rocks your boat, I suppose. 

Christopher

Sunday, April 07, 2013 7:04 PM
> How many people on this list use FXTree for Active work ?

Just people using XSI and doing rendering related stuff and knowing the FxTree :).




Sunday, April 07, 2013 6:25 PM
Gullaume - There are two meaning to 'dead'
Dead as in it's not actively used and Dead as it's removed from the product.
Dead as in Walking Dead :)

How many people on this list use FXTree for Active work ?

Christopher

Sunday, April 07, 2013 6:18 PM
The FxTree is not dead of course. Every components of XSI can be improved at any time by the Softimage team.
Improved by adding feature to the existing code or improved by creating a new version of the component (like when ICE replaced the old particle system).
 
FxTree will be dead the day it will be removed from the product.
 
Simple as that.
 
Every other statements are just pure speculation.
 
Period :).
 
Guillaume




Reply via email to