性能优化
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
done:
1. face culling(对fps影响最大),分两部分,一部分是默认生成的主世界,一部分是新增方块的face culling,其中新增方块的 culling 为了保持逻辑简单,只做了整个方块的剔除,没有做更细致的面的剔除,实测影响不大。
2. instancedMesh,目标是降低 draw calling,也分两部分,
1. 一部分是默认生成的主世界的 chunk meshing 的实例化
2. 一部分是新生成的方块也纳入 instancedMesh 管理,确保 draw calling 的复杂度不超过 O(n),目前 draw calling 直接放在主线程里了,目测性能还可以。其中动态增加方块的 instancedMesh 为了不打破 gpu 的极限压力,做了缓冲池的数量控制,目前是128个,超过的话就完全用 new Mesh 的方式来新增实例,这样做是比较均衡的值。如果缓冲池太多(比如超过1000)fps会陡降到20-30,如果缓冲池太少,比如10个,则很容易就进入 new Mesh 模式而脱离 instancedMesh 的管理,后续创建方块越多,gpu 压力会呈线性增长。 方案实施不成功,换成了定期清理入instancedMesh,方案复杂度最小。
3. 动画特效:完全剔除程序模拟的粒子效果,也不要用 gif,而要用png的序列帧来模拟,性能最好。主要是tnt爆炸效果等。
4. worker:除了主线程之外,目前已有的三个线程
1. 世界地图渲染的管线
2. 数据读写 indexedDB 的管线
3. 处理复杂的爆炸半径与方块破坏计算.
5. 外部模型的导入,优先GLTF/GLB (.gltf, .glb)格式
todo:
1. 住线程 update 方法用 webassembly 重构
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the main-thread update method and trace what it currently does before assessing the WebAssembly rewrite. Done means the main-thread update method has been refactored to WebAssembly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, wasm
- Domain
- game-dev, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100