Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Two-tier entity representation for bulk debris

Abierto
  • ¿Algo no está bien?
#326 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp
Área
game-dev, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

c:engine p:low size:XL t:feature

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 Node when 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 Node tier 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)
Lenguaje dominante
C#
Estrellas
1
Forks
1
Merge medio
1 h 46 min
PR fusionados (30 d)
41

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MASS4ORG/Turian

Todos los issues de MASS4ORG/Turian

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.