Extending the Editor Without Breaking the Model
Pascal Editor's plugin system tests whether the shared scene model is a real boundary or merely a convention followed by the built-in code. The specific question here is where a new building concept—such as a landscape object, a specialized fixture, or an analysis node—can enter Pascal without creating a private scene format. Understanding that boundary lets a reader distinguish a genuine node extension from code that only adds a visual widget around the existing editor.
The answer is unusually direct: built-in and external node packs use the same plugin manifest and registry contract. A plugin is not asked to imitate the built-in package through undocumented hooks. It contributes a declared node kind, and the host decides how that kind participates in the shared model, rendering, floor plan, tools, and project lifecycle.
The same contract for built-in and external kinds
A plugin manifest has a globally unique ID, an API version, and an optional collection of node definitions. The ID prevents two extensions from silently claiming the same identity. The API version makes compatibility explicit: the host can reject a plugin whose contract version it does not understand instead of allowing it to fail later through an unrelated renderer or panel error.
The important architectural choice is that the built-in nodes use this shape too. A built-in wall, a catalog object, or a domain-specific plugin kind is registered as a definition that the same registry can inspect. There is no separate “internal” format with privileges that an external author must reverse-engineer. This parity does not make every plugin automatically correct, but it gives every plugin the same places to declare what it is and how it behaves.
The new kind still begins with semantic data. Its schema defines the fields that describe the object, its defaults define what a new instance means before a user fills every field, and its capabilities state which generic interactions apply. A node can declare that it is selectable, movable, duplicable, hostable, floor-placed, paintable, or otherwise related to the editor's common operations. Relations tell the framework which other nodes it depends on or can host.
That order matters. If an author begins with a custom mesh and adds a label that says “tree” or “duct,” the result may look right but has no reliable place in the scene graph. A real node kind can be selected by identity, saved with its parameters, included in a floor-plan decision, queried by an agent, and validated through the same document boundary as existing architectural objects.
A node definition is a bundle of explicit decisions
Pascal's NodeDefinition is best understood as a bundle of decisions rather than a single renderer registration. The definition can supply a pure geometry builder, a custom React renderer, a per-frame system, or a combination of those. The choice follows the kind's behavior.
A parametric object whose meshes are a pure function of its fields can use a geometry builder. The generic renderer provides a registered group, and the generic geometry system rebuilds its children when the node becomes dirty. A GLB-backed object may need a custom renderer because it loads a model or uses React Three Fiber composition.