In this guide
Keep a license and dependency record for each third-party source package, then connect the production derivative to that record. Renaming a mesh, editing a texture or exporting another format does not remove the need to know where the source came from and which agreement applies.
This is a practical production register for producers and technical artists. Record the actual applicable terms and unresolved questions; do not infer permission from “free,” a marketplace thumbnail or a download button.
Register the package before splitting it apart
Save the source listing, purchase or download evidence, applicable license text or reference, acquisition date, account holder and package version. Record the files you actually received. If the project later uses only one texture, retain its link to the original package.
| Register field | Useful content | Avoid |
|---|---|---|
| Source identity | Listing URL and package revision | A local filename alone |
| Permission evidence | Applicable agreement and receipt | A remembered marketing label |
| Dependencies | Textures, plugins, fonts or tools | Assuming the main mesh covers everything |
| Production use | Project and derivative IDs | Untraceable shared-folder copies |
| Open issue | Owner and next action | Treating unknown as approved |
The Fab EULA page is one example of a marketplace’s published licensing terms.1 Use the agreement that actually governs your acquisition; do not apply one store’s conditions to assets obtained elsewhere.
Link derivatives without losing provenance
Record when a source mesh is decimated, retextured, retargeted or combined with other assets. Keep hashes or stable revision identifiers for the original and important production outputs. The register should let another team member trace a shipped file back to its source without relying on the original artist’s memory.
Distinguish external dependencies that must be delivered from dependencies needed only to author the asset. A plugin used during production is not necessarily a runtime dependency. Conversely, a texture referenced by the export may still be required by the receiving project.
Review handoff boundaries explicitly
Ask who can access the source package, which collaborators need their own access, what can be included in a supplier handoff and what must stay out of a public sample. Record the answer from the applicable terms or responsible reviewer. Do not put original marketplace source files in a public ZIP merely because the derivative is visible in a game.
For promotional captures, also check third-party marks, artwork and other dependencies that appear in the scene. The presence of a valid technical asset does not resolve every depicted-content question.
Make the register useful at release
Before a build milestone, sample production files and trace them through the register. Flag missing records, changed source terms that need review and dependencies no longer used. Assign a person to resolve each open issue. Keep the original evidence rather than replacing it with an unexplained “approved” checkbox.
Use the provenance register. Pair it with the outsourced delivery checklist and format handoff comparison. The Rendora game workflow supports traceable source and delivery records; it does not determine third-party license permission from model geometry.
Register questions
Do free assets need records?
Yes. Keep the source and applicable permission evidence, including any attribution or redistribution conditions relevant to the intended use.
Does a modified model become an independent source?
Treat the modification as a derivative in the register. Record its original dependencies and the actual governing terms rather than assuming editing erases them.
References
- Fab, End User License Agreement, checked October 26, 2026.
About this guide
Rendora publishes practical guides for teams working with configurable 3D assets and traceable production handoffs. Updated October 26, 2026.