Two-tier entity representation for bulk debris
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 12/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- csharp
- 領域
- game-dev, performance
調査の方向性
This is a design proposal, not a scoped edit: start by reading ADR-018's ownership table and the flat-soa-snapshot-pattern page on the mass4-wiki, then look at Example 12 and how Node/ModelComponent are wired to the physics front end. Line up with #325 (transform SoA) and #327 (instanced drawing), since the debris tier depends on both. Done means an approved debris API design plus measurements at 10k, 50k and 100k against the acceptance criteria, or a documented measured limit.
索引モデルが issue の本文から書いたものです。
説明
Current State
Every simulated box in Example 12 is a full Node with a transform, a ModelComponent, a rigid body and a collider, plus the physics front end's own record. Per object, the engine pays for a scene-graph entry, components, serialization surface and pose copies in both directions every tick. At 10k this is the main per-frame and per-tick cost outside Bepu. At 100k, the object graph alone would dominate.
ADR-018's ownership table already allows simulation objects with no scene node and no Node/Component per object: they get stable, game-owned identifiers instead.
Proposal
- Add a second tier for bulk debris: packed simulation bodies with stable IDs and no
Node/Component, created and destroyed through a pool API. - Render them instanced from Bepu's pose buffers with zero-copy reads (no per-body pose copy into the scene).
- Allow promotion and demotion between tiers (a debris body becomes a full
Nodewhen gameplay needs to interact with it) under explicit rules. - Use the shared vocabulary of the mass4-wiki page
flat-soa-snapshot-pattern: stable index, identity map, compaction.
Tasks
- Design the debris API (spawn, despawn, query, events, promotion) and its ownership under ADR-018.
- Prototype Example 12 with debris-tier boxes; measure 10k, 50k and 100k for physics tick, render, memory and allocation.
- Define how editor tooling, saves and networking see the debris tier (snapshotting, determinism, hashing).
Acceptance Criteria
- 100k debris bodies run at 60 Hz in the exported game on the reference machine, or the measured limit and its cause are documented.
- Per-body cost scales linearly and allocates nothing in steady state.
- The
Nodetier is unchanged for game code that does not use debris.
Related
- #64 (physics backend)
- #325 (transform SoA, Tier 2) and #327 (instanced drawing)
- #324 (never-sleeping pile)
- MASS4ORG/Guinevere#120 (the same pattern for UI layout)
- 主要言語
- C#
- スター
- 1
- フォーク
- 1
- 平均マージ
- 1時間 57分
- マージ済み PR（30日）
- 36
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
MASS4ORG/Turian のほかの issue
-
c:assets p:low size:XS t:task
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
c:engine c:platform p:low size:S t:feature
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
c:ui p:medium size:M t:feature
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
c:build p:low size:XS t:enhancement
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
メンテナーはふだん 1 日以内に返信
-
c:assets p:medium size:S t:bug
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
MASS4ORG/Turian の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 3 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
bug mac アプリ: コード アプリ: チャット 優先: 中 要トリアージ
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
yksr-melt/Meltype#1346 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
Collect corrected translations in the app, with no GitHub account and the least possible frictionオープンlocalization medium ui
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
hexide-io/HexIDE#2819 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信