From Sulu Market to finished Blender frames
By Superluminal Engineering
A clean path from purchasing a Blender product to installing it, opening the scene, submitting a render, and checking the final output.
Published 2026-07-29 · Updated 2026-07-29
Publication status
This noindex protocol defines how a Sulu Market product can earn a narrow, evidence-backed “render-tested” result. No product has passed the public gate yet, and the page does not imply that every Market listing can be installed or executed on the render farm.
Superluminal operates both the Market and the render service, so the conflict is explicit. The test must be reproducible, rights-cleared, and willing to publish a failure.
Required test product and environment
The fixture must be a specially licensed public test product. An ordinary seller package or customer project cannot be repurposed as marketing evidence without permission. The product record needs an exact version, package hash, license scope, Blender range, dependencies, installation instructions, and known external services.
Installation starts from stock Blender in a clean environment. The test cannot inherit a developer machine's preferences, cached package, hidden Python module, activation state, or credential. The exact Blender patch must come from the version inventory.
Acceptance chain
| Step | Evidence | Pass condition | Status |
|---|---|---|---|
| Entitlement | Authorized test transaction or grant | Correct package becomes available | Pending |
| Package identity | Version and cryptographic hash | Download matches recorded artifact | Pending |
| Clean installation | Fresh Blender environment manifest | Package installs without hidden prerequisites | Pending |
| Activation | License and activation record | Declared fixture function executes | Pending |
| Selection | Explicit add-on include choice | Intended module is packaged | Pending |
| Dependency scan | Sanitized manifest and warnings | Expected files and issues match | Pending |
| Submission | Exact runtime and job manifest | Correct Blender and product versions travel | Pending |
| Farm activation | Sanitized runtime evidence | Product activates under tested terms | Pending |
| Render | Original local and farm outputs | Declared hash or tolerance check passes | Pending |
| Revocation | Entitlement and cleanup test | Expected access is removed in scope | Pending |
The add-on mechanism explains selection and packaging. The dependency registry explains scan classes and warnings. Neither page by itself proves a Market product's runtime behavior.
The complete Market-to-render workflow
- 1 · Acquire an authorized entitlement
Use a dedicated rights-cleared test product and record the product package version and hash.
- 2 · Install into stock Blender
Begin from a clean supported Blender patch with no developer preferences or hidden dependencies.
- 3 · Activate and exercise the product
Record installation, activation, licensing behavior, required services, and one repeatable test action.
- 4 · Select, scan, and submit
Include the add-on deliberately, inspect dependencies, package the scene, and submit to the exact farm runtime.
- 5 · Render and compare output
Retain local and farm originals, manifests, logs, hashes or tolerances, and any negative result.
- 6 · Revoke and verify cleanup
Test entitlement revocation and the agreed package/data cleanup behavior without publishing credentials or private identifiers.
Output and failure rules
The fixture should perform a deterministic, product-specific action visible in the scene or output. Local and farm renders retain original files; browser screenshots are supplementary. The result declares whether it expects exact equality or a numerical/perceptual tolerance and publishes the comparison method.
A failed install, activation, dependency, render, or revocation step is retained. “Requires pinning” is a valid result when the product passes only on a particular Blender or product version. “Partial” is valid when a named feature passes and another does not. A badge must never collapse those outcomes into one green check.
Badge scope and expiry
A future badge must name or link to the exact product version, Blender patch, engine, device where relevant, fixture, date, and limitations. It expires when the seller changes the package, Blender version, license, activation path, or material dependencies. Retesting creates a new result while preserving prior history.
The result also needs a seller correction path. If a seller identifies an invalid method or publishes an update, the affected claim is reviewed, corrected, or withdrawn visibly.
What a render-tested badge should cover
| Criterion | Exact identity | Pass criterion | Failure visible | Status |
|---|---|---|---|---|
| Product package | Version and hash | Authorized package acquired | Yes | Pending |
| Blender runtime | Exact patch/build | Clean installation | Yes | Pending |
| Activation | Method and license scope | Required function executes | Yes | Pending |
| Dependency package | Manifest and warnings | Expected files present | Yes | Pending |
| Farm output | Original output hash or tolerance | Declared comparison passes | Yes | Pending |
| Revocation | Test timestamp and scope | Expected access removed | Yes | Pending |
Privacy and security
No test artifact may include customer files, private seller source beyond the authorized fixture, credentials, storage locations, internal identifiers, or raw entitlement records. Revocation and cleanup evidence must be redacted. Broader data-lifecycle claims remain withheld until the separate security publication gate is cleared.
Release gate
This page can become indexable only when one rights-cleared product completes the entire chain from entitlement through revocation, with manifests, hashes, sanitized logs, original outputs, limitations, reviewer, and correction path. Until then, “render-tested Market product” is a proposed evidence label, not a shipped promise.