# three-cesium-examples: a catalogue of WebGL demos with a config-driven front page

> A static site that collects Three.js and Cesium.js examples as small modules, where each entry in a config file decides what the front page renders and where the demo files are actually fetched from.

**z2586300277/three-cesium-examples** — WebGL examples and demos using Three.js and Cesium.js.

- Repository: https://github.com/z2586300277/three-cesium-examples
- Website: https://z2586300277.github.io/three-cesium-examples/
- Stars: 2,200 · Forks: 332
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/z2586300277-three-cesium-examples

## A static index page over a folder of small demo modules

The repository tree is short enough to read in one pass, and it tells you most of what the project is:

```
├── assets/             # 运行框架
├── threeExamples/      # three.js 案例代码目录
├── cesiumExamples/     # cesium 案例代码目录
├── js/                 # 第三方js依赖存放处
├── files/              # 模型、图片等资源
├── config/             # 配置项
├── .gitignore          # git 忽略文件
├── index.html          # 入口页面
├── LICENSE             # 开源协议
└── README.md           # 项目说明
```

There is no package.json, no lockfile and no build script. The site is served as static files, and the README is explicit that you need a running web server with the port pointing at `index.html`, naming nginx, Apache and liveServer as options. The framework assets live under `assets/`, third-party JavaScript goes in `js/`, and shared models and images live in `files/`.

The dependency situation is equally manual. The README instructs contributors to ensure the project is online when running so that dependencies like three and gsap can be pulled in, and to place extra library files such as dat.gui or gsap in the `js/` directory, with the injection point visible in `config/config.js`. In other words, you are assembling a page out of CDN links and files you placed by hand.

The result is genuinely lightweight in the sense that matters for a demo gallery. Nothing needs to compile, nothing needs to install, and the site keeps working as long as the network does.

## One config record decides what a card shows and where the demo lives

The design centre of the project is a single record shape per example, documented in the README as a JavaScript object:

```js
{
    id: '列表唯一id',
    name: '名称',
    name_en: '英文名',
    tag: '标签名字-背景颜色-字体大小',
    tip: '提示信息',
    author: '作者id',
    referUrl: '案例参考来源地址', // 如 没有可不配置
    downloadUrl: '附带下载的url', // 如three.js => 高级案例 => 桃花亭 配置后refer将不显示
    imporver: '优化作者', // 优化作者的id
    links: [{ url: '连接', name: '名称' }] //配置link imporver 将不显示
    image: HOST + 'threeExamples/basic/test.jpg', // 对应窗口图
    codeUrl: HOST + 'threeExamples/basic/test.js', // js module格式 大多数案例形式
    htmlUrl: HOST + 'threeExamples/test/test.html' // html 在线格式 如 three案例 => 粒子 => 随机粒子 粒子行星
    openUrl: '预览外联地址url', // openurl 和 codeurl 为二选一形式 如 可见桃花亭 su7 案例
    githubUrl: '附带github 仓库的url', // 如 three.js => 开源作品 => su7
    meta: {
        title: '此案例网站标题',
        keywords: '搜索引擎关键字',
        description: '此案例页面描述'
    }
}
```

Three things stand out. First, `HOST` is computed from the current domain at load time, with a comment explaining that this prevents asset references from breaking across deployment environments. Second, `openUrl` and `codeUrl` are mutually exclusive: a demo either links out to someone else's hosted preview or shows its own module. Third, there are three different code delivery shapes, so the same gallery handles an inline module demo, a standalone HTML page and an external link.

The `meta` block with `title`, `keywords` and `description` is per-example, which means each demo can carry its own search metadata rather than inheriting the site's.

The `config` directory listing in the README shows nine subdirectories, including `site`, `host`, `links`, `lang`, `author`, `three-examples` and `cesium-example`. Author identity lives in `config/author.js`, and an example references it by id, so contributors get a card with their name and links without touching shared layout.

## Assets live wherever the config points, which is the real architecture

The most distinctive idea here is that this repository does not have to store the assets. The README frames it as requesting resources as if they were API calls: code and images are not confined to this repository, they can sit on your own server, and the config only records the URL.

The suggested pattern is a separate repository acting as a file server, with the author's own example pointing at `https://z2586300277.github.io/3d-file-server/`. The README then explains how to set one up: create a repository, open its settings, go to Pages, set the deployment source to a branch, pick the branch, and save. It also notes that visiting the directory URL directly will 404 and that only a precise file path works, which is normal GitHub Pages behaviour.

The stated reason for doing this rather than keeping files in the repository is a size constraint. Contributors are asked not to submit files over 200 KB, to compress images to roughly 10 KB with a linked compression tool, and to prefer external URLs for shared models and media so the repository stays light. A gallery that hosts hundreds of demos in one git history stops being pleasant to clone the moment the binaries go in, so the split is a pragmatic answer to a real problem.

The tradeoff is equally real and the README does not soften it: because a card points at a URL you do not control, the demo breaks when that URL breaks. Reading the config tells you where each example lives, and the three-cesium-examples record for a 3D map is named in the README as a reference for the approach.

## Two repositories, and the README says this one is the quieter one

The README opens by pointing somewhere else. It names `https://github.com/OpenThree/three-github-examples/` as the frequently updated repository, with a preview at `https://openthree.github.io/three-github-examples/`, and states plainly that this repository is updated less often and that ongoing work has migrated.

That statement sits at the very top of the README, above the contribution instructions, which is an unusual place for a deprecation note and suggests the author would rather you use the other repository. Both exist, both have the same star count as far as a reader can tell from the site, and the page footer lists deployment variants including elegant-github, elegant-vercel, openThree-github, threehub, cesiumhub and a codeLike deployment.

The repository itself is not archived, its default branch is `dev` rather than `main`, and the last push was 2026-09-11. It carries 2,194 stars, 332 forks and a single open issue.

That fork-to-star ratio is the most informative number in the metadata. Roughly one fork per seven stars, against a single open issue, is not what you see in a library. It is what you see in a repository whose intended contribution flow is fork, add your entry, open a pull request to `dev`, which the README documents in exactly those terms. The forks are submissions in flight, and the low issue count reflects that this is a curated gallery rather than a place people file bugs.

The repository description carries the same signal, mixing English and Chinese and adding an encouragement to star the project.

## Contribution flow and the contributor table

The documented flow is four steps: fork the repository, add your contributor information, submit code, and merge into `dev`. Developers in repository management can create their own branches or work directly on `dev`.

The steps for adding one example are more specific. Record your developer details in `config/author.js`, then put your example's JavaScript into the appropriate directory under `threeExamples/` or `cesiumExamples/`, either as loose files such as `test.js` and `test.jpg` or as a directory containing both. Then register the example in the matching config file, pointing the resource paths at your files.

A contributor table in the README lists a dozen names with contact handles and links, and each has a stated speciality: Cesium.js, Three.js and Cesium.js, Babylon.js, advanced GIS rendering, Cesium, Three VR and 3D Gaussian splatting, Three.js on mobile and mini programs, and a point cloud rendering engine. That list is a decent map of the Chinese-language WebGL community this project sits in, and the presence of dedicated sites for several of them suggests the gallery functions partly as a directory.

There is also an online submission form linked from the README, hosted separately from the repository, so contributing does not strictly require a git account. Whether submissions land as pull requests or are curated by the maintainers is not something the README settles.

## What you can actually learn from the examples themselves

Setting the infrastructure aside, the value of a demo gallery is in the demos. The categories named in the README include Three.js basics, particles, expanded features including a 3D map, advanced work, open-source works with an attached GitHub repository, and Cesium topics such as offline maps with an internal-network AMap source.

The Cesium side is the more specialised of the two. The contributor table dedicates several rows to Cesium work, and the offline map example with a local AMap source is the kind of thing that is genuinely awkward to work out alone, because it involves network configuration rather than rendering. The Three.js side covers more ground and is closer to what the wider ecosystem already publishes, so the marginal value of a copy is lower.

The preview is reachable on the `dev` branch through GitHub Pages, and the README notes the branch specifically rather than pointing at a production URL. That means what you see on the live site is the working branch, which for a submission-driven gallery is the honest thing to browse.

If you are weighing this against building your own gallery, the comparison is short. Writing one yourself means choosing a build tool, a template system and a hosting story, and maintaining all three. This gives you a static site, a config-driven index, a contributor model and a hosting walkthrough, in exchange for adopting someone else's structure and living with URLs that point outward.

## Conclusion

This repository is worth reading as a pattern rather than as a library of techniques. There is no build step, no framework and one runtime dependency on a static host, and the entire catalogue is a list of records in config files where each record names an image, a code URL and an HTML preview. That makes it a workable template for a team that wants an internal gallery of WebGL experiments without standing up a database. Two things to weigh first: the README states that ongoing development has moved to OpenThree/three-github-examples, and the example files are served from wherever a contributor's config points, so availability is a property of the contributor rather than of this repository. Fork it, repoint the config, and keep the assets on infrastructure you control.

## FAQ

### What are Cesium 3D Tiles?

3D Tiles is Cesium's format for streaming very large 3D geospatial datasets such as photogrammetry and city models, and it is the subject of several examples in the Cesium section of this gallery. The gallery itself does not explain the format; it demonstrates techniques built on top of Cesium.

### What can I make with Three.js?

The Three.js examples here span basics, particles, expanded features such as a 3D map, and advanced work, with some entries linking to an attached GitHub repository. The most advanced entries have the least explanation in the config record, so the gallery is best treated as a set of starting points rather than a tutorial.

### How do I add my own example to three-cesium-examples?

Add your details to config/author.js, place your JavaScript and image under threeExamples or cesiumExamples, then register the example in the matching config file with the resource paths. Keep files under 200 KB, compress images to roughly 10 KB, and open a pull request against the dev branch.

### Does three-cesium-examples need a build step or npm install?

No. The repository has no package.json and no build script. The site is static files served by any web server pointed at index.html, with three and gsap loaded from the network and extra libraries such as dat.gui placed by hand in the js directory and injected via config/config.js.

## Sources

- [Issues](https://github.com/z2586300277/three-cesium-examples/issues)
- [License: Apache-2.0](https://github.com/z2586300277/three-cesium-examples/blob/dev/LICENSE)
- [Project website](https://z2586300277.github.io/three-cesium-examples/)
- [README](https://github.com/z2586300277/three-cesium-examples/blob/dev/README.md)
- [z2586300277/three-cesium-examples on GitHub](https://github.com/z2586300277/three-cesium-examples)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/z2586300277-three-cesium-examples