{"slug": "suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs", "title": "Suppressing unwanted content without negative conditioning, cross-scene consistency in 3DGS, and data-driven artwork placement on generated walls", "summary": "A new approach to managing AI-assisted creative projects recommends a five-part system centered on a 'HOME' directory, visible history via Git, a PROJECT_STATE.md note, a one-room laboratory, and an AI workbench, according to a guide for designers using AI coding assistants. The method aims to reduce disorientation and make experiments cheap to try, easy to compare, and easy to undo, citing studies on developer disorientation and Google's incident-response guidance.", "body_md": "Hmm… maybe it would be better to first figure out a way to experiment without losing your bearings?:\n\nYour follow-up changes how I would answer this.\n\nAfter 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**.\n\nThat seems more useful than adding another layer of architecture right now.\n\nI also would not assume “renaming projects a hundred times” points to one particular underlying problem.\n\nIf you literally mean folders/projects turning into things like:\n\n```\nmuseum-final\nmuseum-final2\nmuseum-lighting-test\nmuseum-lighting-test-fixed\nmuseum-real-final\n```\n\nthen yes, version control is designed to replace that kind of history-by-filename.\n\nBut 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`\n\n/ collider / code state actually belongs together — Git alone will not solve that.\n\nBecause you are coming to this from graphic design and using AI coding assistants, I would **not** turn the answer into “first, become a developer.”\n\nI would give the project a very small memory outside the chat.\n\nThe whole idea would be:\n\nKeep one place called HOME, change one main idea at a time, and always know how to get back.\n\nA 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.\n\nI would put five small guardrails around the project:\n\n| The small version | |\n|---|---|\n1. HOME |\nPick one working room you understand and record the code + Marble/SPZ/collider/transform state that belongs to it. |\n2. Visible history |\nMake one untouched backup; if folder/project copies are multiplying, let Git history replace `final-final2` naming. |\n3. Project note |\nKeep one tiny `PROJECT_STATE.md` : current question, what stays fixed, how you will check it, what happened, and what you meant to do next. |\n4. One-room laboratory |\nTest a new idea in one representative room first. The other ten scenes are the later “does this generalize?” test. |\n5. AI workbench |\nLet the chat explore, but keep HOME, decisions, tried ideas, and next action in the project rather than only in the conversation. |\n\nThat is the system in miniature.\n\nIf those five lines already make sense, I would **start there and ignore the rest until something specific hurts**.\n\nThe concrete version — including the tiny files/checklists I mean — is below.\n\nThe concrete HOME / Git / PROJECT_STATE / AI setupAt any point, ask:\n\nIf one answer becomes “I’m not sure,” stop adding changes for a moment.\n\nNot forever. Just long enough to recover the map.\n\nThis 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)).\n\nSo I would treat orientation as something the workflow should preserve.\n\nThe nice thing is that you do not need to know *why* you became lost before you recover.\n\nGoogle’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/)).\n\nGive each one its own small card rather than letting one AI conversation redesign the whole museum around all six.\n\nThe card can use the same five lines every time:\n\n```\nQUESTION:\nKEEP FIXED:\nCHANGE:\nKEEP IT IF:\nGO HOME IF:\n```\n\nThat last line matters. A stop condition prevents “one more tweak” from quietly turning a small experiment back into a project rewrite.\n\n| Original question | Smallest experiment I would run |\n|---|---|\nQ1 — unwanted generated content |\nOne 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. |\nQ2 — cross-scene consistency |\nTwo representative rooms. Compare one stronger shared-state strategy — e.g. shared reference/geometry, Marble Expand, or explicit Compose alignment — against independent generation. |\nQ3 — exterior degradation |\nOne bad exterior. Check where the problem first appears: pano → Marble world → exported SPZ/mesh → Spark. |\nQ4 — painting looks like a decal |\nOne painting. First verify Three.js color handling; then compare your current grading against one local environment-map approach. |\nQ5 — automatic hanging |\nOne difficult wall. Validate the existing three-height test against a small set of manually judged “usable / unusable” positions before making the algorithm cleverer. |\nQ6 — selective spotlight |\nOne painting in HOME. Prototype one local splat edit and measure visual result + frame time before integrating it with the rest of the interaction system. |\n\nThat changes the mental model from:\n\n```\n\"I am rebuilding a complicated 11-scene system\"\n```\n\nto:\n\n```\n\"I am answering one small question,\nthen deciding whether its answer belongs in HOME.\"\n```\n\nAnd every experiment only needs one of three endings:\n\n``` php\nKEEP IT  -> it worked + the small checks still pass -> it can become HOME\nGO HOME  -> it failed or answered the question negatively -> record that and return\nPARK IT  -> interesting but unclear -> save the idea without building on top of it\n```\n\n`PARK IT`\n\nis especially useful with AI: a plausible idea can be remembered without becoming code today.\n\nI would not try to turn questions like these into fake metrics:\n\nThose are design judgments.\n\nWhat I would make precise is:\n\n```\nwhich room\nwhich world\nwhich SPZ\nwhich collider\nwhich code checkpoint\nwhich experiment\nwhich result\n```\n\nThat gives you a nice middle ground:\n\ncreative judgment can remain subjective while the route to each candidate stays recoverable.\n\nA compact handoff is usually enough:\n\n```\nQUESTION:\nHOME:\ncandidate:\nexpected:\nactual:\nshortest reproduction:\nwhat changed:\nwhat stayed fixed:\nscreenshot / golden view:\nrelevant error/log:\nwhat I already tried:\n```\n\nThat 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.\n\nInstead of:\n\n“Please understand this enormous chat and remember what happened three projects ago…”\n\nyou can say:\n\n“Here is HOME. Here is the candidate. Here is the one thing that changed. Here is what I observed.”\n\nIf I were in front of the project tomorrow, I would do this:\n\n```\n1. choose one working room\n2. call it HOME\n3. make one visible code checkpoint\n4. write down the exact SPZ/collider/world that belongs to it\n5. create PROJECT_STATE.md\n6. choose ONE of the six original questions\n7. define the smallest experiment that answers it\n8. tell the AI what it must not change\n9. run the same small checks / fixed views\n10. KEEP IT, GO HOME, or PARK IT\n```\n\nThen repeat.\n\nIf that already stops the project from turning into `final-final-really-final-27`\n\n, I would not add more process.\n\nAnd 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.\n\nThat is much easier to work with than “the whole project no longer fits.”", "url": "https://wpnews.pro/news/suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs", "canonical_source": "https://discuss.huggingface.co/t/suppressing-unwanted-content-without-negative-conditioning-cross-scene-consistency-in-3dgs-and-data-driven-artwork-placement-on-generated-walls/178921#post_4", "published_at": "2026-08-22 01:42:35+00:00", "updated_at": "2026-08-22 02:13:42.074458+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools"], "entities": ["Google"], "alternates": {"html": "https://wpnews.pro/news/suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs", "markdown": "https://wpnews.pro/news/suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs.md", "text": "https://wpnews.pro/news/suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs.txt", "jsonld": "https://wpnews.pro/news/suppressing-unwanted-content-without-negative-conditioning-cross-scene-in-3dgs.jsonld"}}