Model

Summary

Models are a very simple way to group parts together. Creating a model requires at least 2 parts selected, but otherwise the second part can be deleted. Parts in a model are not truly connected, but only grouped in the explorer. Models currently have no purpose other than organization.

A model with no children is still shown in the explorer, but does not exist in the world and has no transform controls.

The basic transform tools (Move, Rotate) work more or less as expected when used on a model, except for scaling which currently is not properly supported.

Properties

Properties of a Model, in the order they appear on Vortex Studio.

Properties
• Name: string
• Position: Vector3

Properties

Name

string

The name of the model, and its label in the explorer.

Position

Vector3

The position of the model, in World-space. A model’s position is automatically set to the mathematical average of all its children’s positions. (See Images)

Images

Testing Notes

In Vortex Studio 0.3.4, a detached Model exposes the generic instance surface, including hierarchy and attribute methods, but has no readable Position, PrimaryPart, or WorldPivot property. This is identical in both Script and LocalScript.

Setting a temporary Part’s Parent to a detached Model does not establish an observable hierarchy: parent equality is false, FindFirstChild returns nil, GetChildren() returns an empty table, and WaitForChild does not return the temporary Part.

GetPivot, PivotTo, GetPrimaryPartCFrame, and SetPrimaryPartCFrame are also unavailable (nil) in both contexts. Assigning Model.PrimaryPart is rejected as a non-settable property.

In 0.3.4, the live Character Model is a special case. In both a LocalScript and a confirmed server Script, it exposes ClassName, Name, and Position, plus direct Humanoid and HumanoidRootPart members; Parent reads as nil. It exposes the tested generic Instance method surface and a connectable Changed signal, but its tested hierarchy/lifecycle signals are unavailable. Like a detached Model, its pivot and primary-part APIs remain unavailable.

The live Character Model is also the verified write-only visual rotation target: character.Orientation = Vector3.new(0, 90, 0) visibly turns the character in a server Script while the field remains nil on readback. See Character: Write-only visual rotation.

Character:FindFirstChild("Humanoid") and Character:FindFirstChild("HumanoidRootPart") return the same direct members. However, Character:GetChildren() returns one unnamed generic Instance, not a reliable inventory of those two values or of the tested standard R6/R15 body parts. Character attribute values replicate in both directions between a server Script and the owning LocalScript; see the Attributes guide.

Transient Character visual Scene

The unnamed child returned by Character:GetChildren() can expose a Scene member after the visual character finishes loading. This is a separate, transient render hierarchy; it is not part of the stable public Character projection above. Code that needs it must poll for the route and re-resolve it after every replacement:

local function getCharacterScene(character)
    for _, wrapper in ipairs(character:GetChildren()) do
        local ok, scene = pcall(function() return wrapper.Scene end)
        if ok and scene then
            return scene
        end
    end
end

After the Scene resolves, its primary rig path is also directly indexable:

local armature = scene["Armature.001"]
local visualRoot = armature.HumanoidRootPart
local torso = visualRoot.Torso
local leftArm = torso["Left Arm"]

The bracket form is required for the dot-containing Armature.001 name and for limb names containing spaces. This inner visual root is distinct from the public Character.HumanoidRootPart Part projection.

The following is the observed character projection after the visual Scene and the test avatar’s attachments finished loading. Humanoid and the outer HumanoidRootPart are the stable direct Character members; the tree below the anonymous wrapper is the transient visual projection:

Character (Model)
├── Humanoid                              public direct member
├── HumanoidRootPart (Part projection)    public direct member
└── <unnamed wrapper>                      Character:GetChildren()[1]
    └── Scene
        ├── Armature.001
        │   └── HumanoidRootPart           visual generic Instance
        │       └── Torso
        │           ├── Right Arm
        │           ├── Left Arm
        │           ├── Right Leg
        │           ├── Left Leg
        │           ├── <unnamed attachment>
        │           │   └── Scene
        │           │       └── Spike Sword
        │           │           └── Spike Sword.FBXASC051SG
        │           ├── <unnamed attachment>
        │           │   └── Scene
        │           │       └── Angel wings
        │           │           └── Angel wings.initialShadingGroup.002
        │           ├── <unnamed attachment>
        │           │   └── Scene
        │           │       └── Body.003
        │           │           └── R7Body.028.Material.034
        │           └── Head
        │               ├── <unnamed attachment>
        │               │   └── Scene
        │               │       └── PaperPlane Hat
        │               │           └── PaperPlane Hat.initialShadingGroup.011
        │               └── <unnamed attachment>
        │                   └── Scene
        │                       └── 3.002
        │                           └── 3.002.Hair
        └── Body
            └── R7Body.Material.*          six observed render-material nodes

The named accessory and material leaves are a concrete test-avatar capture, not a guaranteed hierarchy. The repeated unnamed attachment nodes are the stable structural pattern: they are direct children of Torso or Head, and their nested Scene contains the rendered attachment content.

All of these visual nodes report ClassName == "Instance". The observed surface is the generic hierarchy and attribute method set, plus readable Name, Parent, Position, and Size. Changed, Touched, and TouchEnded can be connected, but no delivery was observed while a limb’s Position updated. The live limb transforms are therefore readable render state, not a replacement for the public HumanoidRootPart projection.

Visual rig and attachment nodes also accept numeric Transparency writes in both a LocalScript and a server Script. An initially unset value reads as nil; after node.Transparency = 0.5 or 0, it reads back as that numeric value. The tested torso and leg did not visibly change when the field was written, so this is currently stored projection state rather than a confirmed render-opacity control. In contrast, the public Character.HumanoidRootPart rejects the same write in both contexts.

The hierarchy changes during loading. In one verified run, unnamed attachment nodes appeared below Torso and Head, then each exposed a nested Scene. Their visual content included Angel wings, Spike Sword, hair, and a PaperPlane Hat. Those names are avatar-specific examples, not guaranteed children. Later, Vortex replaced the complete Scene and Armature.001 with a fresh base hierarchy; a direct Cube node also appeared on the replacement Scene in the observed run. Retain no visual-node reference across frames or loading phases—reacquire Scene, Armature.001, and any limb or attachment from the current Character hierarchy.

Replacement destroys the old visual nodes rather than simply detaching them. After a replacement, trying to reparent a stored accessory node into the new visual rig failed with Instance no longer exists. A script can restore a node that was manually reparented during its current Scene generation, but it cannot carry that node across Vortex’s Scene rebuild.

Reparenting Right Arm and Left Arm from this visual hierarchy was observed to hide the corresponding rendered arms in both a LocalScript and a server Script. This is an implementation detail rather than a stable character API; test it against the target avatar and expect visual Scene replacements to undo the change.