Permanent world snapshots: a durability ladder from Eco save to browser-loadable 3D asset #314

New issue

Open

opened 2026-08-20 05:00:54 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-20 05:00:54 +00:00

Member

Filed from the Sirens Discord #suggestions-feedback-bugs forum.

Source // https://discord.com/channels/1300204416229441587/1530515909968400506
Raised by // Kai, 2026-07-25
Forum tags // mods (code), mods (webapp)
Signal // 10 replies, includes a full counter-proposal

The goal

Each cycle's world is destroyed at the wipe. This is about keeping a walkable record of it, and the framing is explicitly about asset lifetime rather than backups. Kai: "I'm thinking about asset lifetimes a lot this week bc I keep maxing out my git servers disk with image builds."

Kai's proposed ladder, each rung more durable than the last

~1 year. Pull an Eco save off the server onto local disk. Survives Eco version upgrades only as long as the matching Eco client version stays available on Steam.
~5 years. Boot the Eco codebase in Unity, load the save as a scene, export a 3D snapshot roughly 0.1 seconds into play mode. The resulting Unity file should embed the assets it needs, so it loads without an Eco install. Lifetime estimated off the Unity LTS cadence.
~25 years. Restart Unity into a blank project, import that file, export to Blender, and confirm it opens. Blender is open source and free indefinitely, unlike Unity.
~125 years. Compile the Blender file into something that gives native 3D manipulation on low-resource machines. Kai's candidate is loading Blender objects into Bevy, which is fast and compiles to browser wasm. Desktop browsers yes, mobile unlikely. Then host it on https://eco-app.coilysiren.me/

Deepflame's counter-proposal, which avoids Unity entirely

Rather than the import and export chain, build a small purpose-made renderer:

Parse the save data directly, or have an agent write the parsing logic.
Write a custom WebGL renderer, blocks-only first. Identify the save's tiles, grab the 4, 9, 16, or 25 tiles surrounding the camera, and render each block as a 1x1x1 textured cube using Eco and mod assets.
Add object support in a second pass, rendering meshes and textures from the same asset sources.

His objection to the Unity route is specific and load-bearing:

Going through Unity with the import/export routes may be more difficult than you think, I'm not sure you can just export Unity assets to blender... You basically need to retrieve some sort of source from compiled assets.

His key point is that extracting usable source from compiled assets is unavoidable either way, because of mod assets. That work does not disappear by choosing the Unity path.

Kai's response was optimism about available expertise rather than a rebuttal: "I think there's many many people in the world with both the desire and skill to figure out how to coerce the Unity engine to export something Blender will load. Although if that's against the Unity TOS then I likely won't find those people."

Open questions

Unity TOS. Kai flagged this herself as a possible hard blocker on step 3.
Lighting. Unresolved in-thread. Kai: "Lighting is gonna suck. Can you snapshot the world with everything being in daylight?" Her own guess: "Eco day night is probably just a simple flat thing. Not spinny globe style." Needs checking rather than guessing.
Mod asset extraction. Required on both paths per Deepflame. This is the real first task regardless of which route wins.

Suggested first step

Decide between the two paths by testing the shared blocker, which is mod asset extraction, before investing in either chain. Step 1 of the ladder is cheap and independent, so it can start immediately either way.

Filed from the Sirens Discord `#suggestions-feedback-bugs` forum. **Source** // https://discord.com/channels/1300204416229441587/1530515909968400506 **Raised by** // Kai, 2026-07-25 **Forum tags** // mods (code), mods (webapp) **Signal** // 10 replies, includes a full counter-proposal ## The goal Each cycle's world is destroyed at the wipe. This is about keeping a walkable record of it, and the framing is explicitly about asset lifetime rather than backups. Kai: "I'm thinking about asset lifetimes a lot this week bc I keep maxing out my git servers disk with image builds." ## Kai's proposed ladder, each rung more durable than the last 1. **~1 year.** Pull an Eco save off the server onto local disk. Survives Eco version upgrades only as long as the matching Eco client version stays available on Steam. 2. **~5 years.** Boot the Eco codebase in Unity, load the save as a scene, export a 3D snapshot roughly 0.1 seconds into play mode. The resulting Unity file should embed the assets it needs, so it loads without an Eco install. Lifetime estimated off the Unity LTS cadence. 3. **~25 years.** Restart Unity into a blank project, import that file, export to Blender, and confirm it opens. Blender is open source and free indefinitely, unlike Unity. 4. **~125 years.** Compile the Blender file into something that gives native 3D manipulation on low-resource machines. Kai's candidate is loading Blender objects into Bevy, which is fast and compiles to browser wasm. Desktop browsers yes, mobile unlikely. Then host it on https://eco-app.coilysiren.me/ ## Deepflame's counter-proposal, which avoids Unity entirely Rather than the import and export chain, build a small purpose-made renderer: * Parse the save data directly, or have an agent write the parsing logic. * Write a custom WebGL renderer, blocks-only first. Identify the save's tiles, grab the 4, 9, 16, or 25 tiles surrounding the camera, and render each block as a 1x1x1 textured cube using Eco and mod assets. * Add object support in a second pass, rendering meshes and textures from the same asset sources. His objection to the Unity route is specific and load-bearing: > Going through Unity with the import/export routes may be more difficult than you think, I'm not sure you can just export Unity assets to blender... You basically need to retrieve some sort of source from compiled assets. His key point is that extracting usable source from compiled assets is unavoidable either way, because of mod assets. That work does not disappear by choosing the Unity path. Kai's response was optimism about available expertise rather than a rebuttal: "I think there's many many people in the world with both the desire and skill to figure out how to coerce the Unity engine to export something Blender will load. Although if that's against the Unity TOS then I likely won't find those people." ## Open questions 1. **Unity TOS.** Kai flagged this herself as a possible hard blocker on step 3. 2. **Lighting.** Unresolved in-thread. Kai: "Lighting is gonna suck. Can you snapshot the world with everything being in daylight?" Her own guess: "Eco day night is probably just a simple flat thing. Not spinny globe style." Needs checking rather than guessing. 3. **Mod asset extraction.** Required on both paths per Deepflame. This is the real first task regardless of which route wins. ## Suggested first step Decide between the two paths by testing the shared blocker, which is mod asset extraction, before investing in either chain. Step 1 of the ladder is cheap and independent, so it can start immediately either way.

coilyco-ops added the

labels

2026-08-20 05:00:54 +00:00