Public API and internal objects

window.editorAPI

window.editorAPI is the stable, officially supported interface for plugins. It provides operations for the interface, objects, projects, translations, HeadPaint, the environment, and selected animation settings.

const api = window.editorAPI;
const selected = api.getSelectedObjects();
console.log('Selected objects:', selected.length);

Run this snippet after the editor is ready. The existence of editorAPI does not mean that the GUI or scene is ready. For an installed plugin, bde:started marks the point at which it can start working with them.

A stable entry point does not turn returned objects into independent copies. For example, getSelectedObjects() returns objects from the scene itself. Accessing their internal fields requires an understanding of the object model and may carry separate restrictions.

window.editor

window.editor is the editor instance, with access to its internal subsystems. You can explore it and use it in your plugins, including when a feature does not yet have a public API method.

// Internal dependency: currentMode is not an editorAPI method.
console.log(window.editor.currentMode);

Methods, fields, and relationships within editor can change without compatibility guarantees. A plugin that uses them needs to be checked when BDEngine is updated. Mention such dependencies in the plugin description and keep access to the internal subsystem in one part of the code so it is easier to adapt.

The editorAPI.editor field also points to the internal editor instance. Accessing it this way does not change the guarantees: editorAPI.editor.gui is still an internal dependency.

THREE, GLTFExporter, Selectable, and gT

The editor exposes several global dependencies:

Access	Purpose
window.THREE	The Three.js version bundled with the editor.
window.THREE.GLTFExporter	The glTF exporter added to THREE; the loader does not create a separate global GLTFExporter.
window.Selectable	The base class for custom editor objects.
window.gT	Retrieves a translated string through the editor’s locale system.
window.libs.JSZip	The JSZip version bundled with the editor.

These dependencies are useful for extensions, but their availability does not mean the library versions or the entire internal object model are fixed forever. This is especially relevant when extending Selectable or working with Three.js resources. See Custom objects and global dependencies for contracts and limitations.

A public solution or an internal approach

First, look for the operation in the editorAPI reference. For example, editorAPI.add() creates a built-in display, and editorAPI.addButtonExportMenu() registers an export menu action.

If no suitable method exists, you can use editor or a custom object. Check the implementation: you need to know more than the name and parameters. Consider when the subsystem is ready, its return value, interface updates, action history, and resource cleanup. Do not substitute a guessed method with a similar name.

Check feature availability

Before registering a tool, check the specific method it depends on:

const api = window.editorAPI;
if (typeof api?.addButtonExportMenu !== 'function') {
  console.warn('[my-useful-plugin] This BDEngine version lacks export menu actions.');
  // Do not register the unavailable tool.
}

Make this check at the right point in the lifecycle. For example, editorAPI.headPaint is created during GUI initialization: its absence before bde:started does not prove that the version is incompatible.

The editor version helps reproduce an issue, while a method check lets you handle an unavailable feature clearly. Use both. The complete verification process is described in Compatibility and updates.