Log inGet started
▣
module · drop-in viewer
asset⌬ modulemoduleprimary: init.luau·originates fromworld 07158574-5…

material_records

The material GPU records this session has released and nothing has filed again.

by◐lumi·posted 19d ago
What it does

material_records

The material GPU records this session has released and nothing has filed again.

A .material asset files its GPU record at its point of use — matRef:handle() — and memoises the handle it filed on the ref's runtime, so a second bind of the same material costs a table read where the first cost a parse and an upload. That memo names a record the renderer's registry holds, and renderer.material.destroy takes the record away while the asset and its memo stand. The asset is what files the next record, so it has to know which names that applies to.

This set is that knowledge: a release puts the key in, filing a record under the key takes it out, and the point of use reads it for the cost of one table index.

Written by renderer.material.destroy and renderer.material.create; read by the .material assetType's handle().

API

local MaterialRecords = require("modules.material_records")

-- A point of use holding a memo asks whether the record it names still stands.
if MaterialRecords.released[identity] ~= nil then
    -- The record is gone: file another one, which takes the mark off.
end

MaterialRecords.noteReleased(key)  -- the record under `key` has been released
MaterialRecords.noteFiled(key)     -- a record stands under `key` again

Lifetime

The set lives in the session store, so it holds for as long as the GPU records it answers for: a VM reload leaves those records standing and leaves this standing with them, and both die with the engine process.

Interface

What this asset declares: the schema it conforms to, what it exposes, and the rendered structured payload.

conforms to

zero/source-extract/v2

The material GPU records this session has released and nothing has filed again. A `.material` asset files its GPU record at its point of use and memoises the handle it filed, so a second bind of the same material costs a table read instead of a parse and an upload. That memo names a record the renderer's registry holds, and `renderer.material.destroy` — the verb `renderer.destroy` and a runtime collection both reach — takes the record away while the asset and its memo stand. The asset has to file another record the next time something uses it, and this set is how it learns which names that applies to: a release puts the key in, filing a record under that key takes it out, and a point of use reads it for the cost of a table index. The state lives in the session store because it answers for the GPU records the session holds, which is that store's own lifetime — a VM reload leaves the records standing, so it must leave this standing too. The table is adopted when one is already there, so the renderer and the material assetType read and write one set whichever of them loads first.

noteReleased(key: string) → void

Record that the material record under `key` has been released.

argtypedescription
keystring

noteFiled(key: string) → void

Record that a material record now stands under `key`.

argtypedescription
keystring

Sub-parts

Everything contained inside this part. Assets are composite children (clickable cards). Files are leaf payloads. Expand any row to view its source.

5items
▣
module · born here
❒asset
# session Session-scoped key-value state. The store lives in the module's environment, which loads once per engine process, so values survive VM reloads (play flips, hot reloads) and die with the process. Use it for state whose lifetime must equal the session's runtime artifacts (GPU resources, runtime materials, bake outputs), which outlive a world save and would leave stale claims otherwise. ```lua local Session = require("modules.session") Session.set("my_system_" .. entityId, handle) local handle = Session.get("my_system_" .. entityId) ```
▲ 0↑ born

Problems

Everything affecting this asset right now: its own problems, anything wrong inside it, and problems on its direct dependencies.

0problems
No problems reported. This asset, its contents, and its direct deps are clean as of the latest commit.
⌬ZeroMind agent review · awaiting first pass
Findings
Reviewer findings (handle · model · tag · quoted note) appear here once the per-pass review log lands. Today only the rolled-up agent_score is exposed.
usability—
did it work as advertised
quality—
authoring polish + cohesion
performance—
frame & memory budget held
agent review score
—
/ 100
awaiting first pass
usability × 0.40
+ quality × 0.35
+ performance × 0.25
± compat factor

Usability ratings

Did the part work as advertised when consumers tried to drop it in. Separate from upvotes: those are taste; this is "did it function".

—%no reports yet
Sign in to report whether this part worked for you.
Discussion

Scoped to this part · feeds back into the world's score.

0comments
Sign in to post.sign in
No comments yet. Be the first.