원클릭으로 Manus에서 모든 스킬 실행

$pwd:

cesium-errors-memory

Name: Cesium Errors Memory
Author: Impertio-Studio

// Use when a CesiumJS app's memory keeps growing, the browser tab slows down or crashes after running a while, or the console reports "Too many active WebGL contexts" or "DeveloperError: This object was destroyed". Covers WebGL resource leaks from missing destroy() calls, teardown ordering, reusing primitives after destruction, entity-removal memory retention, lost-reference bugs that only look like leaks, and exhaustion of the browser 16-context WebGL budget by single-page-app routing or React re-mounts. Keywords: memory leak, heap grows, tab crash, out of memory, browser freezes, app slow over time, WebGL context lost, too many active WebGL contexts, This object was destroyed, DeveloperError, destroy, isDestroyed, PrimitiveCollection, destroyPrimitives, viewer.destroy, how do I clean up a Cesium viewer, why does my Cesium app leak memory.

Manus에서 실행

$ git log --oneline --stat

stars:1

forks:0

updated:2026년 5월 20일 07:37

파일 탐색기

4 개 파일

SKILL.md

readonly

related-skills.json

같은 저장소

cesium-agents-scene-architect.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when starting a new CesiumJS application or feature and deciding how to structure the scene: which viewer class, which imagery and terrain, how to represent a dataset, and whether to enable on-demand rendering. Prevents the wrong-API-tier choice (Entity where 3D Tiles is needed, or the reverse), the continuous-render battery drain, and missing-token blank globes. Orchestrates the CesiumJS skill set into one setup decision path. Keywords: CesiumJS architecture, how do I structure a Cesium app, which viewer, Viewer or CesiumWidget, Entity or Primitive or 3D Tiles, choose imagery provider, choose terrain provider, requestRenderMode, scene setup decision, how do I display my data in Cesium, what API should I use, getting started Cesium scene, plan a Cesium scene.

2026-05-201

cesium-agents-skill-validator.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when CesiumJS code has just been generated or reviewed and must be checked before it is called done, to catch deprecated APIs and common defects, or when auditing CesiumJS code from an older source. Detects the removed synchronous patterns (readyPromise, the url constructor option, ModelExperimental, defaultValue, new on a Cartesian factory), WebGPU assumptions, missing ion tokens, missing destroy() calls, and coordinate-type mistakes. Runs a deterministic checklist and routes each failure to the skill that fixes it. Keywords: validate CesiumJS code, review Cesium code, is this Cesium code correct, deprecated CesiumJS API, readyPromise, ModelExperimental, defaultValue removed, check before commit, CesiumJS code quality, lint Cesium, did I use the right API, audit Cesium scene, why might this code fail.

2026-05-201

cesium-errors-coordinates.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when CesiumJS geometry renders in the wrong place, falls through the terrain, sits at the center of the Earth, or never appears, and when position values come back as NaN. Prevents the radians-versus-degrees mistake, the Cartographic-versus-Cartesian3 mixup, the longitude and latitude swap, the GeoJSON ground-clamp surprise, and terrain-clamping before terrain has loaded. Covers Cartesian3, Cartographic, the fromDegrees factories, HeightReference, HeadingPitchRoll conventions, and terrain height sampling. Keywords: CesiumJS coordinates, NaN position, entity not showing, model wrong place, geometry at center of earth, off the globe, radians degrees, longitude latitude swapped, Cartographic Cartesian3, fromDegrees, fromRadians, clampToGround, sampleTerrainMostDetailed, HeightReference, HeadingPitchRoll, heading pitch roll wrong, why is my point underground, how do I place something on terrain, position is NaN.

2026-05-201

cesium-errors-rendering.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when a CesiumJS globe renders blank, black, white, or frozen, when the canvas shows nothing, when the WebGL context is lost, or when a render-loop error panel covers the canvas. Prevents the blank-globe trap caused by an unset CESIUM_BASE_URL, a missing or invalid Cesium ion token, or an omitted bundler asset-copy step. Covers the renderError event, WebGL context-loss recovery, the 16-context budget, and missing imagery or terrain. Keywords: blank globe, black screen, white screen, nothing renders, globe not showing, CESIUM_BASE_URL, CONTEXT_LOST_WEBGL, renderError, rethrowRenderErrors, Ion.defaultAccessToken, HTTP 401, webglcontextlost, too many active WebGL contexts, no imagery, no terrain, how do I fix a blank Cesium globe.

2026-05-201

cesium-errors-tileset.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when a Cesium3DTileset does not load or render: the console floods with CORS errors, the network tab shows 401 or 403, readyPromise is undefined, fromUrl resolves but nothing appears, the tileset has holes, or fromUrl rejects with a RuntimeError. Covers CORS and file protocol failures, ion and Google authentication, the removed synchronous readyPromise construction, invisible tilesets, individual tile failures, and unhandled promise rejections. Keywords: Cesium3DTileset, fromUrl, fromIonAssetId, tileset not loading, 3D Tiles not showing, CORS error, blocked by CORS policy, file protocol CORS, 401 tileset, 403 Forbidden, tiles missing, holes in tileset, tileFailed, readyPromise is undefined, RuntimeError, unhandled promise rejection, GoogleMaps defaultApiKey, Ion.defaultAccessToken, why is my tileset blank, how do I load 3D Tiles, how do I fix a CORS error.

2026-05-201

cesium-impl-aec-georef.md

from "Impertio-Studio/CesiumJS-Claude-Skill-Package"

Use when placing a BIM model, CAD model, IFC export, or city model into a CesiumJS globe at its real geographic location, and the model renders at the center of the Earth, sits at the wrong place, floats above or sinks below terrain, or faces the wrong direction. Prevents the identity-modelMatrix mistake (a model with no transform draws in raw ECEF coordinates), the double-transform mistake (re-placing an already-georeferenced ion tileset), the radians-versus-degrees HeadingPitchRoll mistake, and the conversion-pipeline-is-an-API mistake. Separates the official CesiumJS georeferencing API (Transforms, Matrix4, HeadingPitchRoll, modelMatrix) from the external CityGML and IFC conversion workflow. Keywords: CesiumJS AEC, georeference, georeferencing, BIM in Cesium, IFC in Cesium, CityGML, modelMatrix, Transforms.eastNorthUpToFixedFrame, headingPitchRollToFixedFrame, HeadingPitchRoll, Matrix4, ECEF, local frame, east north up, digital twin, geo-BIM, EdgeDisplayMode, CAD edges, model wrong location, model at cente

2026-05-201

package.json

"author": "Impertio-Studio"

"repository": "Impertio-Studio/CesiumJS-Claude-Skill-Package"

GitHub 저장소 열기 Creator 저장소 보기

$ install --global

$ download --local

Manus에서 실행

$ useful --forSOC

소프트웨어 개발자컴퓨터 및 수학직15-1252L4

name	cesium-errors-memory
description	Use when a CesiumJS app's memory keeps growing, the browser tab slows down or crashes after running a while, or the console reports "Too many active WebGL contexts" or "DeveloperError: This object was destroyed". Covers WebGL resource leaks from missing destroy() calls, teardown ordering, reusing primitives after destruction, entity-removal memory retention, lost-reference bugs that only look like leaks, and exhaustion of the browser 16-context WebGL budget by single-page-app routing or React re-mounts. Keywords: memory leak, heap grows, tab crash, out of memory, browser freezes, app slow over time, WebGL context lost, too many active WebGL contexts, This object was destroyed, DeveloperError, destroy, isDestroyed, PrimitiveCollection, destroyPrimitives, viewer.destroy, how do I clean up a Cesium viewer, why does my Cesium app leak memory.
license	MIT
compatibility	Designed for Claude Code. Requires CesiumJS 1.124+.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

Cesium Errors : Memory

Overview

WebGL resources held by CesiumJS objects are NOT garbage collected. A texture, vertex buffer, or shader stays on the GPU until something calls destroy() on the object that owns it. Dropping the last JavaScript reference frees nothing.

Every CesiumJS memory bug reduces to one of two causes:

A destroy() call that never happened. This is a real leak.
A reference still held when you believe it was released. This is a lost-reference bug that only imitates a leak.

This skill separates the two and gives a deterministic teardown procedure.

When to Use

Heap or GPU memory climbs on every load, navigation, or add/remove cycle.
The tab slows down, freezes, or crashes after the app runs a while.
Console shows WARNING: Too many active WebGL contexts. Oldest context will be lost.
Console throws DeveloperError: This object was destroyed and should not be used.
An older map view goes blank while a newer one still renders.
A Chrome heap snapshot diff shows CesiumJS objects surviving teardown.

The Iron Rule

ALWAYS call destroy() on every Viewer, Cesium3DTileset, Model, custom Primitive, custom PrimitiveCollection, and ScreenSpaceEventHandler you create, before you drop the reference.
ALWAYS verify a teardown by checking isDestroyed() returns true.
NEVER call any method except isDestroyed() on an object after destroy(). Doing so throws DeveloperError.
NEVER construct a new Viewer on a code path that runs more than once. Create one Viewer and reuse it.
NEVER assume removing a primitive frees GPU memory unless the collection's destroyPrimitives is true (see E3).

Ownership and Teardown : Quick Reference

Object	Freed by	Notes
`Viewer`	`viewer.destroy()`	Cascades to `Scene`, globe, `scene.primitives`, owned imagery layers and data sources.
`Cesium3DTileset` or `Model` in `viewer.scene.primitives`	`viewer.destroy()` or `scene.primitives.remove(obj)`	`scene.primitives.destroyPrimitives` defaults `true`, so removal destroys the object.
A primitive you removed and kept	Already destroyed by `remove()`	After removal from a `destroyPrimitives: true` collection it is destroyed. Do NOT reuse it.
Custom `new PrimitiveCollection({ destroyPrimitives: false })`	You destroy each member, then the collection	`false` disables automatic destruction.
Entity in `viewer.entities`	`viewer.entities.remove()` or `removeAll()`	`EntityCollection` has NO `destroy()`. Visualizers free GPU primitives on the next render.
`DataSource` in `viewer.dataSources`	`viewer.dataSources.remove(ds, true)`	The `destroy` parameter defaults `false`. Pass `true` to free it.
`ScreenSpaceEventHandler`	`handler.destroy()`	The viewer does NOT own it. Always destroy it yourself.

Decision Tree : real leak or lost reference?

digraph leak_triage {
  rankdir=TB;
  grow [shape=box, label="Memory grows over cycles"];
  destroyed [shape=diamond, label="destroy() called on every created object?"];
  verified [shape=diamond, label="isDestroyed() returns true after teardown?"];
  real [shape=box, label="Real leak : add the missing destroy()"];
  lost [shape=box, label="Lost reference : find the retainer (E5)"];
  grow -> destroyed;
  destroyed -> real [label="no"];
  destroyed -> verified [label="yes"];
  verified -> real [label="no"];
  verified -> lost [label="yes"];
}

Error Catalog

E1 : WebGL resources leak after a dropped reference

Symptom : GPU and heap memory climb every time a tileset, model, or primitive loads. The tab eventually slows or throws CONTEXT_LOST_WEBGL.
Root cause : WebGL buffers, textures, and shaders are not garbage collected. Setting the variable to null or letting it leave scope frees nothing. Only destroy() releases GPU memory.
Prevention : ALWAYS pair object creation with a destroy() in the matching teardown path. Objects inside viewer.scene.primitives are covered by a single viewer.destroy(). Destroy side-channel objects explicitly.
Recovery : list every object created since startup; for each, confirm a destroy() runs on teardown; add the missing call; assert isDestroyed().

E2 : DeveloperError "This object was destroyed"

Symptom : DeveloperError: This object was destroyed and should not be used. thrown when a method runs on a tileset, primitive, viewer, or handler.
Root cause : the object was already destroyed, then reused. Common trigger : scene.primitives.remove(primitive) destroys the primitive because PrimitiveCollection.destroyPrimitives defaults to true; stale code keeps the reference. The same happens after viewer.destroy().
Prevention : after remove() or destroy(), set the reference to null immediately. Guard any reuse with if (!obj.isDestroyed()).
Recovery : stop reusing the destroyed instance; recreate it through its async factory (Cesium3DTileset.fromUrl, Model.fromGltfAsync).

E3 : Silent leak with destroyPrimitives set to false

Symptom : heap grows across add/remove cycles even though remove() or removeAll() is called every time.
Root cause : a PrimitiveCollection constructed with { destroyPrimitives: false } does NOT destroy its members on remove, removeAll, or destroy. The caller owns destruction and skipped it.
Prevention : keep destroyPrimitives at its default true unless primitives are deliberately shared between collections. When it must be false, call destroy() on each primitive yourself after removing it.
Recovery : track members in an array; on clear, destroy() each one, then removeAll().

E4 : Memory retained after entity removal

Symptom : after viewer.entities.removeAll(), CPU memory stays high; with very large entity counts the app stutters every tick.
Root cause : EntityCollection has no destroy() method. Entity visualizers free the underlying GPU primitives lazily on the next render pass, and the per-tick visualizer loop scales with entity count. Historically about 100 MB per 5000 entities (issues #6534, #8767).
Prevention : cap entity count; above roughly 10000 features migrate to Cesium3DTileset or batched Primitive plus GeometryInstance; reuse entities instead of churning remove and add.
Recovery : call removeAll(), then allow one render pass so visualizers release primitives; for a hard reset, viewer.destroy() and create one fresh viewer.

E5 : Heap grows but it is not a CesiumJS leak

Symptom : a heap snapshot diff shows CesiumJS objects surviving an add/remove cycle even though destroy() was called.
Root cause : CesiumJS pools and reuses memory, so modest steady-state growth is expected. A genuinely retained object is almost always held by application code : a closure, a module-level array, an un-removed event listener (clock.onTick, scene.preRender, camera.changed), a requestAnimationFrame callback, or framework state. XHR responses can also be retained by a pending Request (issue #8843).
Prevention : store each CesiumJS object in exactly one owner; for every addEventListener on a CesiumJS Event, keep the returned remover function and call it on teardown.
Recovery : take two Chrome heap snapshots around one cycle, diff retainers, and follow the retaining path to the application code holding the reference; remove that path. See references/examples.md.

E6 : Too many active WebGL contexts

Symptom : console warning WARNING: Too many active WebGL contexts. Oldest context will be lost.; an older Cesium view goes blank or throws CONTEXT_LOST_WEBGL.
Root cause : a browser tab allows only about 16 live WebGL contexts. Each Viewer and each CesiumWidget holds one. Single-page-app route changes, React component re-mounts (StrictMode mounts twice in development), and modal open/close cycles create new viewers faster than old ones are destroyed. viewer.destroy() does not always release the context immediately (issue #11533).
Prevention : create exactly ONE Viewer and reuse it across routes and components; ALWAYS call viewer.destroy() in the unmount or cleanup path; never construct a Viewer inside a function that runs on every render.
Recovery : destroy every stray viewer; consolidate to a single long-lived viewer; in React, hold the viewer in a useRef and create it once.

Teardown Ordering

viewer.destroy() cascades to its Scene, the globe, scene.primitives (which destroys contained primitives because its destroyPrimitives is true), and the imagery layers and data sources the viewer owns. Side-channel objects are NOT covered. Tear down in this order:

Remove every CesiumJS event listener you added (clock.onTick, scene.preRender, camera.changed) by calling the remover that each addEventListener returned.
Call destroy() on every ScreenSpaceEventHandler you created.
Call destroy() on any custom PrimitiveCollection and on primitives it held with destroyPrimitives: false.
Call viewer.destroy() LAST.
Set the viewer reference and all child references to null.

NEVER read viewer, viewer.scene, or any child after step 4. A complete React useEffect cleanup is in references/examples.md.

Tileset Memory Budget

A Cesium3DTileset caps its GPU cache with cacheBytes (default 536870912, 512 MiB) plus maximumCacheOverflowBytes (default 536870912). Read tileset.totalMemoryUsageInBytes to measure live usage. The removed maximumMemoryUsage property no longer exists; code that sets it silently does nothing. Lower cacheBytes to cap peak GPU memory at the cost of more tile refetching. Signatures are in references/methods.md.

Common Mistakes

Mistake	Consequence	Fix
Setting a tileset variable to `null` without `destroy()`	GPU memory leaks	Remove it from `scene.primitives`, or call `tileset.destroy()` first
Reusing a primitive after `scene.primitives.remove()`	`DeveloperError`	Null the reference; recreate via the async factory
`new PrimitiveCollection({ destroyPrimitives: false })` then `removeAll()`	Silent leak	Destroy each member, or keep `destroyPrimitives` true
`viewer.dataSources.remove(ds)` without the destroy flag	DataSource leaks	Use `viewer.dataSources.remove(ds, true)`
New `Viewer` per React mount	16-context budget exhausted	One viewer in a `useRef`, destroyed on unmount
Reading `viewer.scene` after `viewer.destroy()`	`DeveloperError`	Null references; never touch after destroy

Red Flags : STOP

A variable holding a CesiumJS object is set to null and no destroy() ran first.
A Viewer is constructed inside render, a useEffect without cleanup, or a loop.
destroyPrimitives: false appears without a matching manual destroy() loop.
An addEventListener on a CesiumJS Event has no paired remover on teardown.
Code reads a property of an object after that object was removed or destroyed.

Each of these means a leak or a DeveloperError is already present. Fix before shipping.

Reference Files

references/methods.md : verified signatures and semantics of destroy(), isDestroyed(), PrimitiveCollection.destroyPrimitives, DataSourceCollection.remove, and the Cesium3DTileset memory budget.
references/examples.md : a complete teardown function, a React useEffect cleanup, tileset memory-budget configuration, and a heap-snapshot workflow.
references/anti-patterns.md : each memory anti-pattern with symptom, root cause, prevention, and recovery, traced to CesiumGS GitHub issues.

Sources

Verified via WebFetch on 2026-05-20 against the CesiumJS API Reference (https://cesium.com/learn/cesiumjs/ref-doc/) : Viewer, Scene, Cesium3DTileset, PrimitiveCollection, DataSourceCollection, EntityCollection, ScreenSpaceEventHandler.

cesium-errors-memory

이 저장소의 다른 Skills

이 저장소의 다른 Skills

Cesium Errors : Memory

Overview

When to Use

The Iron Rule

Ownership and Teardown : Quick Reference

Decision Tree : real leak or lost reference?

Error Catalog

E1 : WebGL resources leak after a dropped reference

E2 : DeveloperError "This object was destroyed"

E3 : Silent leak with destroyPrimitives set to false

E4 : Memory retained after entity removal

E5 : Heap grows but it is not a CesiumJS leak

E6 : Too many active WebGL contexts

Teardown Ordering

Tileset Memory Budget

Common Mistakes

Red Flags : STOP

Reference Files

Sources

Cesium Errors : Memory

Overview

When to Use

The Iron Rule

Ownership and Teardown : Quick Reference

Decision Tree : real leak or lost reference?

Error Catalog

E1 : WebGL resources leak after a dropped reference

E2 : DeveloperError "This object was destroyed"

E3 : Silent leak with destroyPrimitives set to false

E4 : Memory retained after entity removal

E5 : Heap grows but it is not a CesiumJS leak

E6 : Too many active WebGL contexts

Teardown Ordering

Tileset Memory Budget

Common Mistakes

Red Flags : STOP

Reference Files

Sources