CSG in the player: build time baking and runtime editing

Aperta
  • Qualcosa non va?
#64 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, unity
Ambito
game-dev

Direzione di ricerca

Start by tracing ChiselModelManager.UpdateModels and its #if UNITY_EDITOR block, then follow the build-time scene processing and asset lookups described in the issue. Check how paint settings, hotspot layouts, surface parameter identities, and editor-only mesh data are supplied to player builds, including IL2CPP constraints. Done means an unsaved scene builds with all models visible, and runtime brush edits rebuild correctly in a player build with player tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

The CSG only runs in the editor. A build should either bake the models into plain meshes, or keep them editable in the player.

Done when (in 6.6 and Unity 7)

  • Baked: a player built from a scene saved with stale meshes shows them up to date, and contains no Chisel components or code.
  • Runtime: in a player, changing a brush and calling ChiselRuntime.Update() changes its mesh, tested in a player build.

Design

One setting per build, "CSG in the player", off by default:

Setting Code in the player Scenes in the player
Off (baked) No Chisel assemblies or Burst CSG jobs Plain meshes and colliders
On (runtime) Core, components, Burst jobs Chisel components, with meshes up to date at build time
  • The setting should be a build profile sub-asset (BuildProfile.AddComponent) that writes CHISEL_RUNTIME into the profile's scriptingDefines; CI can use BuildPlayerOptions.extraScriptingDefines. Check that a define set in IPreprocessBuildWithReport is too late, so it has to be in place before the build starts.
  • With the setting off the code should go too: core, components and dots.extensions should get "defineConstraints": [ "UNITY_EDITOR || CHISEL_RUNTIME" ] (try || in 6.6 and Unity 7 first). A build preprocess should fail clearly when user code references Chisel without the same constraint.

Build step (both settings)

  • There should be one Bake(Scene), called from IProcessSceneWithReport (6.6) and AssetPostprocessor.OnProcessScene (Unity 7, where the interface is deprecated), like ChiselDrawModesProcessScene, whose debug renderer hiding should move into it.
  • It should build every model.
  • Baked:
    • should strip the Chisel components, partial and selection meshes and debug renderers, leaving MeshFilter, MeshRenderer and MeshCollider
  • Runtime:
    • should keep the components, with the meshes it built
    • should optionally keep partial and selection meshes and debug renderers, for a CSG editor that runs in the player (partial and selection meshes are #if UNITY_EDITOR in ChiselRenderableObjects today, so that code has to compile in a player too)
    • should write the project's materials into a preloaded asset (a player has no ProjectSettings/)
    • should store each model's lightmap UV settings (texels per unit, padding, maximum size), so a player can lay out lightmap UVs as the editor does
  • Check first:
    • whether the processed scene is isolated from the scenes open in the editor.
    • The managers are static, CompactHierarchyManager.Flush builds every dirty tree, and some lookups are global (ChiselPaintManager's FindObjectsByType, the decal hierarchy scan). Each model is its own CSGTree, so the CSG results themselves can't mix.
  • Scene processing:
    • Should be cached by Unity.
    • It can run in a worker process isolated from the editor.
    • If a lightmapped model's rebuilt meshes differ from the ones saved in the scene, its lightmaps no longer fit: warn to rebake the lighting.
    • The callbacks also fire when a scene loads in the editor's Play mode, so we might want to skip this for Play mode.

Runtime (setting on)

  • Updating:
    • add ChiselRuntime.Update(), which the game would call after editing; it should call ChiselNodeHierarchyManager.Update() and UpdateModels()
    • everything should be done when ChiselRuntime.Update() returns: MeshColliders should be baked immediately, not deferred as in the editor (ChiselColliderObjects.DeferBaking off)
    • make UpdateModels work in a player; only the lightmap resolution update (the player would get the settings from the build step) and the editor's saved mesh reuse (it uses AssetDatabase) should stay editor only
    • in Play mode only ChiselRuntime.Update() should update the models: ChiselModelComponent.UpdateModelSettingsLookup() and ChiselModelManager.BuildTheNodesOfNow() should not call UpdateModels() then
  • Noticing changes:
    • ChiselRuntime.Update() should check Transform.hasChanged on the registered nodes to find moved ones
    • edits should go through the Chisel component setters (e.g. ChiselBoxComponent.Max), not their serialized fields; check that every setter marks its component dirty
  • Loading:
    • for now ChiselRuntime.Update() should rebuild every model; properly detecting when sub-meshes should be updated or not (when unchanged) at build time is #106 and can be tackled later
    • the project's materials should come from the asset the build step preloads
  • Limits:
    • we don't support lightmaps at runtime
    • a runtime player would carry Unity.Entities (used only for blobs) and its world bootstrap: replace the blobs or set UNITY_DISABLE_AUTOMATIC_SYSTEM_BOOTSTRAP
  • Not tested: Burst and native containers under IL2CPP, MeshCollider cooking cost.

Order: the build step and baking first, then runtime.

Lingua principale
C#
Stelle
135
Fork
15
Merge medio
24m
PR unite (30g)
90

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RadicalCSG/com.chisel

Tutte le issue di RadicalCSG/com.chisel

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.