If you’d like to see Deep Compositing in Flame, please +1 this feature request from a decade ago. Nope, I am not kidding.
So here’s a question. If one had USD, could load VDBs and had a render delegate (thinking Arnold) would deep matter?
Which would be more useful?
As an everyday deep user, I would say Deeps. There are common workflows and techniques involving turning 2d elements to deeps.
@cnoellert - $0.02 - At this point USD, and for efficacy, Unreal Engine. (and Arnold for eliminating those pesky edge thingies)
When you say USD, what do you really mean? A fully fledge scene assembly implementation?
Correct. With a revised shader system for a supported delegate and vdb support @milanesa
Arnold seems much more likely though, no? The former seems like a licensing mine-field, but if this new action (reaction) could be render delegate agnostic…
Just feel like all of this exists already in Autodesk. We just need an implementation.
Caveat: at best I have a squirrel in this argument, but not a whole dog.
It seems to me there’s a use case where Flame does enough 3D that you don’t have to leave the ecosystem for type of work Flame is good at (just how it’s nice that you can color grade and do beauty work at the same time). But looking at dev effort, is it realistic for Flame to have feature parity with Nuke and other systems? Seems like the gap is pretty significant, and the majority of Flame users would benefit from modernizing Action with better import support, more modern render engine, and those kinds of things to future proof what it already does well, but not the whole enchilada.
When I think of all the things that Nuke is great at, and what you can do in CG apps, which is much more than 10-15 years ago, keeping parity seems a journey of diminishing returns. Don’t a lot of shops also have Nuke and other licenses, and work on pipeline features, and the baseline 3D stuff would be more realistic?
It’s kind of like Resolve chasing the everything app, the equivalent would be Flame chasing everything 2D and 3D finishing. There’s a reason why few of these exist, because it’s extra-ordinarily hard and expensive. BMD has come close, but only by making compromises in using graveyard finds and a truckload of duct tape. It’s not really a top-tier app in each of its branches.
@cnoellert - once upon a time, in a galaxy far, far away there was stingray.
then it got crushed in the garbage compactor.
Why should there need to be a choice? I would say both, just like Nuke and Fusion.
It’s more of a thought experiment. Finite resources, availability of exiting tech and implementations and ultimately user preference.
I agree in principle that both would be great but which one would be more great to get first, cost less time-wise and resource-wise to develop and deploy and ultimately which would would yield the highest roi on that development?
It’s a clear cut choice for me. And @AdamArcher I’m not for a minute saying it doesn’t make sense in the long run—I get it. I just think a solid multichannel workflow and the above implementation are great first steps.
I actually think that isn’t such a clear choice. If I had to choose I would probably say deep as that toolset is more in line with integrating CG rather than becoming a CG app. If you were getting deep images to work with then you would be receiving renders from an app that can already deal with USD and VDBs. You would just be compositing it into the scene.
Once again though, I’d also like the ability to bring in VDBs so you could bring in FX like Fire, smoke, liquids, etc; from tools such as EmberGen and LiquiGen. Id pick deep first though but once again, why should we need to choose?
I have my thoughts on USD implementation and how most if its features could be irrelevant to Flame’s users. You will probably have the intended benefits by modernizing the current system without having to delve into USD… which is what @allklier is talking about. For the sake of sticking to the A vs B question, you can look at the Fusion ( and global comp) community reaction when BM implemented USD vs the recent Deep / Multilayer addition. I think the later is the reason we have this topic.
That said, the USD framework definitely brings speed and interoperability with other apps even for simple things.
I think if you were to measure the number of Flame artists who are requested to deal with deep, versus the number that could benefit from a reworked action which could handle massive amounts of geometry that it could correctly render and insert its own elements into, or use for holdouts, or use for real shadows, or project on, or get real refraction, or for loading sims from Houdini or from ember gen or from wherever I think the balance severely tips in one direction.
Doesn’t solve the issue of deep renders no. I fully understand that. But it can solve some of the issues non deep compositing has with integration of complex cg scenes while adding a metric fuck ton of useful side-effects.
Regarding choice, everything has a cost, and my guesstimate is that solving potentially a slew of other issues which deep was tangentially created to solve while additionally solving a slew of long standing short comings in action and flame as a whole has a great value for that cost than implementing deep for the handful of users that prioritize it.
That’s all. It’s a discussion not an edict I’m just curious what folks think and how much of a press there is in the user base for deep.
Did I mention the new viewport that would need to accompany the new action to deal with all that geo?
But if you want a better viewport that deals with Geo, etc; then why not just learn Blender, Maya, C4D, Houdini or some other dedicated CG app that was designed for this very thing? You’d get Arnold/Redshift/Whatever to support it immediately at no cost to the Autodesk dev team. Then you could render out with deep data and take the CG renders and composite them in place with greater ease in Flame.
Once again, If love a better 3D viewport and the ability to work with volumetric FX within Flame but I have no desire to play with anything beyond simple geo in Flame.
@andymilkis @randy Poll on the above potentially?
Fair, Im not a Flame user, nor deal with the same type of work Flame artists usually do. Commenting from the perspective of using deeps and dealing and big cg scenes for a while.
Because, much like the discussion around deep, how much would a flame artist benefit from a better viewer in action contra deep. It’s a ratio of 100000:1 easily.
The flame viewport today is abominable even for simple geo. No need to poll that.
Perfectly understood and reasoned.
My approach may not be typical for some shops, and it has downsides (lower license load-factor), but I frequently switch and mix/match between apps to use whatever some app is best at, instead of hoping for the perfect app.
If CG is involved, I’ll get into C4D or 3DsMax long before I fiddle with materials in Flame. There are use cases in Flame where you just need to relight something, where Action and materials are really nice to have, but anything beyond basic seems like a headache.
On a recent job I was running in Flame, but Infill Blur shit the pants, so I rendered that out, used InPaint in Nuke, and brought it back into Flame to wrap up. Way faster than trying to see if I can fix Infill Blur. If I can paint it faster in Si than Flame, I definitely will do that too.
Here’s a recent job I was part of (I did the Nuke work, the Keentools tracking, and some of the CG renders, but the modeling and most of the lighting was done by someone else on the team). We could have spent endless hours replacing logos or changing colors. Or we could just create CG versions of the product and comp them in. All but one of these products are CG rendered replacements. We got there a lot faster and better than a paint job would have gotten us there.
So I’m a big believer in mix & match of apps, than pushing apps to the limit.
I’m all for a modern, USD compatible 3D environment. If it’s comprehensive 3D work send it to relevant department. But we can do so much even with the current action for relighting/integrating 3D so think what we can do with USD. Like @cnoellert said, the gains would be much more than deep implementation, imho. Dev time unfortunately is limited.
On a side note we are probably around 10% of Flame users in this forum, where 10% of forum members are active posters and even 2% of them here discussing this issue. So a poll would be too small a sample. But feel free to add one.