What lands in a Roblox export, and what your scripts can reach

Export to Roblox writes one `.rbxmx` model file. Drag it into Studio, or use Insert, then Model from File. Inside it are three things: a `Root` part, a `GeometryData` module holding the baked vertex data, and a `Runtime` script that builds the geometry when the game starts and drives it every frame.

Nothing in the file is a mesh asset. There is no upload, no moderation wait and no asset id. The geometry is constructed on the player's machine from the baked data.

Finding the parts by name

Every set the graph produces is named after the node's label, with anything that is not a letter or digit stripped. A node labelled "Wall Shards" lands as `WallShards`. Two nodes with the same label get a number: `Shards` and `Shards2`.

Where a set sits depends on what it is. A single static mesh is a MeshPart directly on the model, named `<SetName>`. A fractured object is N MeshParts on the model, `<SetName>_1` through `<SetName>_N`. Particles, curve instances and grids each sit inside a Folder named after the set, with the parts inside. So `model:GetChildren()` finds static and shard sets, and a pooled set is one level down: read the Folder by name.

Match on the exact name or on `<SetName>_<digits>`, not on a prefix.

The attributes your game writes

Every exposed knob in the graph becomes an Attribute on the model, read live every frame:

```lua model:SetAttribute("Compare_Threshold", 2) ```

The defaults ship in the file and the runtime only fills in attributes that are missing, so a value you set in Studio wins.

Four attributes ship on every ordinary export. `Animation_Enabled` decides whether the clock advances. `Animation_FPS` is the playback rate. `Animation_Loop` is `"repeat"`, `"pingpong"` or `"once"`. `Model_Scale` scales the geometry, the motion and every distance threshold together, so an asset made at one size works at another. A staged export ships only `Model_Scale` and `Stage_Value`, and your code owns the clock.

Distance-based nodes also ship an `ObjectValue` named `<Name>_Target`. Drop any `BasePart`, `Model` or `Attachment` into its `.Value` and the asset reacts to it.

Two things to know before you script against it

The runtime is a client script. Each player's client builds and animates its own copy, so a server script cannot see the built parts; it sees `Root`, `GeometryData` and `Runtime`. Attributes replicate from the server to every client, so setting one on the server changes what every player sees. Setting one on a client changes it for that player only.

The clock is per client too. It starts when that player's script starts, so a player who joins later sees the animation from its beginning. The shape is identical for everyone, because the random numbers are seeded and the maths is the same on every client.

Pools are fixed at build time. A particle or curve set never grows or shrinks while the game runs, and a part you destroy stays destroyed.

Appearance

Uniform sets reapply their material only when the graph's colour, material, fade or reflectance changes, so a Transparency you set by hand is kept until the graph changes it. Per-instance sets write Color and Transparency every frame and will overwrite yours.

A part has no emissive channel, so a glowing material tints the part colour toward the emissive colour and switches to Neon at higher intensity. Glass on a single part stays real refractive Glass; on a multi-part set it becomes smooth plastic, because Roblox Glass does not render anything transparent behind it.