Skip to content

Latest commit

 

History

History
21 lines (13 loc) · 4.28 KB

scenes.md

File metadata and controls

21 lines (13 loc) · 4.28 KB

Mesh Assets and Rendering Scenes

RenderScene owns retained presentation records. Shared MeshAsset handles contain geometry and each material slot's default material; MeshInstances carry transforms, tint, visibility, material overrides, and shadow policy. Games own the simulation these records represent. The renderer borrows the scene and never updates gameplay.

Use compile_form_mesh, form_mesh_asset, or FormAssetLibrary for procedural assets, MeshAsset::new or MeshAsset::with_materials for meshes a game builds, and MeshAsset::from_document for saved MeshDocuments with textured materials. Meshes and materials describes the records and shading models. The form-viewer example demonstrates the integration. A mesh uploads on first use, and its GPU copy is released when no live instance or asset handle needs it.

Transforms and Collections

Positions use Y-up world coordinates. Rotations are XYZ Euler radians applied X, then Y, then Z; scale precedes rotation and translation. RenderScene::insert_node groups mesh and terrain instances through parent transforms and visibility. Presentation hierarchy does not imply a gameplay entity hierarchy.

MeshCollection synchronizes keyed simulation records into stable instances. Keep keys stable across removal/reordering, and prune absent records through the collection's update boundary. Removing presentation never destroys a simulation entity.

Frame Inputs

The renderer uses one camera and frame state for culling, shadows, lighting, scene attachments, and display processing. Each material's shading model (lit, layered, unlit, or a game's own) shades its slots; see materials. Transparent geometry uses depth testing without depth writes, and every transparent element of a frame (blended meshes, transient triangles, and colored or textured draws such as particles) sorts back to front in one queue. FrameInputs can also borrow environment state, a directional key light, any number of point lights (the renderer ranks them and draws the 32 that light the view most), and image lighting.

LevelScene translates authored render and light records into presentation, and PostProcessVolumes resolves postProcess volumes at the view point (see postprocessing). AssetScene adds FORM assets and colored/textured JOYFX effects; its staged prepare and commit retain accepted presentation on failure. See particles.

FORM Assets in Levels

A render component with a .form script or .forminst instance asset draws that FORM asset with its parameters (and, for instances, an optional named variant); overrides layer as the instance's, then the variant's, then the component's. FormAssetLibrary::resolve_asset reads the instance's referenced script and every use module through the reader it is given, caches by all of their text, and returns a FormAsset: the mesh and its placements, the isolated points the script tagged with attributes (for example addPoint(sites, position, {kind: "tree", object: "assets/objects/tree.joyobject"})). Placements whose object attribute names a template become entities of their own (<parent id>/<index>, linked to the template, oriented by optional rotation and scale point attributes, carrying the point's attributes as a formPlacement component override); one level deep, at most MAXIMUM_OBJECT_PLACEMENTS per asset. Joy Editor shows them as soon as the asset is placed. See FORM.

Games build their world from the same documents: AssetScene::prepare_level(&level, read) returns the level ready to run (objects resolved, placements expanded) plus the presentation stage. Hand the level to LevelRuntime, commit the stage, and present each frame with AssetScene::follow, which draws runtime entities with the prepared assets. Authored placements follow their parent through AssetScene::update in editors; under a runtime they are simulated entities. Read asset text through GameAssets so native development builds hot reload it.

Use the rendering integration tests in tests/integration/ and browser captures for the affected projects. Inspect shadows, transparency, scene effects, and high-density scaling on every supported backend affected by the change.