The texture reference outlives the render engine that used it

A 3D artist's actual asset library — the meshes, the shaders, the scene files — is tied to whatever software built it, and that is fine; that part is meant to change over a career. What should not have to be rebuilt every time a pipeline changes is the folder of real-world photography underneath it: material studies, weathering references, lighting setups shot for a specific look. That folder is just images, and it should outlast every tool that has ever pointed at it.

Where a materials folder stops being useful by eye

Texturing and lighting work runs on photographic reference more than most disciplines admit — a rust pattern shot on a real fence, a lighting reference photographed at the hour a scene is meant to evoke, a fabric close-up bought specifically for its weave. That collection grows for years across projects and starts failing the same way any large image folder does: a rename during a folder cleanup breaks whatever mental map you had, and "I shot better rust reference than this on a previous job" becomes an unanswerable question once the folder crosses a few thousand files spread across external drives.

A material, found by what it is rather than where it was shot

Tag reference by material and surface property as it comes in — rust, brushed-metal, wet-concrete — and tag:any:a,b reaches all of it later regardless of which shoot or which drive it came from. rating:>=4 keeps the search to material studies that actually held up under a real shader before, not everything ever saved. AND across keys, OR inside a comma list, no parentheses.

tag:any:hdri,lighting-ref added:>2025-06     recent lighting studies only
type:video tag:any:turntable                 reference video, not renders
width:>=3000 tag:any:fabric                  print-resolution fabric shots

Where the workspace actually sits, next to a scene's own files

Registering reference/ as its own workspace keeps the material library separate from the scene files a 3D application manages, so nothing about indexing a photo library touches the actual project's asset structure. The three rows Coii Ref writes — an index database, thumbnails, and proxies for any video — all live inside the reference folder itself, so moving that folder to a faster drive moves the whole searchable library with it.

Sharing a reference archive across a small studio team

A texture and lighting team of two or three people often works from the same material archive without needing anything resembling a shared database or a live sync service. Pointing each artist's Coii Ref install at the same folder — over a network share the studio already runs — gives every machine its own local index of the same files, so a query typed on one workstation returns the same tags and ratings another artist saved earlier, without a server process to keep running or an account to manage for the team. Nothing about this setup is specific to teams; it is the same single-user workspace, pointed at by more than one Mac.

What actually gets indexed, and what does not

Coii Ref reads images and video only. A .blend, .fbx, .usd, .hdr or any other 3D or HDRI-container format is not indexed and does not appear in search results — this is a photo and footage reference library, not an asset manager for the scene itself. Where an HDRI is exported as a preview JPEG for browsing, that preview is an ordinary image to the index and searches like any other; the source HDRI file stays wherever the pipeline already keeps it.

Turntable and lighting video, on the same terms as a still

type:video tag:any:turntable rating:>=3     usable turntable captures
type:video ext:mov width:>=1920             full-resolution lighting studies

Reference video for texturing and lighting — a turntable capture of a real object, a lighting reference filmed at a specific time of day — goes through the same index pass as a still image: dimensions read, tags and ratings attach the same way, and it is reachable from the same query line rather than a separate video mode. A canvas mixing stills and short clips of the same material shows a proxy for the video at canvas resolution, so a board does not stutter decoding several source clips to compare against photo reference side by side.

Reference gathered on location, indexed the same as a stock purchase

Texture and lighting reference comes from two very different places — photos bought or downloaded for a specific material, and photos shot on location or on a studio floor specifically for one asset. Both end up as ordinary image files, and Coii Ref treats them identically once they are on disk: a phone photo of a real weathered door shot for one prop indexes, tags and searches exactly like a purchased material pack, with no distinction in the database for where the file came from. That matters because a shoot done for one job is frequently the best reference for an unrelated one months later, and it only pays off a second time if it was tagged by what it shows rather than filed only under the job it was shot for.

tag:any:location-shoot rating:>=4          location photography, not stock
tag:any:purchased,stock-pack               licensed material packs

Neither category needs its own folder structure to be searchable this way — a tag recording the source is enough to separate "can I use this commercially" from "does this look right," which is a distinction a folder name alone tends to lose within a year.

Building a folder shape around materials, not projects

A pattern that holds up across studios and freelancers alike is organising reference by material and surface property rather than by which project it was shot for — Metal, Fabric, Vegetation, Skin — with a project tag layered on top for anything shot specifically for one job. That answers both "what rust references exist anywhere" and "what did I shoot for the outpost job specifically" from the same folder, because the query line does the sorting a folder structure alone cannot. Neither structure is required by the app; an existing per-project layout works exactly as well, since the search reaches into subfolders regardless of depth.

What carries over from an asset-manager-style tool

Software built to manage a game or film pipeline's actual asset library — version control on meshes, dependency graphs, render farm integration — solves a different problem than this page, and Coii Ref is not a substitute for it. What it replaces instead is the photo folder sitting beside that pipeline: the real-world material and lighting reference a texture artist or lighter still opens constantly and still, in most studios, searches by scrolling. That folder does not need a pipeline tool; it needs to be searchable by tag and rating, which is the entire job here.

What a killed asset's reference is still worth

A shader or asset that gets cut from a project late does not take its reference photography down with it, if that reference was tagged by material rather than only by the asset it was gathered for. A weathered metal study shot specifically for a cancelled prop is exactly as useful the next time weathered metal comes up on an unrelated job — findable with tag:any:weathered-metal regardless of which project folder it originally sat in, rather than lost inside a directory nobody has opened since the cut.

What it costs and what it runs on

$19 once, three Macs, updates included, nothing that renews. The trial runs 30 days with every feature active, no card and no account required. It needs macOS 11 Big Sur or later, Apple Silicon or Intel, as two native builds.

The app's only outbound network activity is a licence check on Activate and a launch-time read of a server's Date header, so a wound-back clock cannot stretch a trial. There is no in-app updater, so no update check, and no analytics or crash reporting.

Past day thirty of an unpaid trial, growing the library — registering a new folder, running the importer, starting an index by hand — needs a licence. Everything already indexed keeps reading, and the folder watcher keeps running, permanently.

Working the same reference folder across a studio machine and a laptop

A freelancer moving between a desktop workstation and a laptop, or a studio where a reference drive is shared across a small team, can register the same folder from more than one Mac — each machine builds and keeps its own local index of the same files, with no server or account required to do it. Licensing covers three Macs on one purchase, which in practice covers a desktop, a laptop and a studio machine without a second payment, though each one indexes independently rather than syncing state live.

Reference that outlasts a change of render engine

Studios and freelancers alike change render engines and DCC packages more often across a career than the underlying photography they light and texture from should have to. Because Coii Ref indexes ordinary image and video files rather than anything tied to a specific pipeline, a change of software touches only the scene files a 3D application manages — the reference workspace beside it keeps its tags, ratings and canvases exactly as they were, ready to be registered again with whatever comes next.

Who this actually suits

A texture artist, lighter, or generalist whose actual bottleneck is finding real-world material and lighting reference fast enough to matter mid-shot, not managing the 3D scene files themselves — this app has no opinion about those. If the job needs pipeline-level asset management with version control on meshes, that is a different category of tool entirely and this page will not pretend otherwise.

For the wider case without the material-specific framing, the general reference-manager page makes the same argument, and where reference is mostly footage rather than stills, the video reference manager page covers that in more depth. A related but deadline-driven version of the same argument, aimed at concept work rather than production texturing, sits at the concept artist page. Against the two most-discussed full libraries, refern adds an on-device tagger and search by meaning this app does not have, and Eagle copies what you import into its own library rather than indexing files in place — worth a look if the library needs to travel with a laptop that has less disk space than the reference does.

A material library built this way also survives a change of Mac entirely — copy the reference folder to new hardware, register it once, and the index, thumbnails and proxies rebuild from what is already tagged and rated on disk, with nothing to re-download and no account to sign back into.

Thirty days, every feature, no card and no account: download it and point it at the reference folder sitting beside your current project. Index the largest materials folder first — it is the one where a tag search across years of shoots changes how fast blocking out a new shader actually goes.