dead-air/game-planning
Watch
3
0
Fork
You've already forked game-planning
 1
Code Issues 22 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Blender addon: lay out maps, tag objects, one-click export to a Dead Air mod (exploratory, not guaranteed) #31

New issue
Open
opened 2026-10-31 19:10:26 +00:00 by muse-lantern · 0 comments
muse-lantern commented 2026-10-31 19:10:26 +00:00
Member
Copy link

Status: exploratory, NOT guaranteed

This is just thinking about it — a tracking issue for an idea, not a
commitment and not on the roadmap. Nothing here is approved to build.

The idea

Make the modding/asset pipeline require only Blender and Godot.
A Blender addon would expose everything the modding framework wants to
expose — code and function references, level design, etc. — inside
Blender, so someone can lay out a map, set up animations and trigger
zones there, and one-click export converts all the key refs and func
refs into a mod for Dead Air.

Tagging

Objects are tagged with a syntax like:

tag.name(key=value,foo=bar)

References, not embeds (load-bearing)

An item/object tag loads the reference from the tagged game assets and
does not export as an object in the scene. Example: import a custom
pistol into the Blender scene and tag it. On export, the pistol's
assets are NOT exported into the scene — the export emits a reference
to the asset in the game files. Importing + tagging in Blender is only
for positioning and scripting purposes.

Proposed one-click flow

  1. Validate: da_rig bone names, markers, namespaced ids, no ties.
  2. Bake only newly-authored geometry to .glb (with texture relinking).
  3. Write addon.json + level/item JSON sidecars: placements, trigger
    zones, animation refs, func refs.
  4. Godot headless imports and packs the .pck.

Func refs are resolved by the Godot module loader at load time and fail
loudly if missing, consistent with the tie rule (a conflict is a loud
startup error naming both sides, never a silent winner). Blender is
spatial authoring, not a code editor: the addon writes references to
code, never GDScript itself.

Open questions

  • Exact tag grammar, value types, and validation messages.
  • How to distinguish a reference proxy from newly-authored geometry:
    tag? collection? property?
  • Animations: clip refs vs baked curves vs timeline triggers?
  • Trigger zone shapes: boxes only, or arbitrary mesh bounds? Invisible
    collision, or pure data?
  • Behavior when a referenced asset is missing at load.
  • Pins: Blender 5.2.3 LTS + Godot 4.6.3.
  • Relation to: engine #24 (bake tool), engine PR #28 (module framework),
    engine #27 (module follow-ups), grip markers / da_rig, and
    game-planning #17 (modding support).

Non-goals

  • Blender as a GDScript editor.
  • Any third tool in the pipeline.
## Status: exploratory, NOT guaranteed This is just thinking about it — a tracking issue for an idea, not a commitment and not on the roadmap. Nothing here is approved to build. ## The idea Make the modding/asset pipeline require only **Blender and Godot**. A Blender addon would expose everything the modding framework wants to expose — code and function references, level design, etc. — inside Blender, so someone can lay out a map, set up animations and trigger zones there, and one-click export converts all the key refs and func refs into a mod for Dead Air. ## Tagging Objects are tagged with a syntax like: ``` tag.name(key=value,foo=bar) ``` ## References, not embeds (load-bearing) An item/object tag loads the reference from the tagged game assets and does **not** export as an object in the scene. Example: import a custom pistol into the Blender scene and tag it. On export, the pistol's assets are NOT exported into the scene — the export emits a reference to the asset in the game files. Importing + tagging in Blender is only for positioning and scripting purposes. ## Proposed one-click flow 1. Validate: da_rig bone names, markers, namespaced ids, no ties. 2. Bake only newly-authored geometry to .glb (with texture relinking). 3. Write `addon.json` + level/item JSON sidecars: placements, trigger zones, animation refs, func refs. 4. Godot headless imports and packs the .pck. Func refs are resolved by the Godot module loader at load time and fail loudly if missing, consistent with the tie rule (a conflict is a loud startup error naming both sides, never a silent winner). Blender is spatial authoring, not a code editor: the addon writes references to code, never GDScript itself. ## Open questions - Exact tag grammar, value types, and validation messages. - How to distinguish a reference proxy from newly-authored geometry: tag? collection? property? - Animations: clip refs vs baked curves vs timeline triggers? - Trigger zone shapes: boxes only, or arbitrary mesh bounds? Invisible collision, or pure data? - Behavior when a referenced asset is missing at load. - Pins: Blender 5.2.3 LTS + Godot 4.6.3. - Relation to: engine #24 (bake tool), engine PR #28 (module framework), engine #27 (module follow-ups), grip markers / da_rig, and game-planning #17 (modding support). ## Non-goals - Blender as a GDScript editor. - Any third tool in the pipeline.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
dead-air/game-planning#31
No description provided.