# Suppressing unwanted content without negative conditioning, cross-scene consistency in 3DGS, and data-driven artwork placement on generated walls > Source: > Published: 2026-08-22 01:42:35+00:00 Hmm… maybe it would be better to first figure out a way to experiment without losing your bearings?: Your follow-up changes how I would answer this. After four weeks of wrestling with this, I would pause the six original questions for a moment and make the **experiments themselves cheap to try, easy to compare, and easy to undo**. That seems more useful than adding another layer of architecture right now. I also would not assume “renaming projects a hundred times” points to one particular underlying problem. If you literally mean folders/projects turning into things like: ``` museum-final museum-final2 museum-lighting-test museum-lighting-test-fixed museum-real-final ``` then yes, version control is designed to replace that kind of history-by-filename. But if you mean something broader — an AI-assisted change keeps turning into a different project, or after enough edits you no longer know which world / `.spz` / collider / code state actually belongs together — Git alone will not solve that. Because you are coming to this from graphic design and using AI coding assistants, I would **not** turn the answer into “first, become a developer.” I would give the project a very small memory outside the chat. The whole idea would be: Keep one place called HOME, change one main idea at a time, and always know how to get back. A checkpoint is a little like taking a photo before rearranging a room. You are still free to move everything around; the point is that “before” never becomes ambiguous. I would put five small guardrails around the project: | The small version | | |---|---| 1. HOME | Pick one working room you understand and record the code + Marble/SPZ/collider/transform state that belongs to it. | 2. Visible history | Make one untouched backup; if folder/project copies are multiplying, let Git history replace `final-final2` naming. | 3. Project note | Keep one tiny `PROJECT_STATE.md` : current question, what stays fixed, how you will check it, what happened, and what you meant to do next. | 4. One-room laboratory | Test a new idea in one representative room first. The other ten scenes are the later “does this generalize?” test. | 5. AI workbench | Let the chat explore, but keep HOME, decisions, tried ideas, and next action in the project rather than only in the conversation. | That is the system in miniature. If those five lines already make sense, I would **start there and ignore the rest until something specific hurts**. The concrete version — including the tiny files/checklists I mean — is below. The concrete HOME / Git / PROJECT_STATE / AI setupAt any point, ask: If one answer becomes “I’m not sure,” stop adding changes for a moment. Not forever. Just long enough to recover the map. This is not only a beginner phenomenon: studies of experienced developers describe disorientation when navigation context disappears, views are revisited repeatedly, or side tasks displace the original task ([field study](https://www.cs.ubc.ca/tr/2005/tr-2005-23), [follow-up](https://www.cs.ubc.ca/~murphy/papers/disorientation/disorientation-vlhcc06.pdf)). So I would treat orientation as something the workflow should preserve. The nice thing is that you do not need to know *why* you became lost before you recover. Google’s incident-response guidance makes a similar separation: restoring/mitigating toward a known-good state and understanding the complete root cause can be different jobs ([Incident Response](https://sre.google/workbook/incident-response/)). Give each one its own small card rather than letting one AI conversation redesign the whole museum around all six. The card can use the same five lines every time: ``` QUESTION: KEEP FIXED: CHANGE: KEEP IT IF: GO HOME IF: ``` That last line matters. A stop condition prevents “one more tweak” from quietly turning a small experiment back into a project rewrite. | Original question | Smallest experiment I would run | |---|---| Q1 — unwanted generated content | One generation requirement + explicit forbidden-content checklist. Compare a small number of prompt/reference/edit strategies; accept/reject the result rather than endlessly modifying the whole pipeline. | Q2 — cross-scene consistency | Two representative rooms. Compare one stronger shared-state strategy — e.g. shared reference/geometry, Marble Expand, or explicit Compose alignment — against independent generation. | Q3 — exterior degradation | One bad exterior. Check where the problem first appears: pano → Marble world → exported SPZ/mesh → Spark. | Q4 — painting looks like a decal | One painting. First verify Three.js color handling; then compare your current grading against one local environment-map approach. | Q5 — automatic hanging | One difficult wall. Validate the existing three-height test against a small set of manually judged “usable / unusable” positions before making the algorithm cleverer. | Q6 — selective spotlight | One painting in HOME. Prototype one local splat edit and measure visual result + frame time before integrating it with the rest of the interaction system. | That changes the mental model from: ``` "I am rebuilding a complicated 11-scene system" ``` to: ``` "I am answering one small question, then deciding whether its answer belongs in HOME." ``` And every experiment only needs one of three endings: ``` php KEEP IT -> it worked + the small checks still pass -> it can become HOME GO HOME -> it failed or answered the question negatively -> record that and return PARK IT -> interesting but unclear -> save the idea without building on top of it ``` `PARK IT` is especially useful with AI: a plausible idea can be remembered without becoming code today. I would not try to turn questions like these into fake metrics: Those are design judgments. What I would make precise is: ``` which room which world which SPZ which collider which code checkpoint which experiment which result ``` That gives you a nice middle ground: creative judgment can remain subjective while the route to each candidate stays recoverable. A compact handoff is usually enough: ``` QUESTION: HOME: candidate: expected: actual: shortest reproduction: what changed: what stayed fixed: screenshot / golden view: relevant error/log: what I already tried: ``` That is the [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) idea adapted to a visual/3D project — and a clean way to start a fresh AI conversation. Instead of: “Please understand this enormous chat and remember what happened three projects ago…” you can say: “Here is HOME. Here is the candidate. Here is the one thing that changed. Here is what I observed.” If I were in front of the project tomorrow, I would do this: ``` 1. choose one working room 2. call it HOME 3. make one visible code checkpoint 4. write down the exact SPZ/collider/world that belongs to it 5. create PROJECT_STATE.md 6. choose ONE of the six original questions 7. define the smallest experiment that answers it 8. tell the AI what it must not change 9. run the same small checks / fixed views 10. KEEP IT, GO HOME, or PARK IT ``` Then repeat. If that already stops the project from turning into `final-final-really-final-27` , I would not add more process. And if it does **not** help, that is still a useful result: now the problem is more specific. It is probably time to open only the relevant detour — asset identity, AI change scope, runtime lifecycle, dependency drift, or an experiment that is not separating the possibilities. That is much easier to work with than “the whole project no longer fits.”