Chris Wells wrote:These are two separate markets, Post houses vs VFX houses. The professionals that wear all the hats and work on editing and color and even do impressive VFX vs the professionals that only do VFX. Can davinci do some VFX, sure, can it hold up to doing a very intense VFX show, no, no it can't.
Where I come from people specialize, on big films people specialize. If anyone thinks the next Big Marvel VFX could be done in davinci, well, they don't know enough to know how little they know. I'm not saying BMD is wrong for going after the post house/adobe market, it's a very big market, but it is naive to think davinci will replace/grow in the VFX house market. Will it replace compositing tasks, sure, some of the tasks. BMD is coming at this from a post house view, not a VFX house view. and it'll be great for you post house guys. All us old time VFX guys, well we aren't going to get with the times and start using davinci, we are going to keep using old Fusion until it's dying breath, or moving to Nuke and the foundry, a company that seems to get VFX houses. BMD will do fine, they will grow their post market that they understand and davinci user's will do some green screen comps and think they are now officially compositors. But davinci will not get the heavy VFX shots.
I wish BMD would continue to support and develop Fusion, But I think fundamentally they don't get VFX houses. They don't understand that market and it's needs.
This is very true unfortunately. It would make sense to get VFX houses involved with the development, but from my understanding that was not the case. It was put in there for the editors and colourists to play with.
Kays Alatrakchi wrote:I think you're missing the forest for the trees. 10 years from now, the idea of having to jump to different apps for compositing to editing to color grading will seem downright medieval.
I think you're missing the point entirely from a VFX house point of view. See Chris's answer. Specialised tools exists to focus on industry specific problems. Its less so that its missing features, Resolves architecture and forced workflow is incompatible how VFX houses does work. That would be OK if the proposed workflow was better, but it isn't. Its severely limiting.
Here's just two major showstoppers
1. Database VS files on disk
Resolve uses a DB, VFX houses in general tend to have their own DB coupled with files on disk. Files on disc are a de-fact standard in VFX. The files (.comp, .nk, .shk) are ASCII files thats easy to read and easy to manage with third party manipulation. Granular control is KEY. Files on disk is a KEY element.
Here's a couple of issues caused by not having files on disk or direct access :
* Backup issues with using a DB instead of files. Restoring single versions of a .comp instead of having to restore an entire projects database. Imagine an artist gets a corrupted .comp and needs to restore a previous version, this is easy with restoring the single file from yesterday. But if you have to restore the entire snapshot of yesterdays DB then you'll not only waste resources but potentially revert back the ENTIRE project by 1 day. This isn't a hypothetical example, its everyday.
* Version issues, lighting, compositing, paint & roto and DMP departments all use comp to generate images for review and presentation. The segmentation between departments and artists are usually done via naming convention and storage location on disk. A single compositor can easily do 100s of file versions of a single shot when you count major and minor version. A lighting artist might have less versions but still 50+. This is all excluding hidden shadow copies of the .comps meant for render-farm usage. Currently in Resolve 15 there are no way to scale to these numbers with Fusion, no way to specifically label or fetch comps based on departments or any other tags. Which are usually done via file name and naming convention of .comps on disk.
* Size issues, if a single shot can consist of lets say a 500 .comp versions of a shot (100 for comp, 20 for lighting, 40 for paint and roto, 10 for tracking, 40 for DMP, 20 for environments, and 100 for models, 100 for FX and 70 for anim) And if each version gets rendered on the farm 5 times (a VERY conservative number) thats 2500 .comps pr shot. Compositors often include 2d and 3d tracks in their files, and paint and roto also includes a lot of paint and roto strokes, these operations usually make a .comp grow significantly in size. Again if we choose a conservative size of 5mb pr comp we end up with 12.5gb in just RAW project files for a SINGLE shot. Not counting image/geometry data of course. Having to use Resolves DB to reconcile this data-management is unwarranted as most places have solved this issue with external naming convention, tracking tools and with the assurance that good file systems scale horizontally. This is untested ground in Resolve that the VFX industry at large have solved through naming and file structures.
* Naming issues, currently no way of naming or managing versions in Resolve beyond the most simplistic approach. The VFX industry has mostly agreed on some standards for naming conventions (the mpaa/marvel/WB all share very similar structures that all the VFX vendors adhere to).
* .Comps often need to live outside of a shot-context. Especially early on for assets, look-development and pipeline related work. Having them exclusively tied to a clip on a timeline is not needed and counterintuitive if you factor in multiple artists and vendor sharing.
These issues aren't just missing features, they are missing parts of the architecture from a VFX pov.
2.Deliver page doesn't scale
VFX is a VERY iterative and bi-directional process, not only is compositing at the heart but its responsible for farming out images to other departments in iterations, and bringing them back in in a feedback-loop-like process.
Comp departments are responsible for delivering content to other departments in unique specifications, example would be delivering a plate for 3d tracking. Comp renders out undistorted plates with internally neutral graded colors in both .EXR and .PNG for the trackers to work with. Often are blocking roto also provided. As the trackers are working on it there might be need to re-adust work and provide the tracking department with updated plates. A shot can also contain multiple plates (imagine multiple green screen elements, single shot stitch work etc).
This isn't limited to images, the FBXexport node shares the same sentiments. If a comper updates a camera track in Fusion it needs re-deliver it to the lighting, FX and anim departments.
Because the need to funnel image and geometry data in a bi-directional fashion the saver and loader nodes are KEY to provide a stable, predictable, scriptable way of splitting out images for various departments. At this scale; automation is KEY.
Currently the deliver page has VERY simplistic approach where each iteration would have to be manually edited should the output need to be changed pr department or even version.
Fusion standalone solves this with the Loader and Saver nodes, and it's scripting capabilities.
This shouldn't be an afterthought, it should be a core functionality if Resolve should be considered for this type of VFX.
Oh and heres a few more showstoppers (that CAN be fixed without changing the Resolve architecture)
- Limited EXR support (need all channels)
- Broken metadata handling (fusion can't read resolves metadata and resolve can't read fusion metadata)
- No custom frame ranges (all my shots NEED to start at x1001, not some arb. frame number based on cut)
Fusion standalone solves all of these.
To end with a somewhat pedantic analogy,
I need this :
![surgical-equipment-500x500.jpg](./download/file.php?id=17654&sid=c39eff5eaf3463735be95e57bb68dd36)
- surgical-equipment-500x500.jpg (17.02 KiB) Viewed 253579 times
Not this :
![giant-swiss-army-knife-6181.jpg](./download/file.php?id=17653&sid=c39eff5eaf3463735be95e57bb68dd36)
- giant-swiss-army-knife-6181.jpg (64.24 KiB) Viewed 253579 times
-t