It can compare a defined workflow
A controlled record can show what happened for named briefs, versions, settings and target conditions. Repeated attempts can expose variation and rejection frequency inside that scope.
A versioned, vendor-neutral method for testing exported AI 3D assets without turning selected renders into unsupported performance claims.

The G3D.AI evidence method compares complete production attempts under the same brief, time limit and acceptance gates. It retains failed runs, exported files and cleanup observations so a reader can see what was tested and what the result does not prove.
This page publishes the protocol and blank records. It does not report a winning tool, accepted-asset rate or cleanup-time result because no public test package has yet been attached. A future result must identify its tool version, date, settings, inputs, exports and limitations before it is described as a G3D.AI benchmark.
Protocol: published and versioned.
Available for teams to run locally.
None claimed yet.
Name the asset role, camera distance, scale, material needs, topology expectations, target engine and pass-or-fail gates before opening a generator.
Store the provider, product, model or feature version, date, account tier, settings, seed when exposed and applicable terms reference.
Keep the prompt or authorized inputs, raw preview, original export, failed exports and rejection reason. Do not preserve only the strongest candidate.
Record operator time for retries, repair, retopology, materials, rigging, import and approval. Test the accepted file in a representative engine scene.
One field cannot stand in for another. A fast generation may need long cleanup; an attractive preview may fail export; a technically valid file may still miss the art brief.
| Record group | Required evidence | Question it answers |
|---|---|---|
| Brief | Role, dimensions, camera, style, materials, engine and acceptance gates | Was every system asked to solve the same production task? |
| Generation | Tool and version, date, settings, seed, attempts, prompts or authorized inputs | Can the attempt be understood or repeated? |
| Export | Original files, formats, hierarchy, mesh count, materials, textures and warnings | Did the useful information survive outside the hosted preview? |
| Cleanup | Hands-on minutes, operations performed, regenerated attempts and rejection reasons | Did fast generation reduce total production labor? |
| Engine | Importer version and settings, validation scene, collision, LOD, material and target-device notes | Did the delivered asset perform its named job? |
| Rights | Input permission, applicable terms reference, operator, reviewer and final file hash | Can the technical decision be connected to its production history? |
These files contain no sample scores and make no product claim. Duplicate them for each attempt, keep the unedited raw files beside the record and add fields when the project needs stricter controls.
CSV fields for briefs, versions, attempts, exports, cleanup and acceptance.
Download CSV ↓A structured JSON record for one reviewed output and its production evidence.
Download JSON ↓The portable protocol, evidence rules and publication threshold.
Download Markdown ↓A controlled record can show what happened for named briefs, versions, settings and target conditions. Repeated attempts can expose variation and rejection frequency inside that scope.
Models, prices, terms and exporters change. Asset classes also fail differently. Conclusions must remain tied to the test date, sample and target pipeline.
Selected successes hide the cost of retries. A public comparison must report rejected and broken attempts or state clearly when evidence cannot be released.
For the complete scoring rationale, continue with the AI 3D tool benchmark guide. Build practical geometry and texture limits in the 3D asset production workbench.