The On-Set to Post-Production Disconnect (and how we can fix it)

posted: May 16, 2026, 5:50 p.m.

VFX-Supervisors and Data-Wrangler collect a vast amount of data on set, both during the shoot, but also during recces and working with the camera department to film lens grids and so forth. It can be immensely frustrating to find that artsts are not able to use this data because they don't know it exists, they receive it too late or it is not easy to find or navigate. This often creates a bottleneck where artists have to wait for supervisor time in order to show them where things are.

As is often the case, the problem begins in pre-production. As soon a a screenplay is received it is entirely possible to create entities in your facility database, be that Shotgrid (Flow, whatever Autodesk marketing comes up with next), FTrack or a bespoke system. The first entities that can be created, directly from the screenplay are Assets: Every location is an asset. So if you read the line:

INT - SHIP COMMAND DECK - DAY

Then we can immediately create a Ship-Command-Deck environment asset. This doesn't necessarily mean we will end up doing VFX work on it. But should we capture the set with photogrammetry/gaussian splatting, HDRIs, or simply just measurements and reference photos, that data will have a home to live in.

Likewise we can create a Character asset for all the characters we encounter in the screenplay, we might end up doing digi-doubles or head-scans, we might not. But again, any info we capture about that character has a place to live. Likewise if we read an action line like: Helen picks up the PLASMA-GUN then we might as well create a Plasma-Gun asset. We might also need a Helen asset too, perhaps merely a simple 3d proxy to capture bounce light from the plasma-gun.

Note when I say, 'create an asset', I do not mean we book artists to build a 3D asset. I simply mean the Asset entity on our asset management system. It costs nothing to have an unused "Asset" on the database, and we can hide any unused assets once we have confirmed they are not needed.

Database entries are Boxes:

I made it a heading because it's important, and at the risk of repetition, when we talk about making "assets" we are just saying, let's make Ship-Command-Deck box to put anything we capture about that environment, and let's make a 'Plasma-Gun' and 'Helen' box to keep their stuff in to. Like I said they may end up remaining empty boxes and that's OK.

It is worth erring on the side of too many assets rather than leaving them out. For example set reference or scans for an ENVIRONMENT (ie location) might be useful for paint-outs even if no VFX was in the original bid.

Recces and meetings:

In the lead up to the shoot you may accompany the clients on a Recce of the locations. During the recces you might already be taking reference photo, making measurements, discussing angles. greenscreens and all manner of other things. You might be meeting with costume and art departments and need to capture reference for props that might need enhancing, replacing or replicating in VFX.

Slates and Cameras:

Either shortly before, or shortly after the shoot, it is likely you will be shooting lens grids for tracking. Don't forget comp can also use the lens grids to capture the chromatic aberation of a lens. A lot of shot management systems have a "camera entity" you can use to store this information. Remember the grain should be linked to the camera body, while the the lens needs to account for a specific sensor+lens combo. For camera bodies we want to record the Make, Model and Serial number. For Lenses we want to record the Make, Family, Prime/Zoom, Focal Length (or range for zooms), whether it's Anamorphic, Spherical or some specialist lens type, Serial number, and the Sensor/Film Back(s) it is being shot on.

Lens grid files can be eventually be published as: [cam-make][cam-model][cam_sensor][cam-serial][lens-make][lens-model][lens-serial][focal-length-used][clipname][take][yymmdd]

And similar conventions can be used for bokeh and grain plates.

While you are there, why not also capture grain plates (which you can also use to model the vignetting of a lens). Lastly if you can it's great to capture the bokeh of a given lens/focal length. The advantage of modelling things like vignetting, aberration and bokehs for each lens used at the show level like this is that more time can be spent on nailing the exact look and then that look can be rolled out quickly across multiple shots, perhaps hundreds of shots. 2 Days spent nailing a lens look precisely is probably too expensive for a single shot, but for 50+ shots it's pretty cheap!

During the shoot itself, you are mostly going to be dealing with Slates. Now slates are different to Shots; shots are based on the final edit (although there may be many named shots in the storyboard or previs). on-Set the camera crew will be recording Slates: Reel, Scene, Take, (Pass). Basically, everything that happens between "Roll Camera!" and "Cut!" will be recorded under the slate.

For example imagine a classic scene approach of shooting a wide master and then a series of Mid Shots and Close Ups. A single take of the Master might end up being used for multiple shots in the final edit, we won't know how many shots until we receive the edit, possibly months after the shoot. But if we have the Slate information recorded, it's simply a matter of linking the final shots to the original slates from the shoot. We should have a ball and chart for each slate, which again means that same ball and chart might be used for several shots in a sequence.

If we have already recorded the cameras being used, then filling that info in during the shoot will be a lot faster, since we can just attach the same camera/lens entity to all the slates that use it.

There are arguments for capturing HDRIs to the slate or to the Environment asset. However if the light is changing because takes, whether because it is natural light, or because of artistic adjustments made by the DOP it is worth having HDRI panos per slate. If we have the luxury of capturing HDRI maps of set-lights and or the Sun, then it is worth publishing them to the Environment Asset.

HDRIs could be captured using a convention like this: [slateName][type][shotDate][location]day/night

*The optional descriptor might be something like overcast, sunny, noPyros etc…

When capturing each slate we should record: • Which camera/lens recorded the slated footage • Camera setup (crane, dolly, handheld etc…) • Focal distance and other measurements. • Which passes were filmed for that slate (ie fg, bg, clean plate, ref, element etc…) • Which Assets are used in that slate (ie which Environment, which Characters, which Props) • The VFX expectation for the slated footage at time of shooting. • Source clip and timecode

This information should flow downstream to the Shots.

Environment Assets:

Create an asset for each location in the script. All LIDAR, Photogrammetry, gaussian splats, plans and measurements should be published under this asset.

[show][script-location]physical-location[type][int/ext][day/night][yymmdd]

E.G. photogrammetry of the QUEEN-VIC location shot at The Hat and Tun 11th Jan 2026 would be:

end _queen-vic_hat-and-tun__pgram_ext_day_260111

Note the reason we always record them as script name, location name in that specific order is because otherwise it could become confusing (was that Queen Vic pubs shot at The Hat and Tun or the Hat and Tun shot at the Queen Vic??)

Prop Assets:

These can be placeholders under which pscans, textures, reference etc… can be published. These should be named as per the script ie:

[show][script-name][_state][

The optional “state” entry is used when a prop can change between “on” and “off”, “new” and “broken” or whatever.

Creature and DigiDouble Assets

Every creature or possible digi double in the screenplay should have an asset created inyour asset management system even if it is not 100% certain there will be 3d Asset. These can be placeholders under which bodyscans, textures, reference, concept art etc… can be published.

Shots:

Shots are the unit most artists interact with on a daily basis. Therefore it is critical that all slate information is accessible via the Shot entity.

Shots most likely won’t be known until the client is ready to turnover and there is an edit ready for us to work on.

Every shot needs to be linked to: • The source slate (the shot material), in this way all HDRIs, reference photography, cameras and assets will be recorded to the shot. • All relevant Assets • All on set-reference (which will have been recorded under the assets and/or slates)

To link Shots to Slates we will have the following clues: • Source clip - either in metadata, burn-in on client offline and count sheets • Explicitly recorded in count-sheets • Clapperboard reference from client editorial (unlikely on factual)

Assets will have originally been linked to Slates, so once slates are connected to shots, the assets should also be linked to assets. In cases where this doesn’t happen automatically, assets will need to be linked to shots by editorial.

A Database is a Map:

That is all it is. Behind all the fancy names and fancy code, all we are doing is creating boxes to hold information and work we have done. As we go, we are creating maps to link those boxes so that anyone can find them. Just as I don't need to understand satellite technology in order to use GoogleMaps, I shouldn't need to be a Supervisor or Head of Production to use the Asset Database.

If we create the assets before shoot attendance then any data collection methods (forms, spreadsheets etc…) can be based around these requirements. Getting the data into the system will be faster and we avoid the risk of departments having to start work before vital information is ingested or ordered.

Reference:

https://camerareports.org/

https://community.shotgridsoftware.com/t/camera-and-lens-info-table/2568/2

Apps:

https://setellite.com/

http://www.shotbot.com/

modified May 17, 2026, 12:41 a.m.