Hi Alan.
Thanks for posting this!!! I totally agree.
* * *
Here is my personal TL;DR list of Loader node benefits.
In a VFX workflow context, the dedicated Loader node still has a lot of really useful purposes where it would be very beneficial to have a Loader node available inside of Resolve, sitting there alongside the existing Media Pool based MediaIn node.
A MediaIn node is great for working with video footage that is located inside the Media Pool and is part of the video editing timeline sequence. MediaIn nodes work best in the Fusion page when most of the video clips are all at the same base resolution/aspect ratio and have the same approximate frame duration as the rest of your Fusion page timeline media. Mixing single frame duration media with longer video clips, or footage with differing aspect ratios gets messy fast with MediaIn nodes.
A Loader node is great for all of the other random small things you need to add repetitively to all your comps that don't conform to the Media Pool expectations. Things like static images that you'd rather not have to put in a Compound clip or add a Time Stretcher node to adjust the duration longer then 1 frame, image plane references at super high resolution you need to have in your comp and then swap out quickly without wanting to touch the MediaPool DB each time, image-based texture maps that are related to your imported FBX/ABC models that you want to be able to manage with a simple Filename field on a Loader node to pick the right asset without having Resolve place all of your dozens or hundreds of "non human readable" UV layout based texture maps into the Media Pool where they don't really belong next to the full-length video clips for the project.
Here is my top list of things that I miss having a Loader node in Resolve to help with:
- A Loader node would allow users to copy/paste example Fusion page comp files with a pre-defined image filpath from the BMD Resolve and Fusion forums "code" block elements that users share to help each other. With a Loader node, all the media resources would be brought into the Resolve Fusion page correctly without the dependency on the assets existing in the Media Pool. A MediaIn node doesn't provide the ability to embed those relative PathMap based filepaths into a copy/paste macro style text snippet that would be relevant outside your own personal Resolve Media Pool DB.
- A Loader node (and a Saver node) working together allows VFX artists to start their timeline and the footage loading on a frame range value like a Render Start frame value of 1000 or 1001. This means VFX artists get all the particle pre-roll time, and media handles needed on footage that a film or TV project could possibly require.
- A Loader node can be embedded inside of a Macro .setting file/title template which allows 2D image resources, and file texture maps for Fusion 3D system mograph elements to be loaded as design elements in a Resolve title template. MediaIn nodes do not allow this media resource embedding to happen in a .setting file AFAIK.
- A Loader node can be embedded inside of a MacroLUT that works inside the Fusion viewer window. This allows interesting things like logo burn-ins, or complex image processing effects like live UV pass lens warping previews to be done in the Fusion page viewer as a live LUT "view shader" effect.
This image shows the "ViewerWarp LUT.setting" MacroLUT that used an internal Loader node inside the macro to let you load in warping template UV images that would be applied interactively on the current Viewer windows based media footage to do things live 360VR camera lens stitch previews in the viewport, or fisheye lens to LatLong conversions on the fly, etc... The ViewerWarp LUT was part of the original KartaVR and Domemaster Fusion Macros 360VR tools.
- viewerwarp-lut-edit-prefs.png (238.79 KiB) Viewed 4329 times
- A Loader node would allow the Reactor provided "
Fusion Comp Link" script to fully send all nodes from a Fusion Standalone comp over to Resolve and back again without any missing node errors. We've got the Saver node in Resolve 15 Beta 7 and with the addition of a Loader node artists could round-trip their comps with no data loss at all. IMHO that is a super useful workflow boost that allows core compositors who live in Fusion Standalone to use Resolve for some tasks and then return all their nodes back to the dedicated compositing environment that is Fusion Standalone to render their footage on a render farm with the Fusion Render Manager.
- A Loader node can be saved in a plain text Fusion .comp file that is easily created by external VFX production pipeline tools like the
SynthEyes camera matchmoving software. If a Loader node existed in Resolve's Fusion page, any VFX tool that supported Fusion Standalone centric Loader and Saver nodes would be able to have their exported .comp data work in Resolve today too.
Having Loader nodes in Resolve would also allow any of the external VFX tools and external apps that generate macro style copy/paste clipboard image resources (like SynthEyes offers) to be able to be loaded into the Resolve Fusion page with a simple "
Command + V" or "
Control + V" hotkey press for the production assets and lens correction elements that exist outside of the current Media Pool.
(Tech Note: It's worth noting that 3rd party developers and VFX houses who consider supporting and using Resolve 15's Fusion page will eventually need to figure out a way for data interchange if they start to use the Resolve Fusion page across hundreds of comps in dozens of Resolve project files at their company.
These professional production level users will need a way for an external tool in their pipeline to be able to access all of the raw Fusion composite data their artists create that is stored securely locked inside of a file via Resolve 15's proprietary .drp "zipped" file format.
As things are right now, by design a Resolve .drp project file stores each of the Fusion raw Fusion comp data records in a binary encoded XML file record that no human can read and you have not published any specification for or notes about.
Many of the other records in a Resolve .drp file are plain text XML files that are easy for an external script to parse. None of the fusion page comp data is treated that way with the strange serialized binary encoding that is used. To me, it really does not make any sense why you do this to the Fusion comp data since the entire Resole .drp file is zipped anyway so you get a basic binary compaction and space savings on any of the raw ASCII formatted XML text files that are present for no extra effort.
Ideally that Fusion page data (that is saved in your XML record, in the .drp file) should be stored in a text formatted Lua table like the existing Fusion .comp files do in Fusion Standalone. If you also allowed a Loader node to exist inside that comp file record, then it would simply be a matter of a VFX studio having a terminal script use the zlib/zip library to jump into a folder full of zipped .drp file and extract each of the Fusion comp Lua data documents. then the Loader filename records can easily be read programmatically from the Lua table via a super fast plain text "regular expression" search.
AFAIK there is no known way for a 3rd party company to open a damaged Resolve .drp file that crashes instantly to extract and salvage any Fusion page production data since it has that binary encoded Fusion page record + the MediaIn nodes are not externally parsable.)- A Loader node would allow media resources to be added by Resolve (free) directly to the current Fusion page composite from a simple Lua script or a .fu file based Hotkeys / Action entry without needing the user to have Resolve Studio for access to the Resolve API. The full Resolve API really is overkill for a simple 1-press image loading hotkey a person could create in ~3 or 4 lines of .fu code to instantly add their company logo or another element to any of the Fusion page comp's in any of their Resolve projects.
- A Loader node working alongside the Resolve 15 Beta 7 added Saver node in a Fusion page composite would make the RunCommand node function as expected. Without a Loader node being made available in Resolve 15 Fusion page, the powerful and useful RunCommand node is made pretty much useless and irrelevant to a PipelineTD who needs to interconnect their Fusion page composite file based assets with the rest of their VFX pipeline.
AFAIK the RunCommand node in Resolve doesn't have a way to interface with a MediaIn node. What I mean is the MediaIn node's CustomData MediaProps storage of the Media Pool clip details is not compatible with the current implementation of the RunCommand tool since the MediaIn node lacks the accessible Filename data on the inputs section or metadata Filename record.
The lack of a Filename field input on the MediaIn node means the required information can't be cleanly passed into the RunCommand node with a typical Fusion simple expression or intool scripting approach that works on all other nodes in the Resolve Fuson page. As a quick example, design wise the FBX and Alembic mesh nodes are fully compatible with the RunCommand node and readin their Filename attributes from an intool script and an expression while MediaIn node isn't so lucky.
You don't even have the raw filename displayed as visible text on the MediaIn node's Inspector GUI window as a read-only text string that would let a user select that information with their mouse cursor and quickly copy/paste it into the RunCommand node fields if they needed to enter those details manually in Resolve.
As far as the RunCommand node goes, I'd truly love to hear a BMD Resolve developer or product manager explain in a sensible way how the RunCommand node works more successfully in the context of a Resolve Fusion page composite with the new MediaIn and MediaOut analogy then the freedom and flexibility that the previous Loader/Saver nodes allowed in Fusion Standalone. Like really, I don't think you can make a sensible case that Resolve's Media Pool centric handling made things better for the RunCommand node. I've tried to think of a use case but have come up blank because MediaIn nodes won't share their filename data with other nodes via expressions, and a MediaOut node has no defined output name from inside the Fusion page space. 
- A Loader node and Saver node combination allows you to easily bake out multiple parts of a complex node based composite with things like optical flow or stereo disparity mapping, or complex particle based renders that take a long time to compute (like 30+minutes for a short clip) to intermediate files that live in the current composite at a PathMap managed location that can be shared across your artist systems.
You can then re-use these pre-computed image sequence elements via new Loader nodes added in the same Fusion page comp, or copy/paste the Loader nodes for the intermediate files into other comps, or send them via a messaging app to another artist on your team.
If artists were working inside of a complex and slow to update Resolve Timeline based Fusion page comp this Loader > Saver node process of baking the really slow to render elements out and re-using them could help to cut down on hours of un-needed rendering duplication. This optimization is especially important as there isn't a "Fusion Render Node" app and unlimited render node license equivalent offered yet in Resolve Studio 15's Fusion page environment that would allow an existing Fusion Standalone based Render Farm to take up the slack and accelerate your output to the amount of productivity lost from not having the Loader/Saver pair of nodes available.
When working with baking parts of a large composite to disk, the existing Eyeon Fusion era "Loader from Saver" tool script in the past made it a 1-click process to bring the parts of your comp that were saved to disk back into the comp to allow artists to continue building mega-comps in the same document.
- A Loader node makes it easy for a simple expression or intool script or fuse working in a limited variable scope to access the metadata details on any node downstream of the Loader node in the comp using a Lua command like:
- Code: Select all
meta = comp:FindTool('Loader1').Output[comp.CurrentTime].Metadata
dump(meta)
or
- Code: Select all
==comp:FindTool('Loader1'):GetAttrs()['TOOLST_Clip_Name']
*You would typically switch your Lua code over from using the comp:FindTool() function over to self.Comp when in placing it inside a fuse or intool script.*Also, it is very easy for a Fusion Standlone scripting TD to then take a Loader/Saver based Relative PathMap location that was defined in the current Fusion comp's PathMap preferences and translate it into an absolute filepath using Lua code like:- Code: Select all
filename = self.Comp:MapPath(filename)
The Resolve API in Resolve 15 Beta 7 and interfacing with the Media Pool from a script cannot be used or accessed from the scope of an intool script or simple expression which is a major detractor for Pipeline TDs who might be asked to see how well Resolve's Fusion page fits in with an existing Fusion standalone based VFX company pipeline.
- The Resolve Media Pool cannot be accessed from a Fusion page Console Fuse module. This makes it difficult to use powerful Console Fuse tools like the Reactor provided Slash Commands to when you are stuck using a MediaIn node and want to do asset management tasks. Loader nodes, by comparison, are well behaved and work really nicely with Console Fuse and Slash Commands so a pipeline TD at a studio, or anyone else who likes to write a script in Lua code could create a custom scripted tool that adds new and simple Console window based functionality.
This Loader node vs MediaIn node (and Resolve API limitations) issue can be seen if you installed
a Slash Command like SlashFootage or SlashFor from the Reactor package manager.
- A Loader node and the Saver node supports the use of IFL filename sequences which enables non-sequentially named image files to be loaded into a composite using a text file ending in the .ifl file extension with one image filepath listed per line in the IFL document.
This IFL support in Fusion Standalone is great if you want to be able to make custom image sequences out of existing assets and you don't want to have to rename the original filenames into a Resolve happy "name.###.ext" linearly numbered sequence, or end up duplicating a hundred gigabytes+ of EXR files. Without IFL support you have to manage the original files, and then keep your Resolve renamed image sequence numbered copies of the same footage in sync which mean you have twice the number of assets in your pipeline to backup and store and think about.
- A Loader node would allow the previous license holders of the KartaVR v3.x for Fusion Standalone toolset to run it inside of Resolve 15's Fusion page without any changes to the Lua scripts, macros, MacroLUTS, and fuses.
The KartaVR PanoView hotkey, the "Send Media to" scripts, the included "Send to AGI Photoscan" photogrammetry workflow tools, PTGui panoramic importer script, the automatic "Generate UV Pass in PTGui" script, and the "PTGui BatchBuilder Creator/extractor" scripts would instantly work inside of Resolve 15 the same way they were designed to work run inside of Fusion Standalone with no changes needed to the software.
Here are a few videos that show those KartaVR scripts working with Loader and Saver nodes inside of Fusion Standalone:
In the clear absence of any plublic 360VR tools development roadmap from BMD, or new immersive tools being added to Resolve 15 between now and the Resolve 15 final shipping version, KartaVR is one of the few options for node based 360° stereo video stitching, 6DOF RGBZ 360° image handling, and complex immersive media production that might be able to work inside the Resolve 15 Fusion page environment.
Only a few days ago
Tom Polson posted he was interested in BMD Fusion having a PTGui Project importer tool that worked in a Fusion comp. Well, the lack of a Loader node in Resolve today means the existing 3rd party created PTGui importer script that was created to work in Fusion 7-9 doesn't work at all in Resolve. If a Loader node existed in Resolve then that script would run right now without any changes required to the existing Lua code.
- A Loader node would allow the existing
Cryptomatte for Fusion fuse that is available inside of the Reactor package manager to work with Resolve 15 Beta 7.
The MediaIn node currently lacks the required Filename metadata tags that are essential for the Cryptomatte node to work successfully in Resolve. That metadata Filename information provided by a Loader node allow numerous Cryptomatte nodes to be placed anywhere the artist wants down-stream of the original node that brought in the EXR image data into the comp.
(Tech Note: When I tried to get Cryptomatte v1.2.1 (WSL Reactor Edtion) to work manually in Resolve 15 Beta 7 with the MediaIn node's deficiencies I had to do a strange workaround that involved using a:
- Code: Select all
MediaIn Node > LifeSaver Fuse > Cryptomatte Fuse
- 2018-07-30 WIP Cryptomatte Support in Resolve via LifeSaver Fuse.png (768.87 KiB) Viewed 4329 times
This workaround to get Cryptomatte to function leveraged exotic aspects of the of
Reactor package manager provided LifeSaver fuse that works only when the fuse is set to the "
Format > Save File > None" mode and you have the Filename field set to match the name of the Media that is being imported from the MediaPool.
- 2018-07 Life Saver - Save Frames - None.png (19.57 KiB) Viewed 4329 times
The LifeSaver fuse added the image sequence named Filename metadata attribute that filled in for the missing entry that is present in a "real" Fusion Standalone Loader node but nowhere to be found on a MediaIn Node. Also, the LifeSaver fuse also fixed MediaIn > Cryptomatte DoD/Proxy setting issues that became apparent.
Mon Jul 30, 2018 9:23 am
