Do not grade the answer before the question changes.
An edit is a part-level counterfactual intervention. It is not an image
morph, not a deformation applied to the final rendering, and not a
second optimization pass. Each case defines an original procedural target
\(T\), an edited target \(E_T(T,u)\), and a named intention \(u\).
Major trainable surfaces in each program are adjusted using samples from
\(T\) only. A separately authored program executor \(E_P(P,u)\) then
updates that template's primitive parameters. I compare its endpoint with
the edited target. Distinguishing \(E_T\) from \(E_P\) matters: the two
program families do not receive the same low-level parameter update.
The semantic region is known because I control the generator. The
generator names object components, and each program template declares
which primitives belong to each user-facing control. For the mug, the
cup body, rim, foot ring, and attachment pads stay fixed while the side
loop moves outward. For the desk lamp, the base and lower stem stay
fixed while the flexible neck bends downward and carries the lamp head.
For the drawer pull, the face stays fixed while the posts and curved
grip move outward as one pull. I am therefore not claiming to solve
open-world semantic part discovery. I am asking a narrower question:
once a template claims to expose a part control, can an authored executor
for that control produce the intended counterfactual shape?
Defineauthor an original object, an edited target, and a named intention.
Fitadjust the templates' trainable major surfaces using the original only.
Executeapply a family-specific authored parameter mapping for that intention.
Comparescore each edited endpoint against the known edited target.
The crucial—and limiting—step is the edit transfer for the local-piece program.
This template represents the original object with local
SQ pieces whose boundaries do not coincide with the intended semantic
control. The author must distribute the same high-level intention across
several parameter updates. In these examples that distribution is chosen
to illustrate drift. The result therefore establishes a counterexample to
surface-only evaluation, not a causal estimate of what an automatically
learned executor would do.
For example, the semantic-control mug program has a container control and a
handle control. The handle control is implemented as a linked group of
small SQ segments, because that renders a cleaner handle than forcing a
single primitive to do everything. Widening the handle moves that group
coherently: the mounts shift slightly, the outer arc shifts more, and
the loop remains attached. The local-piece mug program uses a
similar-looking set of local SQs, but those pieces are not one edit
control. The same instruction has to be distributed across pieces, and
the authored local executor in this construction is where drift appears.
There is no hidden semantic oracle inside the optimizer. The target
generator provides the part labels, the program templates provide the
primitive-to-control labels, and the edit operator is a deterministic
authored update on those controls. The edit-critical chains are
template-fixed; only selected major surfaces are trainable. The edited
target is excluded from fitting and restart selection, so no program is
re-fit to the edited answer—but the supplied labels and executors mean
this is not a test of part discovery or edit learning.
Inspect the exact edit operators
The actual edit operator
Formally, a program is a list of primitives
\(P=\{(\theta_i,g_i,c_i)\}_i\). The vector \(\theta_i\) stores the SQ
scales, exponents, pose, bend, and taper; \(g_i\) is the procedural
component label used for evaluation; and \(c_i\) is the user-facing
edit control. A family-specific executor \(E_{P,f}\) selects one or more controls and applies
a deterministic parameter update to their primitives. Primitives
outside the edited controls keep their fitted parameters. Primitives
inside them receive prescribed translations, rotations, bends, tapers,
or scale changes. No parameter is reoptimized after this step.
The table below gives the actual local-coordinate executors used by the
page. These constants are hand-authored as part of the controlled
illustration, just like a robotics benchmark might specify a grasp motion
or an articulation target. Both executors aim at the same target-level
intention, but they are separately chosen mappings. That asymmetry is
visible here rather than hidden behind the phrase “same edit.”
Mug: widen handle loop
Target loop: mounts move from x=0.30 to x=0.36; the outer arc moves from x=0.74 to x=0.90.
Semantic executor: mounts use tx += 0.06; handle endpoints use tx += 0.06; mid segments use tx += 0.11; the middle segment uses tx += 0.16 and sx *= 1.06.
Local executor: middle pieces use tx += 0.22 and sx *= 0.92; upper and lower pieces use smaller tx shifts plus opposite z shifts and y rotations.
Desk lamp: bend neck downward
Target lamp: the neck control points move downward; the shade moves tx 0.66->0.80, tz 0.32->0.16, and ry 0.46->0.63.
Semantic executor: linked neck pieces receive increasing offsets along the curve: lower tx += 0.02, tz -= 0.06; middle tx += 0.08, tz -= 0.11; upper tx += 0.16, tz -= 0.16. The shade group changes pose; the opening and bulb keep fixed local offsets inside the shade.
Local executor: every local neck piece gets rx += 0.14, then lower/middle/upper pieces receive different tx, tz, and ry offsets.
Drawer pull: pull handle outward
Target pull: drawer face stays fixed; the pull control moves from y=-0.12 to y=-0.28.
Semantic executor: posts use ty -= 0.08 and sx *= 1.55; the curved bar uses ty -= 0.18 and sz *= 1.05.
Local executor: middle local pieces use ty -= 0.22 and rz += 0.08; side pieces use ty -= 0.10 with opposite x rotations.