Model Building and Refinement Handbook

Guidance updated October 7, 2026. Validate each exported model and use the controls available in your app version.

Prepare models for VR Build Kit using your own AI assistant and modeling tools. For account access, privacy, upload, and headset workflows, read Agents MD. These instructions do not provide automatic project control.

Contents#

1. Use your own AI and modeling tools
2. Establish a useful brief
3. Export a compatible model
4. Preserve components and names
5. Get scale and architecture right
6. Optimize and refine without losing intent
7. Validate and deliver
8. Copyable prompt recipes

Use your own AI and modeling tools#

Bring your own AI workflow is useful on every VR Build Kit plan, including Free and Pro. Your assistant can interpret a plan, generate modeling code, inspect a GLB, or revise a model. Uploading its output is separate from VR Build Kit generation.

Work performed by an external assistant does not consume VR Build Kit generation credits. Your AI provider's subscription, tool availability, execution limits, and possible charges still apply. An assistant with image understanding may interpret a drawing without having a 3-D modeling environment. An assistant that writes a Blender script may not be able to run Blender or attach the resulting GLB.

Establish the assistant's capabilities first: reference reading, model inspection, tool execution, GLB export, measurement, and file delivery. If execution is unavailable, request a runnable script and next steps, labeled GLB not generated yet. An image, script, or renamed file is not a finished GLB.

VR Build Kit hosted generation or refinement may be an optional continuation where the current product and your account support it. Its availability, allowances, and charges are separate from external work. An eligible paid plan does not require you to use hosted generation; Free does not make paid hosted work free.

Establish a useful brief#

Start with the desired outcome and supplied evidence. For a floor plan, a useful first choice is shell only, shell with simple fixtures, or furnished model. A shell normally means floors, walls, and requested openings. It does not automatically include furniture, cabinets, landscaping, ceilings, or a roof.

The assistant should extract known dimensions before asking questions. Ask only about missing information that changes the result materially: an unreadable scale, conflicting dimensions, required wall height, or whether a line represents a wall or opening. Offer a small choice with a disclosed default for optional detail. Do not turn every modeling decision into a questionnaire.

Keep a short brief containing:

• Purpose, model scope, and intended inspection distance.
• Supplied dimensions, original units, and exactly what each measurement spans.
• Required components and the parts the user expects to move or recolor separately.
• Reference files and which facts came from each reference.
• Explicit assumptions and unresolved questions.
• The current upload limit in bytes and available project storage, when obtainable.

Retrieve limits from the current signed-in account information or upload interface before finalizing an export. Record the source and retrieval date. Do not substitute a remembered plan table, confuse total storage with the per-file limit, or invent a triangle allowance. If the limit is unavailable, continue preparing a useful modest model, mark size compliance unverified, and request the displayed value before import. Do not label an unchecked file as fitting the Free allowance.

Export a compatible model#

The dependable target is a static glTF 2.0 binary file with the .glb extension, containing its geometry and image resources. Convert an OBJ, FBX, SketchUp, USDZ, or other source through an appropriate modeling/export tool. Renaming its extension does not convert it.

Use these export rules:

Standard metallic-roughness preparation can use base color, metallic/roughness, normal, and occlusion inputs. Opaque, masked, and blended alpha modes are supported, but transparency still needs visual inspection. Unlit materials and texture transforms are supported options. Emissive image textures are outside this handbook's compatible editing target; use a supported material treatment and disclose any appearance compromise. Do not assume transmission, clearcoat, specialized glass, or other optional material extensions will reproduce their source appearance merely because a file uploads.

Do not “repair” compatibility by deleting an extension declaration while leaving geometry or textures that depend on it. Likewise, do not convert every supplied texture to a small lossy JPEG by default. Preserve a compatible, good-quality source. When conversion or downsampling is necessary, retain the original, change only what is needed, and compare the result.

Passing the required-extension check is one compatibility check; it does not prove the whole file is valid or visually correct.

Preserve components and names#

A component boundary comes from the model's structure. If a door and its frame need separate manipulation, export them as separate mesh-bearing glTF nodes. Two disconnected pieces inside one mesh-bearing node remain one component for this purpose. Two material slots on one object also do not create separate component identities.

Use names that communicate purpose and location: Wall_North, Door_Entry, Window_LivingRoom_01, or Drawer_Top_Handle. Names should be unique within an asset and stable across revisions. Avoid blank names and autogenerated labels that do not describe the part. Duplicate names can make selection and refinement ambiguous even when the file loads.

A named parent with geometry beneath it can represent a useful assembly:

Kitchen_Cabinet_01
├── Cabinet_Body
├── Door_Left
├── Door_Right
└── Countertop

Keep this structure shallow. Extra wrapper groups create extra selection levels. Verify the exported node tree: naming a Blender collection alone is not proof that the intended grouping appears in the GLB. A continuous simple object may appropriately have one component; every triangle does not need a name.

In the headset, the usual top-level selection can choose an assembly, and opening it exposes its children. The selection-depth setting can support deeper selection. The hierarchy provides a readable way to find parts. Meaningful names do not by themselves guarantee that the headset supports a spoken command targeting a part by name.

Names are human-readable labels, not a substitute for durable identity. An external workflow should retain its own component inventory and record mappings when a part is renamed, split, merged, added, or removed. Do not invent a required VR Build Kit custom ID field inside the GLB. Preserve any established source identities rather than regenerating them on every edit.

Material identity is separate: several independently selectable walls may share one finish. Reusing that material does not require joining those walls into one object.

Get scale and architecture right#

Explicit measurements take precedence over pixel estimates. Record their endpoints and scope: an internal room width, external building width, clear opening, and overall object width are different constraints. Convert units accurately; one foot is exactly 0.3048 meters. Do not normalize a model to an arbitrary unit cube or resize it to improve a preview.

Check dimensions after export and after all node transforms. Measure the intended surfaces or named components, not necessarily the full model bounds. A dimension label, door swing, or outlying reference marker can enlarge those bounds without changing the room itself. Distinguish small numerical export error from uncertainty in reading a drawing; an inferred dimension does not become exact because software prints many decimal places.

For a simple room, place the finished floor at the model's floor datum: Blender Z=0 normally becomes exported glTF Y=0. Default floors should be flat surfaces rather than raised blocks. Do not use a zero-scale box to imitate a plane. Preserve explicitly requested slab thickness, steps, slopes, and levels, and record their relationship to the finished floor. Actual alignment to the user's calibrated physical floor must be checked in the headset.

Continuous walls should have uninterrupted surfaces around openings. Avoid accidental gaps, bevel grooves, shading seams, duplicate faces, and coplanar overlaps. Preserve separate logical walls without showing the construction fragments used to make them. Smooth walls do not mean rounding every architectural corner.

Inspect exported walls, floors, openings, transparency, and materials while moving the view, including close and grazing views. A still image can hide flicker and overlap problems.

Optimize and refine without losing intent#

Inspect first: file bytes, triangles, mesh-bearing nodes, materials, image dimensions, and hierarchy. These are measurements, not invented product limits. A small file can still render poorly; fitting the upload limit is not a performance guarantee.

Optimize the expensive or unnecessary content actually present. Remove export staging, hidden duplicates, excessive subdivisions, and detail that does not serve the brief. Reuse compatible materials and image resources. Reduce texture size or geometric detail selectively, then inspect the change. Preserve hard dimensions, openings, silhouette, useful pivots, UVs, and logical component boundaries. Do not combine an entire building into one object solely to lower node count.

For refinement, inspect the current accepted GLB and editable source before building a replacement. State the intended changes and protected properties. A finish change should preserve geometry and dimensions. Moving a fixture should preserve unrelated walls and openings. Stable names make it easier to compare the intended part across versions.

Keep the original, the accepted baseline, and each proposed replacement in the user's chosen file storage. Maintain a brief and change log alongside them. Do not assume VR Build Kit retains unlimited source files or version history. Replacement may be irreversible. Keep a verified copy of the accepted model and confirm the replacement before relying on it. Do not assume a failed replacement automatically restores the accepted model. Website originals and headset-saved project content can differ; verify which content the headset will open before declaring a replacement ready.

Before updating through supported product controls, verify the intended project, space, variation, and newest content. If the content has changed since you inspected it, review those changes before proceeding so you do not overwrite newer work. These instructions do not themselves provide automatic project access.

Validate and deliver#

Use separate labels for separate evidence:

Deliver the actual GLB, editable source or runnable generation script when available, a preview, and a short report. Include exact file bytes, component inventory, measured dimensions, assumptions, checks performed, and checks still pending. Compare bytes against the retrieved limit and check storage separately. Do not describe a screenshot review as a headset test.

The GLB prepares model content. It does not itself activate the Dimensions tool or configure application settings. A location, date, and time recorded in the brief do not establish that the requested sunlight has been applied. Use only currently available controls, verify the result, and report any remaining manual setup as described in the Agent Guide.

Copyable prompt recipes#

Replace bracketed user inputs. These recipes assume the assistant can inspect files; it should disclose unavailable execution or export tools immediately. Each recipe includes the critical export rules so it remains useful when copied alone. Use your own tools first; copying a recipe does not authorize VR Build Kit hosted generation. Read https://vrbuildkit.com/agents.md for current account and workflow guidance, and recheck this handbook before a new export.

Recipe 1 Build a basic shell from a floor plan#

Use my own assistant and modeling tools; do not start VR Build Kit hosted generation.
Create a basic shell for VR Build Kit from [attached floor plan]. Extract the
supplied dimensions and units first. Ask only about essential conflicts or
missing scale; disclose defaults for unspecified wall height or thickness.
Include floors, walls, and shown openings. Do not add furnishings unless asked.

Retrieve my current upload byte limit and available storage from the account
information I provide or can access. Mark unknown limits as unverified.
Produce an actual static glTF 2.0 GLB in meters, Y-up, triangle geometry,
compression off, with embedded PNG/JPEG images only if needed. Require no
extensions except KHR_materials_unlit or KHR_texture_transform if used.
Use standard metallic-roughness materials and TEXCOORD_0; no emissive textures.
Give each logical wall and floor its own stable, unique named mesh node.
Preserve useful assemblies. Keep the finished-floor datum at Y=0 and preserve
specified levels. Avoid seams, duplicate faces, and raised default slabs.
Remeasure exported openings and room dimensions. Deliver GLB, editable source
or runnable script, preview, exact bytes, component list, assumptions, and
validation report. Clearly distinguish file checks from headset testing.
If you cannot execute the exporter and return a GLB, label the result
GLB not generated yet and provide the runnable script or concrete manual step.

Recipe 2 Build an object with useful components#

Use my own assistant and modeling tools; do not start VR Build Kit hosted generation.
Build [object] for VR Build Kit using [references and dimensions]. Make a short
component plan first. Preserve specified measurements and identify assumptions.
Separate useful movable/recolorable parts into unique named mesh-bearing nodes;
use shallow parent assemblies and retain meaningful pivots. Do not use material
slots as component boundaries. For a specific product, verify its model and
dimensions and distinguish imported, adapted, and newly modeled content.

Export an actual static glTF 2.0 GLB, meter scale, Y-up, triangles, compression
off, resources embedded. Use PNG/JPEG and standard metallic-roughness materials
on TEXCOORD_0, without emissive textures. Require only KHR_materials_unlit or
KHR_texture_transform if needed. Retrieve the current account byte limit;
optimize without joining useful parts or changing dimensions. Reinspect the
export. Supply the GLB, source/script, preview, component inventory, measured
size, exact bytes, and remaining checks. Say explicitly if you cannot run export.

Recipe 3 Refine the current accepted model#

Use my own assistant and modeling tools; do not start VR Build Kit hosted generation.
Inspect [accepted GLB and source] and change [requested changes]. Preserve
unrelated geometry, dimensions, names, hierarchy, pivots, materials, and UVs.
Do not rebuild unaffected parts. Record the baseline file and explain any
necessary rename, split, or merge. Keep the accepted baseline separately.

Deliver a proposed replacement as a static meter-scale Y-up glTF 2.0 GLB with
triangle geometry, compression off, embedded PNG/JPEG resources, and standard
metallic-roughness materials on TEXCOORD_0 without emissive textures. Required
extensions may contain only KHR_materials_unlit and KHR_texture_transform.
Keep separate, uniquely named mesh nodes for independently editable parts.
Compare the export with the baseline: requested changes, protected dimensions,
component inventory, appearance, and bytes against the retrieved account limit.
Return the GLB, editable source/script, before/after preview, and change report.
Do not claim you uploaded it or changed the headset project unless verified.
If you cannot execute the exporter and return a GLB, label the replacement
GLB not generated yet and provide the runnable script or concrete manual step.

Recipe 4 Produce three variations from one shared brief#

Use my own assistant and modeling tools; do not start VR Build Kit hosted generation.
Using [shared brief, references, and accepted baseline], create three variations
that differ only in [allowed differences]. Keep the same protected dimensions,
floor datum, coordinate frame, and names for corresponding components. Record
which parts were added or removed. Ask one concise question only if the allowed
differences are unclear; otherwise propose three meaningful options and proceed.

Each output must be an actual static glTF 2.0 GLB: meters, Y-up, triangles,
compression off, embedded PNG/JPEG resources, standard metallic-roughness
materials using TEXCOORD_0, no emissive textures. Require only
KHR_materials_unlit or KHR_texture_transform when needed. Preserve separately
named mesh nodes and shallow assemblies. Retrieve current upload/storage limits
and check each file separately. Provide three GLBs, editable sources/scripts,
matched-view previews, and a comparison of changes, dimensions, components,
bytes, and unverified checks. Check variation capacity within the intended space,
not just project capacity. Retaining an original plus three alternatives may
need four variations. Do not assume my account has that capacity.
If you cannot execute the exporter and return GLBs, identify which files are
not generated yet and provide runnable scripts or concrete manual steps.

Recipe 5 Repair from a measured validation report#

Use my own assistant and modeling tools; do not start VR Build Kit hosted generation.
Inspect [GLB, source, and measured failure report]. Reproduce each reported
failure before editing. Repair [listed failures] while preserving all passing
dimensions, named components, hierarchy, materials, and UVs unless a specific
repair requires a documented change. Do not hide scale errors by resizing the
entire asset or remove extension declarations without converting dependencies.

Re-export a static glTF 2.0 GLB in meters, Y-up, triangle geometry, compression
off, embedded PNG/JPEG resources, standard metallic-roughness materials on
TEXCOORD_0, no emissive textures. Require only KHR_materials_unlit or
KHR_texture_transform if used. Preserve separately named editable mesh nodes.
Repeat failed checks and relevant regression checks on the exported file.
Compare exact bytes with the retrieved upload limit. Deliver the repaired GLB,
source/script, before/after measurements, preview, and unresolved findings.
Keep the original and accepted versions; do not claim device acceptance without
testing the headset.
If you cannot execute the exporter and return a GLB, label the repaired file
GLB not generated yet and provide the runnable script or concrete manual step.

Recipe 6 Prepare a portable handoff for optional hosted continuation#

Package [current accepted model] for possible continuation in VR Build Kit.
First verify that the currently available hosted workflow accepts this kind of
existing-model refinement, and explain its separate account allowance or cost.
Prepare the package without starting paid planning or generation. Paid work
requires my explicit authorization of its scope and maximum cost.
If unsupported, provide the portable package without claiming an automatic handoff.

Keep the accepted source unchanged. If conversion is required, make and identify
a separate compatible copy and disclose any appearance changes. Include a
static glTF 2.0 GLB in meters, Y-up, triangle geometry,
compression off, embedded PNG/JPEG resources, standard metallic-roughness
materials on TEXCOORD_0 without emissive textures. Required extensions may be
only KHR_materials_unlit and KHR_texture_transform. Preserve named mesh nodes
and useful assemblies. Include editable source or runnable script, references,
brief, component inventory, dimensions, assumptions, and validation report.
Record exactly which file is accepted and the requested next changes. Retrieve
current upload/storage limits and report exact bytes. Keep a user-owned copy;
do not assume retained server history. Report what was actually submitted and
accepted only if a supported submission was performed and verified.
If a required conversion cannot be executed, return the unchanged accepted
file and label the compatible replacement GLB not generated yet, with the
runnable script or concrete manual step needed to finish it.

Final handoff check#

Deliver a real file, known scale, understandable components, and test results. Name missing checks and the next concrete step. Keep the source and accepted baseline available for continuation.