Replace Stingray with Unreal Engine wouldn’t hurt.
Yeah, I mean I’m sure there’s a million reasons why this will never happen, but given that Action is basically just a game engine, it would be awesome to see it updated.
Unreal is incredible.
When quoting a site that’s not involved with Visual Effects (VFX) it would be appreciated if the OP would, at the very least, spell out the (likely unknown) acronyms.
For the VFX (Visual Effects) artists here, “AEC” is the acronym for “Architecture, Engineering, and Construction”
He didn’t quote, he linked an article.
I do believe people here are capable of googling if they find themselves under extreme acronym duress and if they don’t have the time they can opt out of that little bit of understanding until later, no?
FWIW, an h264 comp wip is on FIO…also email the ECD and COO the FPO for their PPM in the AM and remind the AD the 40x needs to be smooth AF or the DMP will be a PITA.
You are correct, my apologies.
Looking at the landscape, what Unreal has achieved is remarkable but the future lies on USD (Universal Scene Description) and the ecosystem Pixar has built that is now being integrated everywhere.
Very soon you will be able to bring full CGI scenes in USD format into Flame and render these frames on the fly, on a render farm, at maximum quality and we will remove all the tricks Unreal brings so successfully.
I would encourage AD to bet on USD, bet really big.
Agree that usd is very exciting stuff.
The fact that it is app agnostic is very helpful.
It’d be great to see support in flame, but full-blown support might be far off.
A few thoughts:
- there is no real render engine in flame. Getting a hydra delegate into flame is likely no easier than to get Arnold, etc into flame. Seems like USD would require some way of getting third party renderers into flame toolset. Big ask but worth pursuing.
- what needs to be balanced is that as comp apps become more like 3D apps, they inherit similar probs. Interactivity turns sluggish.
- USD enables very larger sets of cg data. Flame tends to work/render at final quality and this much data might require some kind of limitation so work could get out the door.
- most apps that currently support USD are not very good editors of USD.
Houdini Solaris is by far the best of what I’ve seen. Without Solaris, USD would be an intimidating climb for me.
- maybe limited support would make sense in near term? Loading a USD into something like Action could give AOVs like depth, etc.
as far as editing, I’d think lights and cameras would be great interactive tools in flame without opening up the whole CG can of worms into flame. The trick is to get these adjustments back to USD so it could again be app agnostic.
Agree with the huge potential.
Think it’s definitely worth looking into.
Currently I’m using fbx as a bridge to Houdini and unreal to/from flame.
It’d be a big deal to get into flame and Autodesk would need to allocate significant resources.
Have you seen Nukes 14 beta demonstration of its new USD scene handling. Is really interesting and a nice approach to scene manipulation.
Omniverse is quite promising. Been following it for a while now. Should really find some time to dig in some more…
Very good points, there is a factor of data exchange as in 3D models, camera data, etc… and then rendering a 3D scene, which you can’t do interactively at the moment and with ever growing complexity will never happen.
That said, this does not mean you could open the 3D scene and render it, perhaps with the help of some big graphic cards and get full control of the look AND cg camera.
I think that is where I am coming from, how this is implemented will make all the difference but Foundry are all steam ahead with it, and rightly so.
In terms of making Flame work with USD, I don’t know how hard that may be… surely not easy but it all depends on the ambitions, it would be pointless to be a full authoring tool like Solaris but perhaps start simply rendering it and then move forward as needed?
For me the issue would be speed… big reason for me personally for not using Nuke is that I don’t have the patience for it…
So I wouldn’t really care (also didn’t when there was talk of implementing mental-ray) for it do full ray/path/tracing/marching/ etc… (unless it’s realtime)
I’ve been using some of Flame’s stingray tools in the past to add simple 3d background elements like buildings/ planes/ drones/ windmills… etc which worked quite good even with it’s limitations. But stingray is very limited and replacing it with something more versatile would be awesome…
Good points all around.
Yes there could be helpful workflows without a full blown implementation.
Unlike past requests peeps made for ray tracing, what’s interesting about USD is that it’s an app agnostic geo format like fbx or abc.
But also strongly agree w Ton.
With flame, the name of the game is speed and interactivity.
Some of the tools in nuke can be cool but contribute to me hating working in that app.
Deep Comp is great example.
Deep comp is super helpful if it keeps you from redoing an expensive sim, but if you are choosing that kind of solve to avoid roto, you are filling the pipe with huge frames that’ll make setups slow and unstable.
I think any implementation would need to be well thought out. Unlike the Deep Comp example, I think there’s a lot to consider w USD. It’s like a 3D version of EXR, which has become my preferred working format by far, regardless of its colorSoace.
Even tho I’m unclear how it could be implemented usefully, I do think it’s a worthy discussion.
We have never been big enough to need anything like Katana, but isn’t this kind of what it does? 3d scene assembly mixed with lighting mixed with comp?
Blender’s Eevee is an excellent example of non path tracer, almost real time engine.
Here is a supercool demo of Eevee (pure GPU) vs Cycles (Blender’s internal pathtracer)
The interesting thing is that both engines are almost 100% compatible regarding shaders, so Eeeve can be used for fast iterations, switching to Cycles for final pixels.
Here is a sneak peek at Blender upcoming real time Compositor
About 5 mins in
Just some more ideas.
I think there is going to be some consolidation on this part of the 3D market.
Katana is a front-end to parsing render files, hacking them and rendering them, something I used to do with RIB files now have a lovely interface (kind of) and the Foundry has done a good job there. That said, what USD taking hold, we are going to see that Houdini Solaris environment opens so many new avenues that I am not looking at Katana at all. If you have a huge facility you may do great with Katana but in all honesty, having everything on one roof is so nice I can entertain it.
On the other side is Omniverse, which opens new forms of collaboration and well, that may be interesting but I think we will be, as an industry, settling on Solaris… it is too good not to.
my 2 cents