search

cedricduriau / Cryptomatte

Cryptomatte Nuke plugin, sample images, and specification
BSD 3-Clause "New" or "Revised" License
6 stars 1 forks source link

Update Documentation #23

Closed cedricduriau closed 3 years ago

cedricduriau commented 3 years ago
AndrewHazelden commented 3 years ago

I had a idea for a Reactor "network" installer concept I never rolled out, that could be interesting to adapt for a Fusion centric Crypto test suite that would function as a render farm "deployment validation" stage.

Fusion supports SxS (side by side) scripts where a .lua script and a .comp have the same base filename like "basename.lua" and "basename.comp". When the Fusion comp is opened, the SxS script is run automatically.

Fusion also supports intool scripting via lua that lets you pack a minimal Lua script into a node in your composite for events like frame render, or start render, or end render task handling.

It would be possible to make a "Cryptomatte-Validator.comp" that could be loaded into the Fusion Render Manager and run as a job across all the Fusion Render Nodes on a render farm.

The test comp would be able to make an output of a validation test image per render node, and a JSON text file report from all Cryptomatte test units on each render node with the hostname, fusion version, and other details logged, too.

Plus a PathMap scan could be done by a validation script to locate and report duplicate Cryptomatte fuses, or legacy Crypto Lua modules present on each render node, along with fuse version checks too.

JPDOC and other WSL users have reported in the past Cryptomatte issues on their render farms with dual versions present so making those situations easier to troubleshoot would be handy.

This could be another edge-case need sort of Reactor Cryptomatte distributed tool option which would be handy for people using the crypto fuse tech "at scale" in their VFX workflows.