CSG in the player: build time baking and runtime editing

Ouverte
  • Quelque chose ne va pas ?
#64 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
csharp, unity
Domaine
game-dev

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C#
Étoiles
135
Forks
15
Merge moyen
23 min
PR mergées (30 j)
115

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de RadicalCSG/com.chisel

Toutes les issues de RadicalCSG/com.chisel

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.