0ce626ad422fcb430e5a7d25df4dc4333a9e1c46
98
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Nicholas Butzke
|
0ce626ad42 | jump ani fixing and transition animations | ||
|
Nicholas Butzke
|
833e936bcd | ani fixed | ||
|
Nicholas Butzke
|
9358746582 | ani | ||
|
Nicholas Butzke
|
922983429e | big | ||
|
Nicholas ButzkeandClaude Opus 5
|
61669627db |
chore(debug): track the UID Godot generated for menu_capture.gd
Godot writes a .uid sidecar for every script and this one landed after the commit that added debug/menu_capture.gd. All 140 of the others are in version control; an untracked one drifts to a different UID on the next machine that imports the project. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
2efc21b18d |
feat(menu): PLAY is one press, and the level cards are photographs
Reaching a game was Singleplayer → pick a level. Reaching a multiplayer game
was Multiplayer → Host Game → wait → pick a level → wait, and the gamemode
dropdown had exactly one entry which set a string nothing read.
PLAY now starts the last map and mode played, and says which — "Akiba Crossing
• Deathmatch" under the button, so pressing it is a promise rather than a leap.
Everything else on the home screen is a detour from that, which is the right
shape for a menu: the common case is a button, not a path. Hosting is one press
and lands in the lobby already hosting; the lobby puts map, mode, players and
start on ONE screen; Enter connects, so typing an address does not then require
reaching for the mouse.
This is the lesson HoYoverse published about Zenless Zone Zero's first months
more loudly than anything else they have written. Their postmortem on the TV
mode names three complaints — it took too long, it sat between the player and
the combat, and there was too much of it early — and 1.2 removed it from the
story entirely rather than shortening it. Time spent BEFORE the thing the
player came for is not neutral, it is a cost.
The cards were a two-stop gradient generated from two colours in a meta file,
whose hover state was `use_hdr = true` — not a visible change on any of them.
They are photographs now, shot by debug/map_preview_capture.gd, which took
three attempts to get right and each attempt is a comment in the file:
- framing each map from OUTSIDE by merging every VisualInstance3D's AABB
produced five tiny dioramas floating on a table, and one solid black
rectangle. That is a minimap, and a minimap is not a photograph.
- standing at a spawn point fixed three maps and left two black: fps_blockout
is genuinely dark and most of its spawns face an unlit wall, and
procedural_arena builds its geometry at runtime so no fixed offset is
reliably inside it.
- so the tool now RENDERS several vantages and scores each result — mean
luminance times its standard deviation, because brightness alone picks the
empty sky and variance alone picks a high-contrast corner of a dark room.
Their product picks a photograph. A black rectangle passes any check that
only asks whether the camera ended up somewhere sensible.
Also fixed, and caught by looking at the screenshot: the selected mode chip was
unreadable. Its glyph is ink on volt, and the theme gave every button a 5 px INK
outline — an ink glyph inside an ink outline is not outlined, it is five pixels
fatter, and on a small chip that is a solid blob. Button labels now carry no
outline at all, which is the same reasoning debug/ui_contrast_check.gd already
encodes: an outline separates a glyph from a backdrop it cannot beat alone, and
a label on a solid chip does not have that problem. The chips keep their heavy
ink border, so nothing about the drawn look changes.
`current_gamemode` is normalised on the way in, because it used to hold a
display string and six callers still pass one. An unrecognised id compares
unequal to GameMode.GUN_GAME and would silently disable that mode's weapon
issuing — half a mode is worse than none.
The menu's background character is the player's OWN skin holding their weapon,
rather than the box-and-capsule mannequin that stood there before.
spawn smoke 0, game modes 30/30, movement 11/11, contrast 108/108, HUD layout
PASS, weapon holds 0, dances 0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
986179854d |
feat(modes): matches now end, and something is at stake when they do
There was a string — `current_gamemode`, always "Deathmatch" — an OptionButton
with one entry in it, and a five-minute timer that counted to zero, set
`match_active = false`, and did nothing else. No winner was declared, no summary
appeared, the clock froze at 00:00, and players carried on shooting each other
in a match that had stopped counting. Nothing was tracked beyond a running kill
count. A match did not end so much as stop mattering, and everything a player
does in the last minute only matters if there is a last minute.
globals/game_mode.gd answers the three questions a mode has to answer — how you
score, when it ends, who won — for three modes:
Deathmatch 25 frags or 10 minutes.
Team Deathmatch two squads to 50, teams balanced by COUNT on join (a 4v4
that loses three from one side must refill the short side;
round-robin on join order leaves it 4v1 forever), friendly
fire off and enforced on the server before damage is even
broadcast — a mode where the damage lands but the kill does
not count is worse than either.
Gun Game every kill promotes you a rung and swaps your weapon. The
score IS the rung and the limit IS the ladder's length, so
finishing the ladder and reaching the score limit are the
same event and only one win condition exists.
`check_win` is a pure function of the stats and the clock, deliberately, because
a win condition that can only be exercised by playing a whole match is one
nobody tests — and the previous one never was. debug/game_mode_check.gd runs 30
cases over it: a tie is a DRAW rather than a win for whoever came first out of
the dictionary; a team match is decided on the TEAM's total, which a per-player
check never reaches; every ladder rung names a weapon that exists, or that rung
softlocks the mode; and promoting past the top clamps, because the winning kill
promotes before the match-end RPC lands.
Tracking now covers score, team, current streak, best streak and ladder rung.
Score and kills are separate numbers because in Gun Game they coincide and in
anything with an objective they would not. The scoreboard ranks by score, shows
the mode's own noun for it, and puts the limit on the top line — a win condition
players cannot see is one they cannot play toward.
ui/match_summary.gd gives the ending somewhere to happen: who won, WHY (time and
frag limit are different stories about the same scoreline), team totals, full
standings, and a way out that is not alt-F4. Play Again is host-only on a server.
Three bugs found on the way, all of which only became bugs once matches could
actually end: loading a level reset the clock but not the scores, so the second
match on a server would have ended on its first kill; `.rpc()` on an offline
peer does not call locally, so singleplayer had no killfeed and no stat sync at
all; and a rocket already in the air at the whistle could change the result
after the summary was on screen.
spawn smoke 0, game modes 30/30, movement 11/11.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
f1a4f7df52 |
feat(emotes): five dances, built like animation, behind a radial dial
The shared clip library ships exactly one `Dance_Loop`, and five copies of one
clip is not five dances. What the runtime does have is a procedural pose layer
over a real skeleton with spring-driven hair and cloth, which is enough — if
the motion is constructed the way an animator would construct it rather than
the way a programmer reaches for first.
Wiring sine waves to bones is that first reach, and everyone can tell. A raw
sine moves fastest through the middle and slowest at the ends by the same
amount on every channel, all in phase, forever. It floats. It has no weight, no
accent, and no sense that one part of the body is driving and the rest is
following. Four principles fix it, and all four are cheap:
OVERLAP the body is a chain. Hips lead, spine follows a beat later,
head last. One subtraction — `beat - lag * i` — and the spring
solver then carries it out through the hair and skirt for free,
because the dance layer runs before it.
ACCENT a dance HITS poses. `shape` bends the wave so it hangs at the
extremes and snaps between them, which is what a key-and-
breakdown pass produces by hand.
WEIGHT the HIPS translate, not just rotate. A body that never leaves
its own axis reads as a puppet on a stick.
CONTRAST Robot deliberately breaks all of the above — zero lag,
quantised motion — and reads as mechanical precisely because
the other four do not.
Spin spots its head: it holds a heading against the turn and whips round to
catch up, which is what a real dancer does to keep from getting dizzy and the
most recognisable thing about a turn.
The dial is a radial menu because every option is then the SAME DISTANCE from
where the pointer starts — the choice is a direction, and a direction becomes
muscle memory in a way "the fourth row down" does not. Selection is by ANGLE
alone, so a flick and a careful nudge do the same thing. HOLD to open, release
to commit; a tap too short to have aimed replays the last emote, which is what
the button did before, so the old habit still works. Pressing while already
dancing just stops — having to aim at something in order to STOP would be the
most annoying possible way to build this.
debug/dance_check.gd asserts the overlap, and getting it to measure that took
four wrong measurements, each of which is now a comment where it was made:
- correlating the hips' TRANSLATION against the head's position relative to
them compared two different quantities at different periods; it ranked the
Robot, whose lag is zero by construction, as the most overlapped routine.
- a signed scalar `angle * sign of the axis's largest component` is
DISCONTINUOUS — as a rocking bone passes back through rest the axis flips —
so smooth Two-Step measured a full-range jump per frame, which is exactly
what quantised motion looks like.
- a bone's GLOBAL rotation carries every ancestor's, so the head correlates
with the hips at lag zero however delayed the head itself is.
- and the hips and head are driven by different channels anyway.
Measuring two links of the SAME chain, as local rotation vectors, agrees with
the authored lag: Spin measures 9 frames against 8.4 authored, Two-Step 7
against 6.6, Robot 0. The Robot is checked on the property it actually has —
its jump per frame is 0.41 of its range against 0.03-0.06 for the others.
RigRoles is pulled out of ShooterPoseModifier so the dance layer resolves bones
the same way rather than carrying a second copy. Two copies is how a rig ends up
animating correctly under one modifier and not the other.
spawn smoke 0 failures, 11/11 movement, 21/21 weapon-hold pairs, contrast 108/108.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
a13ae50f95 |
feat(rig): every weapon gets its own hold, so the silhouette names the gun
`_apply_rifle_hold` did exactly what its name said, to everything. A knife, an
AWP and a rocket launcher were all solved as a rifle — stock in the shoulder
pocket, support hand out along the barrel, muzzle on the aim line — so in third
person every character stood the same way whatever they carried, and the only
thing distinguishing a sniper from a shotgun was the ~30 cm of gun mesh in
their hands. At the distance an enemy is usually seen that is nothing.
It costs more than looking wrong. A character's pose is the fastest available
answer to "what is about to happen to me": a tube on a shoulder means take
cover, a blade held low means they have to close, a rifle at low ready means
they have not seen you. One hold throws all of that away. It is also the thing
HoYoverse's team say they chase in Zenless Zone Zero — characters read by
silhouette first, and they refuse to settle on one construction method because
one method limits how distinguishable the results can be.
weapons/weapon_hold_profiles.gd gives each of the twelve weapons a style, and a
style is not a bundle of slider values. Three of its differences cannot be
expressed on the rifle solve at all, and those are the ones that carry:
support WHERE the off hand goes and HOW IT IS TURNED there — wrapped round
a handguard, cupped against the firing fist, hooked under a tube
palm-up, or released entirely. Sending a hand somewhere new without
re-orienting it gives a hand teleported to the new spot still shaped
for the old one.
mount whether the weapon's rear sits IN the shoulder pocket, ON TOP of the
shoulder, or nowhere near it.
head whether the head comes down to the stock, or leans away to clear a
tube. The cheek weld is the sniper silhouette, and its inverse is
what says a launcher is resting on that shoulder.
A blade RELEASES the off arm back to the animation, so it swings with the run
cycle instead of gripping a handguard that is not there — most of what makes a
one-handed weapon read as one-handed — and closes a full fist, because an index
left straight along a knife handle reads as a mistake, not as discipline.
Layered strictly UNDER the existing tuning, so aria's hand-tuned AK-47 hold is
byte-for-byte what it was. WeaponHoldTuning.default_for is weapon-aware now,
which it had to be: the rig lab SAVES every knob it shows, so without it,
opening the lab on the knife and pressing save would silently overwrite the
blade profile with the rifle spec and put the character back to holding a knife
like an AK with nothing to indicate it had happened.
debug/weapon_hold_check.gd asserts the consequence, not the plumbing — storing
an enum and reading it back proves nothing. It measures where the hands and head
ACTUALLY end up, from inside the modifier pass (outside it, Godot restores the
local poses and every weapon reports an identical rifle) and in the shoulder's
own frame, because the hold breathes and two samples of the SAME weapon
otherwise differ by more than two different weapons do. 21 weapon pairs, all
distinguishable; the knife's off-hand weight measured at 0.01.
Two findings only measuring produced. Pushing `gun_fore` further out for the
sniper does NOTHING — the reach solver slides the support hand back down the
handguard until the arm can get there, so it landed at 0.388 m against the
rifle's 0.387. Raising the whole weapon is what makes a scoped rifle read.
And one only LOOKING produced, via debug/hold_capture.gd: the shotgun's barrel
passed through the character's chest. Every assertion passed — the hands were
exactly where they had been asked to go — but +x is toward the centreline, so
dropping the pocket and pushing it across at once swings the muzzle into the
torso.
rig_anchor_check still reports aria: her hand-tuned wrist rotates the anchor
offset. Pre-existing, and this halves it — it was 2 failures on main, now 1.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
c4bcbc7fd1 |
feat(ui): the first-person HUD is one thing, in the game's own hand
The reticle was five white ColorRects, pasted byte-identically into three
level runtime scripts. The vitals were two stock ProgressBars with a flat
colour override, inlined 1200 lines into the movement controller. The ammo
count — the number a shooter's player looks at most — was drawn by the LEVEL,
in a black rounded panel that shared nothing with the menus, and it had a
special case in it (`elif active_weapon is DoubleBarrelShotgun`) because that
weapon never declared a name or a capacity.
Everything that describes A PLAYER now belongs to ui/player_hud.gd, and a
level owns the level. The immediate symptom that fixed: the screen had two
ammo panels on it at once, in two different styles, overlapping in the corner.
What each piece now says, rather than merely shows:
ui/crosshair.gd one drawn reticle instead of five rectangles, so it can
BLOOM — open with speed, airtime and each shot, snap shut
on ADS. That is the accuracy readout of the whole game and
five ColorRects could not express it. Every stroke is
drawn twice, ink underneath, because a 2 px white line
disappears over pale concrete exactly when aim matters.
The hit confirmation is the same cross at 45 degrees, so
it lands where the eye already is.
ui/vital_bar.gd segmented, so remaining health can be COUNTED rather than
estimated, with a drain ghost that holds the old value for
a beat — the gap between fill and ghost is the size of the
hit, which a bar that merely gets shorter never tells you.
ui/ability_chip.gd dash and grapple as a wipe across a chip rather than a
tinted JPEG with a 12 px number under it. A shape changing
size is readable in peripheral vision; 12 px type is not.
chain meter promoted out of the debug panel. Movement is this game's
first stated pillar and chaining is its skill expression,
so the count is a score, not a diagnostic.
The numerals moved OFF the bars and beside them. Text centred on a two-tone
bar cannot be given a colour that beats both the fill and the trough — that is
the 2.4:1 debug/ui_contrast_check.gd measured on the old HUD — so this fixes it
at the source rather than leaning on an outline to rescue it.
debug/hud_layout_check.gd measures where every element actually lands, which is
how three real bugs were found rather than squinted at: `set_anchors_preset`
moves the anchors and LEAVES THE OFFSETS, so the reticle spanned the viewport
with a size of exactly (0,0) and drew itself in the top-left corner; a
PRESET_CENTER applied after the ring's own `_ready` undid its centring; and a
BOX CONTAINER's own `alignment` is what pushes content to an edge, not a
SHRINK_END flag on the box, whose minimum width depends on children that may be
hidden. The ammo card was hanging off the right edge of the screen because of
the last one.
DoubleBarrelShotgun now declares `weapon_name` and `max_shells` like every
other weapon, and the four inline `2`s are gone.
spawn smoke 0 failures, 11/11 movement tests, contrast 108/108, layout PASS.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
414026f001 |
feat(ui): every control state is checked for readability, not trusted
The palette has two light accents and one very dark one, and a control changes its FILL on hover and press. Paper text that reads at 18:1 on the resting near-black chip inverts to paper-on-yellow the moment the pointer arrives, which is 1.1:1 — invisible. That is the standard way a stylised UI becomes unreadable, and it was live on the OptionButton dropdown that every settings row uses: PopupMenu draws its papaya hover fill but keeps `font_color` unless `font_hover_color` is set, and it was not set. So the label now follows the fill. `ink_for(fill)` picks the legible glyph colour by contrast ratio, and every state's text, icon and outline is derived from its own fill through it — including the states nobody remembers exist: `hover_pressed` on a toggle (a CheckButton read as OFF while you touched it), icon colours on a CheckBox that is all icon, and the list hover that used to be the same papaya as list SELECTION, so the row you pointed at looked like the row you had chosen. debug/ui_contrast_check.gd interrogates the BUILT theme rather than the palette — a table compared against itself agrees by construction and catches nothing — and fails below the WCAG floor. It found the PopupMenu gap, a Tree hover asking for a `font_hovered_color` Godot does not have, and the health bar's readout at 2.4:1 over its own fill. That last one is not fixable as a colour pair: a centred readout straddles a hot papaya fill and a near-black trough, and no single colour beats both. What carries it is the heavy ink outline this theme puts on every glyph, which is its first stated rule and the same mechanism that keeps menu text legible straight over the 3D scene. The check models that as a fallback route — outline vs backdrop 3:1, glyph vs outline 4.5:1, at least 4 px — granted only where the backdrop genuinely varies, and substituting two ratios for one rather than waiving the requirement. Disabled text moves from 3.2:1 to 5.2:1 on the way past. A greyed-out "Start Match" is information; an illegible smudge is not. Also styled, because the theme had simply never mentioned them and Godot's defaults are grey-on-grey: scrollbars, Tree, SpinBox, ProgressBar, tooltips, LineEdit read-only and selected text. 108 pairs checked, all passing. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
742d68e318 |
chore(characters): Aria's AK-47 hold, tuned in the lab
The first tuning pass saved through the rig lab, and the first content in assets/characters/weapon_holds.json. Aria holding the AK-47 at low ready: weapon scaled to 0.53, both wrists set, both elbow poles placed, and both hands moved along and off the barrel line. Authored by hand at the sliders, not derived — which is the whole point of the file. Every value here is one the code cannot work out from the skeleton, and the layering means it applies to this character and this weapon only; every other character still gets what the code derives. Also picks up the .uid Godot generated for debug/wrist_gun_check.gd, which was committed a moment before its companion existed. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
e97de9aafd |
fix(weapons): the wrist turns the hand, and the gun stays on the aim line
The weapon is a child of a BoneAttachment3D on the trigger hand, so the two were welded by construction. Every degree `wrist_r` turned swung the barrel the same degree off the aim line — and took with it every control that could have corrected for it, because they are all expressed relative to that same hand. There was no combination of sliders that aligned a hand to a gun, which is the one thing the knob exists for. Both outcomes are now computed where the hand's local pose is set: the rotation the hand would take without the wrist offset, and the one it takes with it. The hand gets the second; the difference between them is exactly the counter-rotation the weapon mount needs, in the hand's own local frame, and `SkinnedPlayerModel._hold_weapon_still` applies it to the mount each frame. The gun ends up precisely where the solver put it. That also gives the two controls a clean split, which is what makes them usable together: TRIGGER / SUPPORT WRIST (hold) turns the HAND, gun stays on the aim line Grip roll / pitch / yaw (anchors) turns the GUN inside the hand Identity when `wrist_r` is untuned, so a character nobody has tuned mounts its weapon exactly as before. Applied in `_process` rather than inside the modifier pass on purpose. The gun's mount is not something the skeleton owns, and the compensated value only changes when a slider moves or the ADS blend travels, so one frame of lag is a fraction of a degree; reaching into the modifier to touch a scene node would be worse. wrist_gun_check asserts both halves, because only asserting the first is how this shipped broken: the hand must TURN, or the knob does nothing, and the gun must NOT, or the knob cannot be used. Across both poses and all three axes the hand turns 28.2-28.7 degrees for a 0.5 rad knob and the gun moves 0.1-0.6 — against the ~28 it would move if it were still following the wrist. The residue is the arm's own IK settling, since the hand's rotation feeds the chain that places the shoulder. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
a97ccca13c |
feat(rig lab): wrists in three axes, and sliders that belong to the pose on screen
Three things the lab could not do. WRISTS. Each hand had one scalar, a twist about the barrel. That is the only axis a hand wrapping a cylinder is free in ONCE the arc onto the barrel is solved — which is true of the support hand, was never true of the trigger hand, and in neither case left a way to cock a wrist forward or break it inward. Both now take pitch, yaw and roll, applied in the GUN's frame so the three sliders mean the same thing whether the muzzle is down at low ready or level down the sights. Zero is exactly the old behaviour, since the roll term defaulted to zero too. HAND POINTS. `gun_stock` and `gun_fore` are the distances along the weapon at which each hand sits, and they were labelled by what they measure rather than by whose hand it is. They now say TRIGGER and SUPPORT, next to the off-barrel shifts for the same two hands, so the four controls that place a hand read as four controls that place a hand. POSES. The hold's knobs are now per pose, and the lab shows one pose's at a time. Half of them mean something different at low ready than down the sights; showing both sets at once meant every slider on screen was for one of two poses with nothing saying which. Selecting a pose rebuilds the panel. Two poses, not four, and deliberately: the runtime blends between exactly two holds on `ads`. Running and Crouched are locomotion states that still use the low-ready hold, so they edit the same numbers — and the heading says so, rather than letting someone tune "Running" and wonder why standing still changed. Offering four independent tunings would be inventing a capability the code does not have, and the fourth would silently do nothing. `pitch` is the case that forced the design: down the sights the muzzle follows the CAMERA, so there is nothing there to tune. It exists at low ready and nowhere else, and a spec table where a knob names the poses it applies to is what lets that be said instead of shipping a control that does nothing. hold_pose_check asserts both halves — that no pose shows another's knobs, that aiming offers no muzzle pitch, that the heading names the hold being edited, and that all twelve wrist axes turn the hand they name. Its first version reported every wrist axis as moving the hand by 0.0 degrees, which is precisely the answer it would have given if the wrists had never been implemented: it read `get_bone_pose_rotation` from a SceneTree script, and Godot restores every bone's local pose after the modifier pass. The repo has a reference section about exactly this and it still cost a cycle. Measured through a PoseProbe, every axis turns its hand ~20 degrees. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
b1c8bab714 |
feat(rig lab): drag the anchors themselves, not just the gun under them
The lab could move the GUN and not the anchor points the hands are solved onto. `grip_offset` slides the weapon around inside the fist; `gun_fore` and `gun_stock` are distances ALONG the barrel, so the trigger and support hands could travel up and down the weapon's own axis and nowhere else. Nothing could take a hand off that axis, which is what a handguard below the bore, an angled foregrip, or a pistol whose grip is nowhere near its barrel line all need. Two things fix that. `grip_shift` and `fore_shift` give the two hand anchors real three-dimensional freedom, expressed in the GUN's own across/up/along frame so a sideways nudge stays sideways as the weapon pitches between low ready and ADS. Zero is exactly the old behaviour. Their z overlaps the along-axis distances, which is redundant and deliberate: keeping those separate is what lets the reach solver slide the support hand back down the handguard without undoing a considered sideways offset. And the markers are now draggable. They already showed the anchors; now they are handles. The one under the mouse swells and draws through the body — depth testing is right for judging whether a hand reached its target and wrong for a handle, because at any useful framing the hands occlude all three. Verified three ways, and each one had to be rebuilt once: anchor_shift_check first compared absolute positions and reported a 3.5 mm error that was the character BREATHING — there is a sin() on the muzzle pitch, so no anchor is ever in the same place twice. Measuring each anchor relative to the one it hangs off, rotated into the current gun basis, cancels the breathing, the ADS blend and the recoil exactly. 48 checks, six characters, both poses. anchor_drag_check asserts the drag writes the knob the MOUSE asked for, derived independently from the camera: 0.00-0.01 mm on all three. It does not assert the marker lands under the cursor, because it does not — the anchors hang off the shoulder and the arm chasing them moves the shoulder, so a drag settles at 0.77x-1.13x. Small enough to ignore interactively. That feedback first read as 1.5x-1.8x, because the cases were compounding on each other, and waiting LONGER for the pose to settle made it worse rather than better — which is the opposite of how a settling error behaves and is what gave it away. The buttstock case also failed for a while on a bug entirely in the test: it read an absent knob as zero when `pocket_hip` defaults to (30, -70, 60) mm. The lab has a note about that trap in `_reset`. It is just as easy to walk into from a test, and now has one there too. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
700d0925d7 |
tools: measure rest poses, and diagnose momo
momo's idle plays with her arms overhead and her waist pinched, and every assertion in the suite passes on her. The first suspicion was the retarget's rest-relative delta: it applies "what the clip does to the LIBRARY's rest" to THIS rig's rest, which quietly assumes the two rests are alike. rest_pose_check.gd tests that, and disproves it — miku's arms rest 41° off the library's and taila's 32°, and both animate correctly. The delta retarget handles a rest-pose difference, which is what it is for. Recorded in the reference so nobody spends that hour again. Writing the tool reproduced this project's own recurring mistake in miniature. Measuring "the direction from a bone to its first child" reported kiyoko's and aria's legs 71° off the library — because a thigh's first child is as likely to be a skirt bone as a shin, and it was measuring the hang of a skirt panel. Pointing it at the next limb BY ROLE dropped both to 1°. What momo actually has: `Root_001` through `Root_007` are in her driven_bones, and they are her HAIR roots — Hair_A is dominated by Root_001_001, Root_007 and Root_005. The animation is keying bones the spring solver is supposed to own, which is non-negotiable #2 broken by the role resolver rather than by a clip. The surface table corroborates it: her hair surfaces report 1.8% and 9.4% chain share, because most of their vertices belong to bones in no chain at all. Not fixed here. `Root_00N` matches no COSMETIC stem, and adding "root" to the stems would cost a rig whose actual root is called `Root` its hips. The structural fix is that a bone whose geometry is dominated by a mesh classified `hair` is a hair bone whatever it is called — which the surface table makes answerable at build time, and did not when momo was imported. It needs a Blender re-run and re-verification of all six characters. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
1e6f3001ac |
docs(skill): the surface table, rig anchors, and asserting the consequence
The skill is this project's own instructions, and three commits made it wrong:
it described a runtime that re-guessed what every surface was, a lab that only
tuned weapon holds, and a suite that could not see any of the last five defects.
It also still listed a seventh character that is not in skins.json.
Records what is new — the surface table and how it is decided, the layered
tuning files and why a fixed rotation on the weapon mount is the wrong answer,
the rig lab — and what the work taught:
* assert the CONSEQUENCE. Asking a model which clip it is playing reads a
variable it set on itself, and says "Idle" just as happily when nothing is
ticking. Asking whether an anchor saved says nothing about whether the gun
moved.
* four of the last five real defects came from looking at a PNG. Every one of
them passed every assertion.
* the line-work rule now exists twice, at build time and as the runtime
fallback, and they must be changed together or a model with a surface table
starts rendering differently from one without.
Also records momo's broken idle and the stray Icosphere under known-unsolved,
with what is worth suspecting first in each case, since neither is fixed.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
99a2ee131d |
style(ui): the last hand-rolled colours join the theme
Five screen titles in the main menu were white on a black outline and the HUD used Color.BLACK outlines and a hardcoded grey. That was the old comic theme's contrast trick, and next to a papaya wordmark it read as a different game's menu. They take UITheme.PAPAYA, INK and PAPER_DIM now, so every screen — main menu, pause menu, character picker, settings, HUD and rig lab — is one palette with one source. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
08ae85b286 |
feat(characters): rig anchors, and a lab that edits any tuning group
The weapon lab could tune how a character HOLDS a gun. It could not tune where
the gun sits in the hand, and that is a different question with a different
scope: a hold is per character and weapon, an anchor is a fact about the hand.
RigAnchors adds it. A hand bone's origin is the WRIST, not the palm, and how far
down the palm a grip should sit — and how the gun rolls in the fingers — depends
on how big that character's hand is and how the artist posed the thumb. It
cannot be derived, it differs per character, and it is small. So it is an offset
that defaults to identity, and identity means exactly what the code derived
before anchors existed: an untuned character is bit-for-bit unchanged.
Deliberately NOT a fixed rotation on the mount. There used to be one, and a bone
attachment is expressed in the BONE's axes, which no two rigs agree on — that
constant is why the hand mount points were wrong on every character. The derived
mount stays derived; the anchor is a nudge on top of it, and nothing here spells
a bone name.
The layering, the JSON round trip and the res://-then-user:// write are now
TuningStore, because none of that was ever specific to weapons and two copies of
it would mean two places for "an exported build's tuning pass is silently
discarded" to come back. WeaponHoldTuning is built on it with its file format
unchanged.
The lab is a rig lab now, and it grew three things:
ANCHORS a second knob group. It cost a spec table — everything in the lab is
written against "which specs, which file, keyed on what" rather than
twice against the two groups, so anchors got sliders, live preview,
reset, save and clipboard for free. A third group is a third row in
GROUPS.
CLIP audition one animation on its own. The four pose buttons are the
states the game drives; watching a whole clip end to end is how you
see where a retarget went wrong, and there was no way to do it.
SURFACES what the importer decided each surface IS, and a click to isolate a
class. Isolating is how the decision gets CHECKED: click `hair` and
anything else still standing was misclassified. Hidden by swapping
in a transparent material rather than hiding the node, because a
mesh is not one class — Miku's body, face and hair are three
surfaces of one mesh.
And it takes the game's theme, applied to its own panel rather than only to the
Window, for the same reason the pause menu needed it: a CanvasLayer is not a
Control, so theme inheritance stops at one.
debug/rig_anchor_check.gd asserts the physical consequence rather than the
plumbing — an anchor system is easy to build so that the sliders move, the file
saves, the JSON round-trips and the gun does not budge. All six characters move
their weapon by exactly the offset asked for, measured in the attachment's frame
because a world-space delta on an animating skeleton is mostly the idle
animation, and all six return exactly to the derived mount when it is cleared.
Also fixes BoltRule, whose zigzag was self-intersecting: draw_colored_polygon
triangulates, and a crossing outline fails triangulation and draws nothing at
all except a console full of "Invalid polygon data". Same silhouette, walked as
a closed loop, with the ink edge as a polyline rather than a grown polygon —
growing a concave shape from its centroid reintroduces the crossing.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
26f7c2c622 |
feat(ui): one high-voltage theme, and pick your character from the escape menu
The theme was a comic one — cream paper, ink borders, papaya. It is now a charged one: near-black violet, hot papaya, and a lightning yellow spent nowhere except the instant a button is pressed. Chips are cut with two sharp corners and two round ones on a diagonal, which is as close to a skew as a StyleBoxFlat gets and is the difference between a button that reads calm and one that reads fast. BoltRule draws the motif itself, struck a third of the way along its rule rather than centred, so it reads as something that HIT the line. The pause menu was 900 lines of hand-rolled UI that never referenced UITheme at all, so it rendered in Godot's default grey. It now applies the theme — and applies it to its own root Control, not only to the Window, because a Control inherits from its nearest Control ANCESTOR and this screen hangs off a CanvasLayer, which is not one. That was invisible at first: the parts built with UITheme.title() carry their own overrides and looked right next to a list and a button that did not. And it now has a Character screen. The roster on the left, the character themselves on the right, turning — a name in a dropdown is not a character selection screen. The preview is a real SkinnedPlayerModel in its own world, so it shows exactly what will spawn: the same cel look, the same per-class outlines, the same cloth and hair on springs. Selecting applies immediately; there is nothing destructive to confirm, and applying on selection means the character behind the menu changes as you arrow the list, which IS the comparison. PlayerMovementController.set_skin() is the supported way in. Both halves of a skin change are easy to do by halves — `synced_skin_id` is what REMOTE peers rebuild from, and only their _process watches it, so setting the property alone would change everyone else's view of you and not your own. Checked rather than asserted. debug/character_picker_check.gd walks the whole roster and proves each entry loads a skeleton, animations, a surface table and body surfaces — and that the skeleton is MOVING, because the clip name is a variable this class sets on itself and reads "Idle" just as happily when nothing is ticking. debug/ui_capture.gd and debug/roster_capture.gd photograph the screens and every character, which is how three things were found that no assertion could see: the theme break above, a preview showing the back of the character's head, and a turntable that carried on from the last character so the third one you looked at was side-on. Known and not fixed here: momo's idle pose is wrong — arms overhead and a pinched waist. Her rig, not the picker; every other character is correct. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
53f175ed6d |
feat(characters): say what every surface IS, and light it accordingly
A character has arrived as separate body, garment and hair meshes since the
pipeline stopped joining them — but nothing recorded which was which, so every
system downstream re-guessed from the material. That guess ("untextured and
nearly black means ink") had already rendered the mannequin's flat yellow body
as a black silhouette once.
The question is answerable once, at build time, where the mesh, the weights and
the skeleton are all in hand. tools/surface_map.py answers it three ways, in
order of how much it trusts them: the material name, which on VRoid exports is
formal and on hand-authored models is still explicit; the weights, which are
decisive when the name says nothing — a surface pulled by the skirt chain is a
skirt whatever it is called; and the material flags, which catch the model's own
line-work. The answer goes in the rig sidecar next to the roles and the chains,
and SkinSurfaces reads it.
All eighteen of Taila's surfaces, and every surface of the other five skins,
now resolve from the table with nothing falling through to the heuristic
(debug/surface_class_check.gd). The heuristic stays as the fallback, which is
the one job it was ever right for.
What that buys immediately is per-class art direction, which was impossible
while every surface had to take numbers calibrated on skin. Hair takes a much
thinner line — at the body's 5 mm each strand's hull swallows its neighbour and
the head reads as a solid dark cap. Cloth takes a heavier line and a crisper
terminator, because a garment's silhouette is most of what separates a character
from the background at range. Accessories take the heaviest. `body` is unchanged
on purpose, so the look this was all calibrated against does not move.
That required moving the outline from the instance to the surface: Miku's body,
face and hair are three surfaces of ONE mesh, so an instance-wide overlay could
only ever give all three the same weight.
Two things found on the way, fixed here because they are one line each: the
surface classifier skips meshes with no vertex groups, which drops the stray
42-vertex Icosphere that rides inside every shipped skin — two older tools
already skipped it by spelling its name — and load_model now clears _rig_info,
which a model with no skeleton used to inherit from the last character loaded.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
33d07b3717 |
feat(tools): a weapon hold lab for tuning each character's grip in 3D
I have been guessing at numbers that want an eye on them. This is the environment to set them instead. godot --path . res://debug/weapon_lab.tscn Pick a character, pick a weapon, pick a pose, drag sliders, press Save. Thirteen knobs — weapon size, support-hand distance along the barrel, grip to buttstock, muzzle pitch at low ready, both wrist rolls, three finger curl amounts, the stock pocket for low-ready and for aiming, and both elbow poles. Three markers show the points being solved for: red trigger grip, green support hand, blue buttstock. If a hand is not ON its marker the IK could not reach it, which is a different problem from the marker being in the wrong place, and the two used to be indistinguishable. Results land in assets/characters/weapon_holds.json, resolved in layers so a number can be set once and contradicted where it matters: defaults every character, every weapon skins.<skin>._all this character, every weapon skins.<skin>.<weapon> this character, this weapon An empty file means "use what the code derives", so the game runs exactly as before until something is actually tuned. The knobs that CAN be derived from the skeleton still are — mount rotation, wrist frame, weapon size — and their sliders read "auto" at zero rather than silently overriding. Two things this had to get right to be honest rather than merely present. Slider defaults come from the same table as the code defaults, because a slider parked at 0 beside a code default of 1.0 means the first touch of that slider silently switches finger curl off. And the markers are depth-tested: drawn through the body they look like they are floating in front of the chest when they are really behind an arm, which is the exact wrong impression for judging whether a hand is on its target. `-- shot <path> [skin] [weapon]` renders one framed close-up and quits, so the lab can be checked without a human at the controls — which is how both of those bugs were caught. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
2a6b321984 |
fix(weapons): orient the support hand by frame, not by arc plus a twist
The support hand was upside down on the handguard. Its rotation was built as a shortest arc from the hand's forearm line to the barrel, plus a constant 0.5 rad twist. A shortest arc is the MINIMAL rotation between two directions and says nothing at all about roll, so the entire roll of that hand came from the constant — and a constant is right only for the one rig it was tuned against. Orienting a hand onto something it grips is a frame-to-frame problem, and saying it that way leaves nothing free to guess. A hand wrapping a cylinder has its curl axis along that cylinder, or the fingers close across the handguard rather than around it; and its palm faces the cylinder, which for a hand supporting from underneath means up. The third axis falls out of the other two. Map the hand's rest anatomical frame onto that target and the roll is determined rather than chosen. The frame is the same one the finger curl already uses — along, palm, curl — now stored whole instead of just its curl axis. Verified by render on the mannequin (Rigify names, 0.524 m arm) and Kiyoko (VRoid names, 0.470 m): fingers wrap the handguard from below and over the top, stock at the shoulder, arms not crossing, consistent across idle, ADS and run. L_HAND_TWIST is deleted rather than retuned — it was the bug. Smoke 0 failures. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
daed7ab980 |
chore(characters): regenerate every sidecar with the finger table
The finger roles only reach the runtime through <model>.rig.json, so a character whose sidecar predates them keeps flat, open hands however good the pose layer is. Aria, Momo, Miku and the Mannequin re-imported; all six skins now carry 10 finger chains. Verified on the Mannequin, which is untextured and so the clearest diagnostic of the three checked: stock at the shoulder, trigger hand on the grip, support hand out on the handguard, both fists closed, arms not crossing. Its arm is a full 0.524 m against Taila's 0.468 and it scales the weapon independently — 0.231 m of hand separation against her 0.217 — with the slide-back loop never firing on either. Known remaining: the support hand's wrist roll leaves the hand hanging a little under the handguard rather than wrapping it squarely. The grip POSITION is right on every character; it is the roll about the barrel that wants another pass. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
682597a0d2 |
feat(weapons): scale the gun to the arm, and close the hands around it
The hold was wrong on every character in three independent ways, all of them a constant standing where a measurement belonged. MOUNT. set_weapon seated the weapon with rotation_degrees = (0, 90, -90). A bone attachment is expressed in the BONE's axes and no two rigs agree on those, so one constant mounted the gun differently on every model. It never needed to be right — the pose layer aims by rotating the wrist until the weapon's forward lies on the aim line, so the identity means "forward is the hand bone's -Z", true on any rig, and the wrist absorbs the roll. SIZE. The set is modelled at real-world scale; an M4 is 0.84 m butt to muzzle and these characters have 0.47 m arms against an adult 0.52. That put the handguard 0.66 m from the support shoulder, 0.2 m past reach, so the support hand was slid back down the weapon until it fitted — on Taila from an authored 0.35 m to 0.083 m, which puts both fists together at the grip. Two hands on a pistol, not a rifle. Fixed by solving the support arm's triangle rather than picking a factor: its hand must reach stock+fore ahead of the pocket from a shoulder half a shoulder-width off the axis, so scale the gun to the largest that keeps the handguard inside that reach. Taila and Kiyoko now come out at their own scales (0.217 and 0.213 m of hand separation) with the support hand at its FULL authored handguard distance and the slide-back loop never firing. The loop also has a floor now: a straight support arm beats no handguard hold. FINGERS. Nothing posed them — every hand was flat and open, which is the loudest possible tell that a character is not holding anything. They close now, about an axis derived from each hand's own anatomy in the rest pose: along = wrist to middle knuckle, palm = middle knuckle to thumb tip (the thumb opposes the fingers, so it marks the palm side by construction), curl = along x palm. The trigger finger gets a much shallower curl than the rest, because it lies along the trigger. Finger bones resolve by ROLE across all three naming families met so far — Rigify DEF-f_index.01.L, VRoid J_Bip_L_Index1, Blender IndexFinger1_L — ordered by depth below the hand rather than by the number in the name, which is not consistent between them. Verified by render on Taila and by measurement on Kiyoko: stock at the shoulder, trigger hand on the grip, support hand out on the handguard, fingers wrapped, arms not crossing. Smoke 0 failures. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
c8b0337aa7 |
fix(characters): rig-independent weapon mount, measured facing, revert Miku
WEAPON MOUNT, all models. set_weapon() seated the gun with a fixed rotation_degrees = (0, 90, -90). A bone attachment is expressed in the BONE's axes and no two rigs agree on those, so one constant mounted the weapon differently on every character. It never needed to be right: the pose layer aims the gun by rotating the wrist until the weapon's forward lies on the aim line, so the identity means "forward is the hand bone's -Z", which is true on any rig, and the wrist absorbs the roll. The grip now sits at the bone origin, so the gun is in the hand rather than at an offset from a differently-oriented bone. Verified by render on kiyoko: rifle shouldered, both hands on it. FACING. flatten_and_scale() now measures toes-versus-ankles and snaps the character to face Blender -Y, the convention the runtime's blanket flip is built around. Kiyoko was 180 degrees off. Snapped to the nearest quarter turn so splayed feet in a rest pose are not read as a turned character. MIKU. Re-imported without --grow-cloth. Her grown hair chains were the cause of the stretching: cloth_bones.py clears a vertex's body weights and re-assigns it to the fitted polyline, so a poor fit does not degrade to "stiff", it degrades to "torn". She now has no hair simulation — stiff but correct — until that tool blends against the weights it replaces instead of destroying them. ARIA'S SKIRT IS NOT SIMULATED. Worth recording plainly, because it looks better than Taila's and the obvious conclusion is the wrong one: aria has ZERO cloth chains. Her skirt never clips because it is rigidly skinned and follows the legs it is weighted to. There is nothing to port to Taila except switching her simulation off. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
27c4117c25 |
fix(pipeline): stand the character up before scaling; reach bones by role
Fixes the two root causes behind four of the seven reported breakages, and rejects the source that cannot be fixed. STAND UP FIRST. flatten_and_scale() now derives the up axis from the skeleton and rotates the model upright before measuring anything. Aria and Momo are correct: 1.75 m tall, 1.43 x 0.41 and 1.52 x 0.39 across, verified by render. The up vector is measured from the FEET to the HIPS, not from the hips to the head. The head is not a reliable landmark — the spine walk ends on the last non-cosmetic bone in the chain, which on a rig with a facial skeleton can sit BELOW the hips. Momo's did, so the first cut of this fix stood her neatly on her head: right size, right proportions, upside down. Feet cannot be mistaken. REACH BONES BY ROLE. SkinnedPlayerModel gained _role_bone(), and set_weapon uses it. Four characters could not hold a gun because one hardcoded lookup knew three spellings and their hands are called "Right wrist" and "J_Bip_R_Hand" — both resolved perfectly in the sidecar the whole time. HIKARI IS REJECTED. She now fails the gate: her feet and spine disagree about which way is up, so the stand-up correction cannot resolve her either, on top of zero-length cosmetic bones and a second armature that was smuggling its own clips into the export. That is not a tuning problem, it is a file that has been through two toolchains. De-registered and removed rather than shipped broken — which is what the gate is for. Six GLB skins remain, all passing. Smoke 0 failures, 11/11 movement tests. Still open, recorded in the skill: kiyoko faces backwards, miku's grown hair stretches under animation, the mannequin's rifle hold does not convince, and taila's front skirt clipping. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
2b3e29dd30 |
fix(pipeline): check that a character is CORRECT, not merely well-formed
Seven characters shipped "All checks passed" and four were visibly broken
in game — lying on their backs at seven times scale, facing backwards, or
holding a gun that floated near their chest. Nothing in the suite was
wrong; it just never asked the questions that mattered. That distinction
is the whole lesson, and it is now written down in the skill as
references/failure-modes.md, generalised per failure.
Two root causes are measured and certain:
- flatten_and_scale() normalises the bounding box along Blender Z because
Z is up. For a model that arrives lying along Y that measures the
character's THICKNESS, so it scales by ~7 and leaves them on their back.
One assumption, both symptoms. The trap is that the normalised number
always comes out right — the exporter maps Blender Z to glTF Y, so "is
the height 1.75" passes on a character who is 7.5 m tall lying down.
All three casualties are VRM files that went through a Blender
round-trip and came back with a baked axis rotation.
- SkinnedPlayerModel.set_weapon() finds the hand with three hardcoded
spellings, which match none of the four non-Rigify rigs — their hands
resolve perfectly in the sidecar as "Right wrist" and "J_Bip_R_Hand".
When it misses, the weapon is parented to the model root at a fixed
chest offset, so it is not attached to the character at all. Same class
of bug as the leg check that name-matched thigh/shin. rig_map.py exists
so nothing downstream has to guess a bone name; only some consumers read
the roles it publishes.
Three new hard checks, none needing more than the vertices and the
sidecar:
character stands up in world space — against WORLD up, not against the
model's own proportions. "Is the spine the longest axis?" catches
nothing: a model rotated as a whole is internally consistent and
passes it comfortably.
character is a plausible size / height
every role the runtime needs is resolved
They separate the four good characters from the three broken ones on the
first run. Also fixed the posture measurement to read vertices rather than
object.bound_box, which is cached and still stale right after an import —
it reported a 1.75 m character as 1.18 m tall.
Recorded but not yet fixed: kiyoko faces backwards (facing is inferred by
two independent mechanisms and verified by neither), miku's grown hair
chains stretch under animation (generated chains are never validated
against the geometry they drive), and the mannequin's rifle hold does not
convince despite resolving correctly.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 5
|
2ce2175d99 |
docs(skill): record what four non-library rigs taught the role resolver
Names lie and anatomy does not — the four VRoid imports each broke role resolution differently, and the lesson generalises: anything guessing anatomy from a bone name needs a structural fallback. Also lists what is shipping and which characters have chains that do not simulate. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
fc9e6f4275 |
feat(characters): four VRoid characters imported and selectable
Kiyoko, Hikari, Aria and Momo, all CC-BY from Sketchfab, licences recorded beside each skin. Seven GLB characters selectable now. kiyoko 13 meshes 20 cloth chains (62 bones) 0.0% cross-leg bleed aria 15 meshes 15 cloth chains (37 bones) 0.0% momo 5 meshes 9 cloth chains (35 bones) 0.0% hikari 13 meshes 10 cloth chains (37 bones) 0.2%, 12 twist bones These are the first characters imported that were NOT authored against the library's own bone spelling, and every one of them broke something that had been quietly wrong all along. All four failures were in code that guesses anatomy from names, which is exactly what tools/rig_map.py exists to stop doing: - LIMB ROLES went to the first role in LIMB_ORDER that matched at all, so shin's catch-all "leg" claimed UpperLeg before thigh's exact "upperleg" was ever consulted, and the thigh went unassigned. The result depended on the order bones arrived in. Claims are now granted longest-stem first. This also broke Mixamo (LeftUpLeg/LeftLeg) and had simply never been hit, because every character so far used Rigify DEF- names. - Names cannot settle thigh-vs-shin at all. A bare "leg" is the SHIN on Mixamo and the THIGH on a rig whose shin is "knee" — both common, same token, opposite bones. RigRoles now walks the leg from the foot upward and fills in whatever the names could not, stepping over twist bones. - verify_character.py looked for legs by the substrings "thigh"/"shin", which VRoid spells UpperLeg/LowerLeg. It declared every locomotion clip static while the legs animated perfectly, and the cross-leg bleed check found no leg vertex groups at all and passed vacuously. Two green- looking lies from one missing lookup; both now read the sidecar's resolved roles. - The cosmetic/spring classifier matched whole tokens only, so Momo's HairFL / HairFR / HairF_Top tokenised to "hairfl" and matched nothing. She imported with six chains, all bust, and no hair. Both classifiers now share one rule that also accepts a two-character positional suffix, which is short enough that "forearm" and "earring" are still untouched. Two more pipeline fixes: - A source model's own clips leaked into the export. Clearing bpy.data .actions before the library import is not enough — hikari carried two on a second armature's NLA tracks, and NLA_TRACKS export mode ships anything in a track anywhere in the file. They export as rest-pose statues. Now everything not retargeted is stripped from every object. - verify_character.py gained a check for cloth chains with no measurable extent. A chain whose bones are zero-length is dropped by the runtime and simulates nothing, while the sidecar still cheerfully reports it. Known: hikari's ten cloth chains are all zero-length and her collider fit found nothing, so her costume does not simulate — her rig has been through two toolchains and its cosmetic bones are empty terminators. She animates correctly otherwise. The new check now reports this instead of hiding it. tools/retarget.py also carries local working-tree changes that predate this session. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
cd0d1b2d99 |
feat(characters): import the Quaternius mannequin as a selectable skin
A third playable character, built with the pipeline skill from a source that was already in the repo: the animation library ships a rigged Mannequin mesh on the exact 53-joint reference skeleton, CC0, so it needed no download and retargets perfectly. 18 clips, 0.3% cross-leg bleed, 7% of verts at four influences — a clean authored-weight import. Licence recorded in mannequin.license.json as the other skins do. It has no cloth chains, correctly: it is a mannequin and has neither hair nor clothes. Importing it turned up two real bugs, both of which would have hit any flat-coloured or single-piece model: - LevelMaterials.apply_character_look treated ANY untextured surface on a character as the model's own outline shell and hid it, so the mannequin rendered as a solid black silhouette — its body and joint materials are untextured flat colours, not ink. _is_line_work() now asks whether the surface is named eyes*, is drawn front-face-culled (the inverted-hull setup), or is near-black. Taila and Miku are unaffected: their materials are textured and never reach that branch. Verified by render. - verify_character.py failed the build for having one mesh. That check cannot tell "the pipeline joined them" from "the artist authored one mesh" — Quaternius' mannequin is one piece on purpose. It is advisory now; the join path's two unambiguous signatures, cross-leg bleed and the 4-influences-everywhere spread, are still hard checks. Also restored Miku's description, which the re-import had blanked. 3 GLB skins selectable (6 with the built-in colour skins). Smoke 0 failures, 11/11 movement tests, cloth idle 0.024-0.078 deg/frame. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
270d5f0973 |
chore: track Godot uid files for the new debug tools
Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
7892669319 |
feat(pipeline): grow skirt and hair bone chains for a costume that has none
Miku shipped with 0 cloth chains against Taila's 35, so her twin tails hung off her skull like a helmet. Nothing downstream could fix it: the spring solver simulates cloth BONES, and a garment with none is welded to whatever body bone it was weighted to. Every auto-rigged model is in that state, and her source was an unrigged mesh. tools/cloth_bones.py builds them, which is the job a technical artist does by hand on a model like this. It finds the geometry by MATERIAL SLOT — the artist already answered which surface is hair, and on a joined mesh (what the auto-rig leaves behind) the slot is the only separation left. Hair is split into connected islands, because a strand is a connected piece of surface and clustering by position would merge two ponytails passing near each other. A skirt is split into radial wedges instead, because a skirt is ONE connected surface and islands would return the whole thing as a single piece — the bell-shaped failure. Each clump gets a polyline fitted down its middle by binning vertices by distance and taking centroids, so the chain follows the piece's own curve rather than cutting the corner on a bend, and vertices are re-weighted onto it while the first 22% keeps its original body weight so the scalp stays on the skull. On Miku: 19 chains, 57 bones from one `hair` slot. Sidecar 0 -> 19 chains. Idle stability 0.007-0.018 deg/frame. Mesh intact, verified by render. Opt-in, via `pipeline.py --grow-cloth`, and run before the retarget so describe_rig() finds the chains by name exactly as it would an artist's. Known limits, recorded in the skill: it cannot find a garment sharing a material with the body (Miku's skirt is on her `body` slot, so she got hair and no skirt), and grown chains are a fallback — an artist's chains carry intent that no geometric fit recovers. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
4559a1adc3 |
docs(skill): record why Miku has no cloth — the source had no skeleton
The two shipped characters are a controlled comparison: Taila's source arrived rigged (35 cloth chains, 8 twist bones, 18 meshes, artist weights), Miku's did not (5 meshes, 0 joints), so Miku was auto-rigged into one mesh with nearest-bone weights and no cloth chains at all. Her twin tails and skirt are dead geometry and the destructive load-time weight repair runs on her every spawn. None of that is recoverable downstream, which makes picking a source that already has skirt and hair bones the highest-leverage decision in the pipeline. Added the no-Blender check for vetting a candidate. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
daf9627ece |
docs(skill): compact the character pipeline into a reusable skill
Everything about getting an anime-styled character into the game — import, stylization, the body/garment/hair separation, rigging, retargeting, cloth and hair physics, and how to measure any of it — collected into .claude/skills/character-pipeline/. Organised around the principle the Hoyoverse-class pipelines are built on and that every failure in this project traced back to: a character is not one object. It is a body, a set of garments and hair, authored and rigged separately and moved by different systems. The body is skinned and animated; the garments and hair are bone chains the animation never touches and physics moves. The skill's non-negotiables are the four ways that separation has been destroyed here before — joining meshes, keying cosmetic bones, skinning cloth to a leg, and running the auto-rig repair on authored weights. references/verification.md leads with the trap that invalidated every cloth measurement ever taken in this repo: Godot restores bone poses after the modifier pass, so a tool that reads them afterwards measures the animation and never sees what any modifier did. Also records what is known-unsolved, with numbers: peak cloth clipping in a run/slide/dash, no foot IK, no strafe clips. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
040b595397 |
feat(anim): point the legs where the character is actually going
The clip library has one forward locomotion cycle and no strafe or backpedal clips, so a character sidestepping ran forwards on the spot while sliding sideways. Nothing in the animation said which way they were travelling and a body lean was carrying the whole burden of telling the player. Yaw the HIPS onto the travel direction and unwind it up the spine. The legs hang off the hips, so the whole stride turns with them and it costs no new animation; the chest keeps facing roughly where the player aims. Past about a right angle the hips cannot follow, so the cycle plays in reverse and the legs point the other way — a real backpedal instead of a moonwalk. The regime is hysteretic and the yaw is eased, so crossing between them reads as a pivot, which is what a person does there. The lean moved into the travel frame with it. Leaning "forward" along the facing while the legs run off to one side leans them sideways relative to their own stride, which is what being dragged rather than running feels like. It is also driven by how hard the character is moving rather than by signed forward input, so a sidestep leans into its own stride instead of standing straight up. debug/travel_dir_check.gd measures it. How far the stride points from the actual direction of travel: forward 9° fwd-diagonals 5-6° backpedal 2° back-diagonal 2° pure sidestep 39-42°, which is the deliberate hip cap Two things worth knowing about that tool. It reads bone poses from inside the modifier pass, because Godot restores them afterwards and anything read later is the animation with the pose layer missing. And it averages over a full stride: a run cycle twists the torso against the hips by tens of degrees twice per stride, so a single-frame sample measures the clip, not the layer. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 5
|
0dd9d01ac7 |
fix(cloth): solve the garment instead of repairing it five times
The skirt glitched when the character moved and the thigh still came through it. Both came from the same place: the solver integrated one spring per bone and then ran four more passes behind it — resolve the collision against the target, resolve it again against the answer, relax the cross-panel links and rebuild every pose from the corrected tips, then walk a separate ancestor "lift" — each writing bone poses the next read back and partly undid. The lift wrote poses that were never fed back into the spring state at all, so every frame began by pulling against a pose the springs did not know about. Replaced with one position-based solve, the shape Magica Cloth 2's BoneCloth uses. Every JOINT is a particle, so a bone's head can move; predict with inertia in the anchor's frame; relax length, bend, backstop, the cross-panel links and the colliders together; convert to rotations once at the end. A contact with no rotational leverage is now resolved by the panel moving, which is what a bodily chain push, an ancestor lift and a drape weight were each approximating separately. Measured, at a dead-still idle and over a movement sweep: idle jitter (skirt) 0.53 -> 0.025 deg/frame, worst 24 -> 1.9 settling after a dash 103 -> 18 mm of leg left inside the skirt fall / air / walk 82 -> 40, 96 -> 75, 72 -> 76 mm run / slide / dash unchanged, ~95 mm The idle buzz and the failure to come home after a hard move are gone — those were the "glitches out". Peak clipping in a run, a slide and a dash is NOT fixed and is still around 95 mm. Four things this turned up on the way: - debug/cloth_clip_check.gd was measuring the animation, not the render. Godot restores bone poses after the modifier pass, so reading them with force_update_all_bone_transforms() afterwards sees nothing any modifier did. It reported the same ~95 mm with collision fully enabled and with it commented out. It now observes from inside the pass. Every number ever taken from this tool before now was measuring the wrong pose. - The collision hulls came from ten farthest-point samples per bone, which describe a panel's corners and hem and leave its MIDDLE unsampled — exactly where a thigh comes through. Built from the real mesh at load time instead. - The drape term is gone. It was there to move a panel the old solver could not, and once the solver could, it was worse in every state but a walk and cost 20x in stability: its target sat inside the leg the collision was pushing out of, so the two ran against each other forever. - Cost was 10.9 ms per character. The inner loop rebuilt every capsule and reallocated the hull array for every (bone, collider, pass). Now 2.6 ms at full quality with a distance LOD behind it. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
Nicholas Butzke
|
374d9f9822 | feat: implement automated 3D character pipeline with retargeting and rig management tools | ||
|
Nicholas ButzkeandClaude Opus 4.8
|
afc954e129 |
fix: no limb vertex may carry opposite-leg weight — thigh collapse gone
The thighs going thin was never the knee bend. It was inner-thigh vertices
keeping ~20% of the weight of the OPPOSITE leg, so a split stride tore them
across the body. Printing the weight composition of the worst-collapsing
vertices is what finally showed it: a right-thigh vertex reading
DEF-thigh.R=0.58 DEF-shin.R=0.21 DEF-thigh.L=0.13 DEF-shin.L=0.08.
Every earlier pass had a guard that let these through. The below-knee pass does
not reach them; the above-knee pass demanded one leg chain be 1.25x nearer than
the other, which excludes everything near the centre line — precisely where the
damage was; and the limb-radius gates are measured from the bone AXIS, so a
vertex on the front or back of a thigh clears them easily.
SkinLegRepair now ends with an unconditional pass: any vertex within a generous
radius of either leg chain is forced onto the leg that actually drives it, at
any height. It runs last so none of the staged rules can reintroduce the
problem.
Measured per vertex, across jump, fall, run and dash:
before after
Body below 0.80 70 0
Body worst 0.46 0.82
ClothCAndW below 0.80 107 0
ClothCAndW worst 0.66 0.85
ClothB worst 0.81 0.87
No vertex anywhere on the legs now loses more than 18% of its thickness, down
from 54%. The skirt still deforms freely (0.87-0.88) — clothes flow, limbs hold.
Also fixed in SkinJointHelper along the way: it picked the FIRST joint chain
that matched a vertex rather than the one holding most of its weight, which
bound right-thigh vertices with stray left-leg weight to the LEFT knee's helpers
and dragged them across the body. It now picks the dominant joint and requires
the joint to own at least half the vertex.
Taila snaps 2021 vertices, Miku 659. FSM tests 11/11, spawn smoke test 0
failures.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 4.8
|
d33f9cd812 |
docs: record why bone-scale volume preservation does not work here
Tried widening the helper bone to cancel the joint collapse. The geometry is right — blending two rotations θ apart thins anything perpendicular to the bend by exactly cos(θ/2), which is |q.w| of the pose rotation, so scaling the helper across the bone by the reciprocal is the exact correction. It does not work, because a BONE scale is the wrong granularity. It fattens every vertex weighted to the helper whether or not that vertex was collapsing: parts of the thigh ballooned to 167% while the worst-collapsing vertices, which are not on the helper at all, stayed at 0.83. The idea needs per-vertex correction and a bone cannot express it. Removed, with the reasoning kept in the file so it is not retried. Hip joints were also retested, since two other variables had changed since the first attempt (one-joint-per-vertex, and the limb gate removed). Same verdict a second time: upper thigh 0.90 -> 0.84, and the skirt 0.80 -> 0.72. Knees only. Shipped state is unchanged from the previous commit; this is the reasoning and a revert of an experiment. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
1ab7e99231 |
fix: handle the knee bend with a joint, and record what made it worse
Renames SkinKneeHelper to SkinJointHelper and generalises it to a list of
[parent, child] joints, so the half-angle joint technique is stated once and can
be pointed at any joint. It stays pointed at the KNEES only, and the header now
says why, because "add more joints" is the obvious next idea and it is wrong
here.
Three things were tried this round and measured, on the thigh, per vertex,
against the rest transforms:
* hip and ankle helpers as well as knees: the knee got WORSE, 0.80 -> 0.50,
and the skirt went 0.80 -> 0.72. The hip mostly swings rather than folding,
and linear-blend skinning handles a swing far better than a fold; the helper
just added another blend for nothing. Reverted.
* gating the re-weight to vertices near the leg bone chain, to keep the hip
helper off the skirt: that also excludes the OUTSIDE of the knee, which sits
further from the bone axis than the limb radius and is exactly the geometry
that needs helping. Knee went back to 0.50. Removed — with knees only there
is no skirt to protect against.
* one joint per vertex (break after the first match): kept, since a second
job would read the bones the first just rewrote.
Net result on the thigh, worst per height bucket during a jump:
y=0.60 0.80 -> 0.83 y=0.75 0.84 -> 0.84
y=0.65 0.81 -> 0.84 y=0.85 0.90 -> 0.90
and the skirt is untouched at 0.80/0.84, still free to move.
FSM tests 11/11, spawn smoke test 0 failures.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 4.8
|
0bb1db0806 |
revert: let the skirt move again; keep the rigid-limb work
The previous commit stiffened the skirt onto the hips to stop it flattening at a wide stride. That was the wrong trade: it made the clothes read as a rigid shell welded to the pelvis, which is a worse look than the flattening it fixed, and it broke the model more than the original bug did. Reverted in full. What stays is the work that makes the HUMANOID hold its shape — below-knee side snapping, the above-knee limb pass, the torso cap, the half-angle knee helpers, and the cross-leg triangle drop. Those only ever touch vertices hugging a leg's own bone chain. The header now states the rule the passes are actually built around, because it is what keeps getting violated: limb vertices are cleaned up hard and must not deform; drape vertices are left alone and must be free to move. It also records the skirt-stiffening attempt so it does not get retried. Measured split now, from debug/limb_deform_check.gd: the body holds 0.98 of its cross-section at the knee while the skirt sits at 0.88 — rigid limbs, moving cloth. Taila snaps 1404 vertices (down from 4024 with the skirt pass), Miku 434. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
20b70e5eda |
fix: hang the skirt from the hips so it stops collapsing at a stride
It was the SKIRT, not the legs. Every leg check I ran hid the skirt to see the thighs, so I was never looking at what is actually on screen. Rendering the full model side-on shows it immediately: at rest the skirt is a flared shape with real volume, and the moment the legs split for a run or a jump it collapses flat against the body. The lower-body silhouette loses its shape, which reads as the legs squashing. Cause: the skirt is weighted to BOTH thighs. At a split stride the two thighs pull it in opposite directions and linear-blend skinning averages them, so the skirt is dragged inward and flattened. The earlier repair deliberately left it that way, on the reasoning that a skirt should be free to drape across both legs — correct in principle, wrong at these stride angles. Draping cloth now hangs from the hips: vertices that clear both leg bone chains keep at most 20% leg influence and the rest goes to DEF-hips, so the skirt holds its shape and swings as a unit. Limb vertices are still snapped to one leg, so the two are now modelled differently on purpose. Bounded ABOVE THE KNEE. The first attempt used distance from the bone chain alone, and chunky boots sit further from the ankle than the limb radius, so they read as "drape", lost their leg weight and trailed off the hips — the legs came out far worse than before. A skirt hem is above the knee; boots and stockings are not. Legs unchanged by this: knee cross-section stays 0.99, and the knee helper work from the previous commit is intact. Taila snaps 4024 vertices, Miku 670. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
050011666c |
fix: half-angle helper bones at the knees kill the candy-wrapper collapse
This is the leg squashing. It was at the KNEE, and every previous measurement missed it because they averaged a ring of vertices, which hides a collapse that only affects part of the ring. Measured per vertex instead, against an exact rest-transform baseline: 532 of Taila's leg vertices lose more than 20% of their distance from the bone axis and the worst lose 40%, all at y=0.54 — exactly the knee — and worst in the air pose. That is "squashing while running or jumping, easy to see from the side". Cause is inherent to linear-blend skinning: it averages TRANSFORMS, not shapes. A vertex half on the thigh and half on the shin is placed at the average of two rotations, and at a hard bend that average falls well inside the leg, pinching it to a ribbon. SkinKneeHelper adds a bone at each knee, parented to the thigh and holding the shin's rest transform, driven every frame to HALF the shin's rotation from inside the skeleton's modification pass. Blend-zone vertices are re-weighted off the thigh/shin pair and onto the helper, taking equal weight from each side and reusing the slot that falls to zero — so no extra influence slot is needed and the weights still sum to exactly 1. The sharpest blend any vertex now sees is half the knee angle, and halving the angle roughly quarters the collapse. Result: vertices losing more than 20% of their radius go from 532 to 0 on the body. The worst anywhere is now 0.79, on the outline shell, which is hidden. Verified visually too, legs rendered bare from the side through rest, run and jump: knees hold their volume and the bind is intact. FSM tests 11/11, spawn smoke test 0 failures, Miku unaffected. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
e707229283 |
fix: stop the torso holding back the top of the thigh
Hiding the skirt and jacket and rendering the legs alone, side-on, finally showed where the deformation actually is: not the knee, the HIP. The top of the thigh flattens into a wedge at full stride. That matches the worst number the corrected measurement reports — cross-section 0.85 at the hip, against 0.97-0.99 at the knee — which had been dismissed as ordinary. Cause is the usual linear-blend failure at a big rotation: upper-thigh vertices are weighted between the near-static hips and a thigh swung far out, and the average of those two transforms collapses the top of the leg. SkinLegRepair now caps torso (hips/spine) influence on LEG vertices at 15% and hands the excess to the leg bone that already dominates them. Only vertices within the limb radius of a leg bone chain are touched, so the skirt keeps swinging from the hips. Hip cross-section 0.85 -> 0.88, and the flattened wedge is visibly fuller in the side-on render. This is a real improvement but a modest one; the legs are slim low-poly geometry and some collapse at a 60 degree hip rotation is inherent to linear-blend skinning. Taila now snaps 1217+ vertices, Miku 434. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
1e12c36cca |
tools: give the limb deform check a baseline that validates itself
The measurement was comparing skinned lengths against BIND-POSE lengths. A
character is never in bind pose, so ordinary posing registered as deformation:
with the animation frozen it still reported 0.42x-2.56x edge ratios, and during
a run it reported edges collapsing to 0.08x and blowing out to 5.2x. Those
numbers were an artefact of the metric, not the model.
The baseline is now built from the skeleton's REST transforms, so every ratio
reads exactly 1.00 on an unposed model and the tool validates itself. Corrected
readings on Taila through the full runtime stack, worst over run, walk, jump,
fall, slide and dash:
lengthwise stretch 1.07 Body, 1.08 ClothB, 1.09 ClothCAndW, 1.03 shell
cross-section 0.97-0.99 knee, 0.85 hip, 0.92-0.94 ankle
That is ordinary linear-blend skinning.
Also records, in the header, the two ways this measurement was previously wrong,
because both nearly produced a bad "fix":
* the bind-pose baseline above;
* flagging vertices weighted across "non-adjacent" leg bones with
max_slot - min_slot >= 2, which flags shin+foot+toe — a perfectly normal
contiguous run. A repair pass built on that was written and reverted before
it shipped; it was stripping legitimate toe and shin influences.
Checks that did come back clean and are worth not repeating: bone pose bases are
pure rotations to 0.00001, bone lengths never drift from their rest offsets, and
of 4019 coincident-vertex groups not one carries mismatched weights, so there
are no split seams tearing at the joints.
No character or gameplay code changed. skin_leg_repair.gd is byte-identical in
behaviour to the last commit; only its header comment gained a pointer to this
tool.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 4.8
|
204846bf09 |
tools: measure limb deformation instead of eyeballing it
Adds debug/limb_deform_check.gd, which skins the leg vertices by hand and compares them against the rest pose across a sweep of run, walk, jump, fall, slide and dash. It reports lengthwise stretch (bending a knee can only shrink this, so growth is genuine stretching) and cross-section loss (the linear-blend "candy wrapper" collapse at a bent joint). No gameplay or character code changes in this commit. Current readings on Taila, through the full runtime stack: lengthwise stretch 1.05 worst (Body, ClothB, ClothCAndW), 1.03 outline shell cross-section 0.93 knee, 0.84 hip, 0.91 ankle Sanity check on the method: the measured rest span of the leg vertex cloud is 0.818 m against 0.843 m of thigh+shin bone length, so the skinning maths is producing real positions rather than plausible-looking noise. That is ordinary linear-blend skinning. Combined with the earlier findings — no bone pose basis deviating from a pure rotation by more than 0.00001, and no bone length drifting by more than 0.0000 m — the leg geometry is not squashing or stretching in any measurable way, so there is nothing here to fix blind. Committing the instrument so the next round starts from a number. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
a6e009d24a |
fix: repair thigh weights too, and keep the gun shouldered at low-ready
Legs: the previous pass deliberately stopped at the knee, on the reasoning that cross-leg weighting above it is legitimate for skirts. It is — but the LEGS themselves are up there too, and 122 vertices on Taila's thigh mesh carry up to 35% of the opposite leg. Running and jumping are exactly what splits the legs far enough for that to show, which is why the cuffs came good while the legs kept squashing. The repair now runs above the knee as well, but only on vertices that belong to a leg. Limb membership is decided by distance to that leg's own bone chain, not by height and not by surface name: a thigh vertex hugs its bone, while a skirt vertex hangs clear of both chains and is left blended so it can still drape over the two legs. The radius is half the gap between the thigh bones, so it scales with the character rather than being a magic number. Taila now snaps 1217 vertices (was 720), Miku 370 (was 214). Weapons: at low-ready the stock was dropped 0.20 m below the shoulder joint down to the ribs, with the muzzle pitched 22 degrees down. That pulls the whole weapon off the shoulder and out of the supporting arm — it read as dangling from the hands rather than being carried. Low-ready now stays in the shoulder pocket and merely relaxes out of it (0.07 m drop), with a shallow 9 degree muzzle tilt. All six weapons now sit in the shoulder with both hands on them. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
f60941d1fb |
fix: stop the boots being dragged by both legs; keep the support hand on the gun
Found the real cause of the leg stretching, after three wrong guesses. 720 vertices on Taila are weighted to BOTH legs at once below the knee — 262 in the boot/cuff surface, 208 in the outline shell, 176 in the body, the worst at a dead-even 49/51 split. A vertex pulled equally by both feet sits halfway between them and STAYS there while the legs separate, stretching every triangle around it. That is the band between the ankles and the elongated boot that reads as the legs being squashed. SkinLegRepair snaps each below-knee vertex to whichever leg already dominates it, renormalises, then drops the few triangles still spanning the two legs (48 on Taila, 0 on Miku, which needs 214 vertices snapped). What finally located it was reproducing the artefact through the FULL runtime stack in a bright scene. Every previous "clean" render had bypassed the game's animation stack — playing the clip straight off the GLB's AnimationPlayer with no AnimationTree and no pose modifier — so it could never show the bug. With the real stack the boot visibly stretches, and freezing the AnimationTree at the rest pose renders it perfectly, which proves the pose is fine and the skinning is not. Confirming measurements, all through the runtime stack during a run: no bone's pose basis deviates from a pure rotation by more than 0.00001, no bone's length drifts from its rest offset by more than 0.0000 m, and no below-knee vertex is influenced by any non-leg bone. There is no squash-and- stretch in this rig; there never was. The two earlier attempts at this are both superseded: re-weighting by triangle-neighbour majority (tore the cloth) and deleting cross-leg triangles (too narrow — 24 triangles against 720 bad vertices). Hiding the model's own outline hull, from the last commit, stays: that hull is genuinely broken and redundant, it just was not the whole story. Weapon support hand: gun_fore was a single constant 0.35 m for every weapon, so on a short gun it hung the off hand out past the muzzle with nothing to hold — that is the "not supported by the arms" case. It is now clamped to 80% of the weapon's own grip-to-muzzle distance, which only bites on the short guns (MP7 0.35 -> 0.20). All six weapons now sit in the shoulder with both hands on them. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
28dc255d17 |
fix: hide the model's broken outline hull, reverse the backpedal, slower blends
The "linked ankle cuffs" and the "squashed legs" were the same thing, and it
was never the cloth or the weights: it is the model's OWN outline hull.
Isolating it took rendering the raw GLB in a bright scene and toggling one
surface group at a time. The hull ("FullBlack" and "material", the untextured
surfaces that trace the body and hair silhouettes) is a duplicated shell whose
skin weights do not track the base mesh through a deep bend. During a run it
tears into spikes and stretches sheets across the ankles. Hiding just those
surfaces makes the legs render perfectly clean, with no other change — so the
two previous attempts here were both treating symptoms:
* re-weighting stray ankle vertices only tore the cloth (reverted last time)
* deleting cross-leg triangles removed real geometry for no benefit
(SkinMeshRepair is deleted in this commit — the clean render above was
produced WITHOUT it)
The hull is also redundant: characters already get an inverted-hull overlay
from apply_toon_recursive AND the screen-space ink_edge pass, so dropping it
costs nothing visually. The EYE cards (EyesFullBlack lashes, EyesInvL, EyesHL
highlight) are real facial features rather than a hull, so those are kept, flat
as before. They are told apart by name prefix, not by guesswork about geometry.
Worth recording: no bone is EVER scaled, in any clip. Measured again here
across the whole Run cycle — worst deviation of a bone's pose basis from a pure
rotation is 0.00000. There is no squash-and-stretch in this rig; it only ever
looked that way because of the shell.
Backpedalling now plays the locomotion cycle in reverse (negative TimeScale)
instead of moon-walking with the forward clip — the library ships no authored
backward run. Directional lean is raised from 0.18/0.30 to 0.30/0.42 rad: with
one forward cycle and no strafe clips, the lean is the only cue for which way
the character is travelling, so it has to be legible rather than subtle.
Blends raised again: base 0.22 -> 0.32, locomotion 0.28 -> 0.40. Verified the
cross-fade genuinely applies rather than snapping — instrumented an idle->run
switch and the thigh ramps gradually over the window instead of stepping on
frame one, with xfade_time reading 0.400 s on the Transition node.
FSM tests 11/11, spawn smoke test 0 failures.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Opus 4.8
|
ec6b8228da |
fix: cut the welded ankle band, seat the gun in the hand, flash at the barrel
1. Ankle cuffs. The previous pass re-weighted the offending vertices to the nearer leg, which was the wrong call: the strip between the ankles is REAL geometry spanning the gap (~10 cm of ClothCAndW crossing x = -0.05 .. +0.05 at ankle height), so re-weighting only tore it in half — a visible seam that still stretched. A triangle with one corner weighted to each leg has no correct pose; it must stretch the moment the legs separate. SkinMeshRepair now deletes those triangles instead (48 on Taila: the cloth band plus its outline shell). The cut is limited to BELOW THE KNEE, taken from the skeleton's own rest pose rather than a hardcoded height, because above the knee cross-leg geometry is legitimate — the skirt and shorts genuinely span left-thigh to right-thigh weights at the crotch. 2. The M4 floated because _measure_weapon derived the grip from mesh AABBs, and the FBX guns report bind-pose bounds tens of metres across — it measured the M4 as 24 m long and pushed the gun 7.5 m in front of the character. Bounding boxes are simply not trustworthy for these meshes. The grip was already authored elsewhere: WeaponManager places the first-person viewmodel's hands at fixed points in weapon space, and every weapon marks its barrel tip with muzzle_flash.position. Those move to WeaponGrips (dependency-free, so both the weapon system and the character models can use it without dragging each other's load order along) and third person now reaches for exactly the points the viewmodel uses. Every weapon's grip now lands 0.073 m from the hand — the M4 included, down from 2.32 m — with barrel lengths that match the models (0.30 m for the MP7, 0.68 m for the DMR). 3. Muzzle flash and tracers were spawned off the viewmodel's muzzle. The viewmodel is parented to the camera, so its muzzle sits inside the player's head — in third person the flash appeared by the character's shoulder. world_muzzle() returns the muzzle of the gun actually in the character's hands whenever the character is what the viewer sees, and the networked fire-effect RPC now sends that position too, so remote players stop seeing tracers leave the shooter's head. Measured: the third-person origin sits at the held gun, 0.54 m below the head, instead of on the camera. FSM tests 11/11, spawn smoke test 0 failures. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
35ada4f34a |
fix: unlink the ankle cuffs, stop the reload head-dive, soften every blend
Three animation complaints, measured before changing anything. There is NO squash-and-stretch. Instrumented every bone every frame: the worst deviation of a pose basis from a pure rotation is 0.00000. Every clip's position tracks match the skeleton's rest pose to within a millimetre (only DEF-hips translates, as it should) and no scale key deviates from 1. The "squishing" is a deep BEND, not a scale: the shared library's PistolReload was authored for someone watching their own hands, and it dives the head 33° with the whole neck chain at 67°. At that depth Taila's head/hair weights pinch and the skull changes shape. Dropping neck+head from the upper-body one-shot's filter leaves them on the locomotion layer: head dive is now 14° and the neck chain 48°, and the character keeps looking downrange through a reload, which is what a shooter wants anyway. Trade-off: Throw/Hit no longer swing the head. The ankle cuffs are not linked by the rig or the clips — the foot bones swing independently (left/right Z correlation -0.94). They are linked by SKIN WEIGHTS: 16 vertices belonging to the LEFT cuff, sitting at x = -0.002 just across the centre line, are weighted to the RIGHT leg, so the far foot drags a band of cuff across the gap. Position alone cannot classify them (the cuff they belong to spans x = 0.00 .. 0.05), so SkinWeightRepair decides by CONNECTIVITY: a vertex that disagrees with 80%+ of the vertices it shares triangles with gets its leg influences mirrored. Ankle-height cross-leg triangles go 24 -> 0 on Taila; the pass is conservative enough that Miku needs exactly 1 vertex and her face/hair/skirt are untouched (only leg bones are ever considered). Meshes with blend shapes are skipped rather than rebuilt. Blending: nothing cuts hard any more. Base cross-fade 0.15 -> 0.22, locomotion 0.28-0.30 (Idle/Walk/Run/Sprint switch constantly as speed drifts across their thresholds, which is where the snapping showed most), reaction moves raised off their near-instant values but still snappy, and the upper-body one-shot's own fades widened to 0.14 in / 0.22 out. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
d8b0c08611 |
fix: Taila reads like her source render — no white rim, matte hair
Two separate causes behind "too glossy with a thin white outline": 1. The model carries its OWN cel line-work as extra, UNTEXTURED surfaces — an inverted-hull outline shell plus eye-line/highlight cards (Taila names them FullBlack / EyesFullBlack / EyesInvL / EyesHL). They are authored to read as flat black, but the glTF import hands them a default near-white albedo, and apply_toon_recursive then LIT them. That is the thin white rim: a pale, toon-shaded outline shell tracing every hair strand. They now render unshaded flat ink (flat white for the "HL" highlight card). 2. The skin textures already have cel shading painted in. Stacking our hard 3-tone break on top produced a bright stripe that slid across the hair as the camera moved — the "gloss". Characters now get a soft terminator and an almost-invisible second step, so the painted shading carries the form. Both live in a new LevelMaterials.apply_character_look(), called only for imported character GLBs, so props and level geometry keep exactly the crisp banding they were calibrated with. The one shared change is that the toon shader's second-step darkness is now the mid_tone uniform, defaulting to the 0.82 that was hardcoded — no change for existing callers. Character shadow tint (0.64, 0.56, 0.72) is measured off the Sketchfab reference render rather than guessed: sampling the hair there, shadow/midtone lands near (0.63, 0.53, 0.70). Green drops hardest, which is what keeps copper hair copper instead of washing it to brown. debug/character_look_capture.gd renders the raw import beside our treatment under matched lighting — the comparison this was tuned against. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
af8c9831c9 |
feat: thinner cel outline + procedural model actually holds its weapon
Outline: the inverted-hull width was tuned when the look was heavier and now reads as a thick marker stroke. Cut every call site to roughly a third (characters 0.012 -> 0.004, level geometry 0.015 -> 0.005, Neon Alley's size-scaled clamp 0.02..0.05 -> 0.007..0.018) plus the shader default, so the ink line stays readable without fattening every silhouette. Third-person weapon on HumanoidModel: the gun was parented to root_pivot at a fixed (-0.15, 1.0, 0.4) — floating 40 cm off the chest while both arms posed at it from a distance. Give the rig a real right-hand node at the end of the forearm and hang the weapon there, so it travels with the arm. Its aim is re-derived from the body each frame (hand_r_pivot's global basis is copied from root_pivot), otherwise the barrel would swing around with the arm animation. The hold pose is retuned to match: right elbow tucked at the ribs with a level forearm, left arm crossing to the handguard. _seat_weapon_in_hand() slides each weapon along its own barrel axis so a plausible grip lands in the fist regardless of where the artist left the model origin. It measures with MeshInstance3D.get_aabb(), not mesh.get_aabb() — the FBX gun parts are skinned, so the Mesh resource still carries bind-pose bounds tens of metres across. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas Butzke
|
1172e465c1 | chore: add UID file for bone dumping debug utility | ||
|
Nicholas ButzkeandClaude Opus 4.8
|
0d125dc03f |
fix: third-person gun actually held — IK to the weapon, real recoil, no flip
Four separate third-person defects, one shared root: the arms were posed at art-directed ANGLES that merely approximated the gun, and a stuck one-shot flag kept handing them back to the animation clip. - The rifle hold was silently DEAD after the first reload or throw. The gate trusted AnimationNodeOneShot's `active` parameter, which never clears, so clip_owns_arms stayed true forever and the clip drove the arms while the gun hung off the hand. `_upper_lock` (a timer we own) is now the authority, and the one-shot is explicitly faded out when it expires. This alone is why the gun was never held correctly. - Arms are now solved with real two-bone IK (`_ik_arm`) onto points derived from the WEAPON: the stock is anchored in the shoulder pocket, the grip and foregrip fall out along the barrel, and the support hand is placed on the actual handguard (sliding inboard if the model is too long to reach). Verified numerically: the hand lands within 2mm of its target. - `_measure_weapon` measures the model's AABB along its barrel and re-seats it so the hand sits at a realistic pistol-grip point. Weapon models put their origin anywhere — the M4's was 10cm from the muzzle end, so parking its stock in the shoulder drove the hand INTO the shoulder and folded the arm up behind the head. - Recoil now shows for the OWNER in third person: server_play_fire_effects only ever fired for remote shooters, so the local player saw nothing. The ammo counter dropping now kicks the model. The kick rides in the gun's aim direction so the IK carries BOTH hands up with it, instead of rotating the arms and shoving the support hand off the gun. - Reload no longer flips the gun. The library's pistol-reload rotates the wrist the gun is parented to, which turned the rifle upside-down (mag to the sky) while the hand reached down for it. The hold now keeps the right arm through a reload and the support hand does the magazine work at the real mag well, under the receiver. anim_capture gains recoil shots and lets ADS settle before framing; debug/dump_bones.gd prints a skin's bone hierarchy. Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
df0bf18e0f |
feat: real per-weapon reload/recoil choreography + knife slash, fully matte hair
Weapons no longer reload by spinning the gun 360 (that was the upside-down
flip; nothing detached). New ViewmodelAnim module drives per-style manual-of-
arms sequences on the existing model_root + named arm pivots, with a temporary
magazine/shell/rocket/cell prop that visibly leaves and returns to the gun:
- mag (M4/AK/MP7/DMR): roll gun to present the well, hand rips the mag
down and away, fresh mag up, seat, charge. Gun stays UPRIGHT.
- boltmag (AWP): mag swap + a distinct bolt-cycle rock.
- break (double barrel): hinge open, flick both shells out, drop fresh
shells in, snap shut.
- tube (rocket launcher): tip the tube in, shove a rocket home, shoulder.
- cell (plasma/nail gun): glowing energy cell swapped on the side.
Per-shot viewmodel recoil kick (ViewmodelAnim.apply_kick) scaled by each
weapon's recoil_amplitude, so an AWP slams and an MP7 chatters — replaces the
old flat model behaviour. Weapons expose reload_style; base classes call
play_reload / stop (on unequip) / apply_kick.
Knife: the old barely-visible flick is now a real diagonal slash that
alternates backhand/forehand, whips the blade through screen centre, and
fires the third-person melee arm-swing action (synced to other players).
Hair/materials: specular fully to 0 (even a 2% stepped glint swept as shine
across Taila's hair when the camera moved); rim trimmed to a whisper. Fully
matte cloth/hair now.
Verify: debug/fp_weapon_capture.gd screenshots each weapon's reload phases,
the knife slash, and the fire kick.
Co-Authored-By: Claude Fable 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Fable 5
|
d46530bd8c |
fix: color-accurate grade — ginger hair stays ginger, characters stay matte
The saturation grade (1.3) was shifting authored hues — Taila's auburn ginger hair rendered fire-truck red and the whole game read filtered. Saturation 1.3 -> 1.08, contrast 1.05 -> 1.03: textures now carry their own vibrancy. Verified by sampling the rendered hair against the source texture: lit hue 18-20 deg vs authored ~20 deg. Character rim/specular cut again (rim 0.15/0.4 -> 0.08/0.32, spec 0.06 -> 0.025 @ 64): hair and cloth read fully matte, no wet sheen. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
1ad3563e5a |
feat: animations follow the mechanics — upper/lower split + real grapple pose
Two fidelity gaps closed: - Reload/throw/shoot/hit used to REPLACE the whole-body clip, so reloading mid-slide snapped the character upright on standing legs. The model now runs a runtime AnimationTree (clips -> Transition -> TimeScale -> OneShot) whose one-shot layer is FILTERED to upper-body bones: the arms play the action while the legs keep sliding/running/falling. Land stays full-body. The rifle hold releases exactly while the one-shot node reports active. - Grapple no longer plays the library's horizontal-swim clip. The zip pose is procedural: Fall as the airborne base, the spine pivots to fly along the line to the actual anchor point (capped so overhead shots don't fold the body), the head sights the anchor, legs trail behind, the FREE left hand reaches up the rope — and the right hand keeps holding the rifle. The anchor point feeds in from the controller for local and remote players (synced_grapple_point). - anim_capture: deterministic open-ground teleport + two new regression shots (reload-while-sliding, grapple zip toward a real anchor). Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
87b8ae70df |
feat: Fortnite-style OTS camera + Alt free-look orbit in third person
- Third-person camera chain is now HeadPivot > OrbitPivot > ShoulderOffset (0.55m right, 0.12m up) > SpringArm(2.6m, 14 deg) — the character sits slightly left of screen centre over-the-shoulder instead of dead centre behind. Aim is unchanged (still the first-person camera). - Hold Alt in third person to orbit the camera freely around the character with the mouse (yaw wraps, pitch clamped -69..+29 deg); the character keeps facing and aiming where it was. Release Alt and the camera springs back behind the shoulder. - debug/orbit_capture.gd: screenshots the OTS framing, a driven orbit, and the spring-back for visual regression. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
b0f26e6dde |
feat: matte anime materials — kill the glass/mirror look, keep the vibrancy
Everything read as wet plastic or glowing porcelain for two stacking reasons, both fixed centrally: - toonify() shipped every character/prop/weapon with a hot rim (0.45 over 65% of the silhouette) and broad stepped specular (0.25 @ shininess 24) — patent-leather highlights on any dark surface. Now a thin rim (0.15/0.4) and a small tight glint (0.06 @ 56); shader defaults match. - The LINEAR tonemapper clipped lit white surfaces (sun + ambient push facades past 1.0) and the glow pass bloomed the clip, so buildings glowed like porcelain. Switched to FILMIC with white=2.4: near-linear through the cel bands (they stay crisp), soft shoulder above 1.0. Glow threshold 1.1 -> 1.45 so only genuine emissives (neon, tracers, plasma) bloom. - Saturation 1.22 -> 1.3 compensates filmic mids — vibrancy unchanged. - Neon Alley: ambient 1.7 -> 1.35 / sun 2.2 -> 2.5 — the shoulder no longer hides the ambient lavender cast, so let the sun shape the facades. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
d0c746d084 |
feat: Taila — second anime character through a hardened import pipeline
New selectable skin: Taila (original anime character by Partaevil, CC-BY, license kept alongside the model), cel-shaded with ink outlines, running the full 18-clip animation set + the new rifle-hold pose layer. Pipeline hardening learned the hard way (each of these produced a broken character before the fix): - tools/strip_rig.py: strips a foreign rig (VRoid/Mixamo names bake FLAT clips in the name-based retarget), keeps only meshes skinned to that rig (scene props were joining into the player model), recentres feet-on-origin, and reroutes image textures into Principled base color for re-export. - tools/unlit_to_pbr.py: KHR_materials_unlit anime models carry their albedo in emissiveTexture over a black base — Blender 5.1 drops the texture on import, rendering the character pitch black. Rewrites the GLB JSON to standard textured PBR before Blender ever sees it. Also dropped the Elle import attempt: her rest pose is seated (posed scene), which the T-pose autorig cannot use. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
6c227b5538 |
feat: real two-hand rifle hold — armed animations finally read as a shooter
The clips were playing all along, but every locomotion state used unarmed jog arms while the gun floated at the hip, so nothing looked animated. - ShooterPoseModifier now REPLACES the arm chain with a direction-based FK rifle hold (low-ready at hip, shouldered on ADS) instead of nudging the unarmed clip additively; the wrist is solved so the muzzle points exactly along the aim line, gun kept upright (no-roll constraint). - Per-arm release logic: reload/throw/hit one-shots, dance, death, the slide ground-brace, wall-run reach and grapple free the authored clips. - Third-person weapon: fixed re-hide on weapon swap while in third person, scaled to character proportions, gripped along the hand. - Armed idle uses Idle (arms owned by the hold) instead of arms-crossed PistolIdle base. - FP viewmodel arms: character-styled sleeve + teal cuff + skin hand instead of the blue slabs. - debug/anim_capture.gd: front+side screenshots of every movement state, one-shot action and ADS for visual regression of the model pipeline. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
39af109893 |
feat: first-person reload animation on the viewmodel
The weapon dips down-and-inward with a roll when a reload starts, holds through the reload, and rises as it completes — driven by the weapon's actual reload_timer so the motion always matches the reload duration. Complements the reload ring UI and the third-person reload clip. Smoke 0 failures, movement 11/11. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
7920aecec5 |
feat: player animation quality pass — aim follow, reload/throw, recoil
Third-person player characters now animate every action with readable intent (all networked, cel style preserved): - Look-around: upper body follows the owner's camera pitch — distributed over spine/neck/head so aiming up/down reads on the whole silhouette (driven by the already-synced HeadPivot rotation on remotes) - Reload: the baked PistolReload clip plays as a one-shot whenever the equipped weapon starts reloading (local edge-detect poll -> new synced action counter replays it on every peer) - Grenade throw: new Throw clip baked from the library's overhead swing (Sword_Attack retarget); triggers on throw, synced the same way - Shot recoil: visible kick on the shooter's model (shoulders snap back, forearms rise, fast decay) driven by the existing fire-effects RPC — remote players' shots now look like shots - Slide: trailing arm braces against the ground for balance on top of the feet-first pose - Armed idle confirmed in capture: weapon held at ready, not arms-down Plumbing: synced_action/synced_action_seq added to all three player spawners' replication configs; ACTIONS table on the model maps names to clips + lock times. Verified: 18 clips resolve (incl Throw), smoke 0 failures, movement 11/11, acoustics PASSED; third-person run + armed idle captures clean. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
5224a455a6 |
feat: screen-space ink edge pass — drawn outlines on everything
New assets/shaders/ink_edge.gdshader: fullscreen depth+normal discontinuity detection draws thin ink lines over the whole scene — the renderer-level line pass anime-styled games use. Works on every model regardless of mesh topology (kit buildings, cars, heroes, characters), with distance fade so the skyline stays clean. Attached via LevelEnvironment so every map gets it for whatever camera renders (first-person, third-person, spectator). Street capture verified: crisp uniform outlines citywide, no artifacts. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
911066875b |
feat: hero batch 3 — pedestrian footbridge + viaduct station platforms
- footbridge.glb: 18m truss footbridge over the central avenue one block south of the rail line — X-pattern teal trusses, mesh railings, real stair flights at both ends. Deck and stairs are WALKABLE (box deck collider + invisible ramp colliders over the stair visuals): a third elevated crossing route between the viaduct and the plaza, and a new grapple anchor over the avenue - platform.glb: station platform strips on the viaduct deck flanking the crossing — canopy on posts, benches, line signs; dresses the deck route players actually run - Fixed a parse error from an undefined color constant caught by the capture loop (blank render -> error -> fix -> verified) Movement 11/11, smoke 0 failures; full-city aerial verified. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
18f50adb78 |
feat: hero asset batch 2 — yatai, koban, phone booths, bus stops, bikes
Second round of original Blender-kitbashed street furniture (tools/build_hero_assets.py): - yatai.glb: ramen cart — noren curtain strips on a hanger bar, counter, wheels, three stools, paper lantern, red roof with ink trim; one at every market mouth (wood collider) - koban.glb: police box with teal roof, door, framed window, sign board and red lamp — watches the central crossing from the SE plaza corner - phonebooth.glb: green-framed glass booth on ~25% of retail corners - busstop.glb: bench + glass canopy + yellow sign disc, alternating blocks along the central avenue, both directions - bicycle.glb: torus-wheeled bikes with frame/seat/basket, parked in seeded rows of 2-4 beside building fronts All toonified with ink outlines; colliders acoustics-tagged (wood/ concrete/glass/metal). Movement 11/11, smoke 0, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
7f9a579b63 |
feat: original kitbashed hero assets built in Blender
First bespoke art authored for the project (tools/build_hero_assets.py, headless Blender 5.1 -> assets/props/hero/): - konbini.glb: 8m convenience-store front — fascia + teal sign band with ink trim, framed windows with sills and window ads, recessed double glass door, angled awning, drink machine, hedge planter. Placed on ~1/3 of wide buildings (glass-tagged collider) - station.glb: viaduct station entrance — canopy on pillars, real stair steps with handrails and balusters, sign totem; placed at the central avenue crossing of the rail line - clock.glb: 10m plaza clock tower — tiered base, ringed column, 4 clock faces with hands, teal crown; anchors the south-west plaza cell - torii.glb: proper torii with segmented curved kasagi, shimaki, nuki beam and plaque — replaces the box torii in every shrine courtyard (invisible pillar colliders keep gameplay identical) All hero pieces run through the toon pipeline with fine ink outlines. Every part beveled; flat cel palette matches the city. Verified: city renders clean with hero pieces placed; movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
6b3e363dfd |
feat: protruding double-sided shop signs over the sidewalks
1-2 per building at second-floor height on metal brackets, double-faced with generated ad graphics — the perpendicular sign clutter that defines Akihabara/anime-city streets and makes rows read dense from street level. Verified via street capture; smoke test 0 failures. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
c8a85586bd |
feat: modeled market stalls, mega wall ads, traffic lights, awnings
Final detail pass — no gameplay object remains a plain box: - Markets: box stalls replaced with modeled kit stalls (4 styles seeded), hidden box colliders keep the wood acoustics; hand carts at the market mouths; standing lanterns between stalls - Shrines: hanging lanterns on the stone pillars, wooden fences flanking the torii approach - Towers: giant mid-height wall ads on the street faces (the anime-city mega-ad look), on top of crown boards and corner columns - Storefront awnings (kit detail piece) on ~40% of buildings - Traffic signals at every central-avenue crossing, diagonal from the streetlights - Fantasy Town Kit (CC0) installed at assets/props/town Verified via street capture (wall-scale glyph ads, pharmacy signs, banner ads, stalls, carts); movement 11/11, smoke 0, acoustics PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
648872a16d |
feat: ad-graphic layer — generated posters, billboards and sign columns
The city's flat color sign panels are now real graphic designs, closing the street-level "graphic density" that anime cities live on: - tools/generate_ads.py: procedural ad library (24 textures) — bold two-tone layouts (diagonal splits, bands, circles, stripes) with fake-glyph text blocks that read as kanji/kana from gameplay distance, inked borders, seeded palette system - Every building gets 1-3 street-level posters plastered on its facade - Vertical sign columns render a stacked-glyph column texture - Rooftop billboards, tower crown boards (both faces) and the central 4-face screen tower all show distinct ad graphics - Posters under the viaduct arches on every pier - All panels lit (albedo + emission of the same texture) so they glow as signage without blooming out Verified via street capture (glyph posters, pharmacy-cross signs, ad boards visible down the avenue); movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
56db9eea59 |
feat: parked cars across the city (Kenney Car Kit, CC0)
Streets are now populated: seeded parking lanes hug the curbs of every N-S street with sedans, taxis, vans, SUVs, hatchbacks, delivery trucks and the occasional police car (~100+ across the city). - Wheels attach at the models' wheel-socket empties at spawn - Metal-tagged box colliders: cars are cover that sounds like cover - Toonified + darkened base tint (kit albedo clips under the map light) with per-car hue jitter for varied paint jobs - Slight rotation jitter so parking reads natural, not stamped Verified via street capture (colored cars parked down the avenue, no clipping/glow); movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
04d91dea31 |
feat: street-level detail pass — real roads, streetlights, trees, cables
Closes more of the gap to hand-authored city art at eye level: - Kenney City Kit Roads (CC0) installed: every street in the 10x10 grid is now real road meshes — lane-marked straights (single stretched mesh per segment) and line-marked crossroad tiles at all 81 intersections, tinted to sit under the toon lighting without clipping - Kit streetlights (curved arms over the road) along both central avenues, with slim pole colliders kept for grapples - Kenney Nature Kit trees replace the cone/box stand-ins in shrine courtyards and plaza planters (original kit materials kept — the toon swap mangled their vertex colors into cyan) - Overhead cable bundles sag across the east-west streets (the classic urban-Japan sky clutter), drawn as ink lines; central avenue kept clear - Construction sites get cones + barriers from the roads kit - Per-building tint jitter so repeated kit models read as distinct shops Verified via street/aerial captures (dark marked asphalt, green trees, detailed facades); movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas Butzke
|
f62f4f2503 | feat: add Kenney road and nature assets and implement map builder script | ||
|
Nicholas ButzkeandClaude Fable 5
|
67040ba12d |
feat: detailed building models across the city (Kenney City Kit, CC0)
Boxes with lines can't reach the requested fidelity — the city now uses real modeled architecture, toonified into the cel style: - Kenney City Kit Commercial (CC0, 41 GLBs) installed at assets/props/citykit: 13 mid-rise buildings + 5 glass skyscrapers with actual modeled window insets, doors, storefronts, awnings, trim and rooftop detail, plus parasol/awning props - Standard + market blocks: street edges fill with seeded kit buildings (measured catalog drives placement, x13 scale -> 11-32m facades) over box colliders; Akiba signage layer (corner sign columns, glowing segments, roof billboards) attaches aligned to each model's bounds - Tower blocks: kit skyscrapers (up to ~70m curtain-wall glass) on the walkable podium, seeded rotation, crown billboards kept - Market blocks add cafe parasols among the stalls - SSAO enabled + exposure recalibrated for the kit's bright albedo (sun 2.2 / ambient 1.7); lighter asphalt/paving to match; lighter haze All kit meshes run through apply_toon_recursive: toon banding over the kit textures, matching characters/weapons/VFX. Verified: street + aerial captures (detailed facades at eye level, dense believable skyline); movement 11/11, smoke 0, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
b0af2ea9ee |
feat: Akiba Crossing city — 100 blocks with unique landmarks + detail pass
Scaled the single block to a full 10x10 city grid (48m cells, 16m streets, 640m across) with a hand-authored layout so the fabric stays varied: Block types: - S standard retail (70%): paired parametric buildings facing the N-S streets, seeded heights/colors per block; ~half get a mid-block alley with fire-escape climbs so no two blocks play identically - T landmark towers: 8-10 floors on a walkable retail podium, mega corner sign, double-sided rooftop crown billboard (skyline wayfinding) - J shrine courtyards: walled court, torii, slide-roof hall, lanterns, trees — the green quiet break in the fabric - M market streets: dense stall rows + lantern strings between low buildings (close-quarters cover mazes) - P plaza cluster at the city centre with planter cover and a giant 4-face screen tower at the exact middle (the Crossing) - C construction sites: open slab frame to wallrun, access ramp, container stacks, and a 28m crane whose jib is the city's tallest grapple anchor City systems: - Brick rail viaduct runs the full east-west width on per-block piers with vending arcades under alternating arches + slide ramps at the centre - Central avenues x=0/z=0 get matched streetlights and zebra crossings at every block line; brick wall rings the district; city-haze fog for depth - Detail pass per building: window bands every floor, water tanks/antenna masts seeded on roofs, denser sign stacking Perf/physics: decoration (signs, windows, leaves, lamp heads) is render-only MeshInstances; only gameplay surfaces are static bodies, all acoustics-tagged. Spawns distributed across block types facing centre. Verified: full-city aerial (all 100 blocks, aligned grid), avenue-level capture (clean canyon, viaduct vista); movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
a7fa7f207c |
feat: Akiba Crossing — parametric Akihabara rebuild of the urban map
Complete new approach after the hand-placed layout shipped misaligned: every element now derives from a street grid and its building's footprint, so alignment is structural, not luck. District structure (modeled on Akihabara's Chuo-dori / Denki-gai / JR viaduct): - 16m avenue flanked by continuous mid-rise rows; buildings defined ONLY by z-interval + floor count (4m quantized floors), packed edge-to-edge - _building() derives everything from the footprint: parapet lips on the roof rim, inset glass storefront, sidewalk canopy, stacked per-floor sign bands, a solid vertical corner sign column with glowing segments, evenly spaced roof AC units, rooftop billboard on 4+ floor buildings - Brick rail viaduct crosses the whole block on piers with an under-track vending arcade; sidewalk-aligned slide ramps with handrails reach the deck on both flanks - Denki-gai alley cut through both rows (wallrun walls + fire escape platforms climbing per floor); red SEGA-style landmark + blue electronics building anchor the north corners - Matched streetlight pairs every 16m with arms over the road; zebra crossings at the alley mouth and south block; spawns on sidewalks/deck facing the map center Movement: viaduct high lane + roof-hop onto the 2-floor row, canopy lane above each sidewalk, alley wallruns + fire escapes, grapple anchors on lamp arms / sign columns / viaduct edge / billboards, slide ramps. Acoustics: facades concrete, storefronts glass, canopies wood, viaduct brick, signs/AC/vending/lights/escapes metal. Renamed in the level selector: "Akiba Crossing". Verified via aerial and street captures (aligned rows, clean canyon, viaduct framing); movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
233f88aee3 |
feat: full cel treatment for Neon Alley — flat toon colors + ink outlines
- LevelMaterials.flat(): toon-banded FLAT color material (no greybox grid texture) for dressed maps; cached per tint, rim/spec off - Neon Alley overrides _box_static: every structure renders flat cel color; prop-scale pieces (<10m) get an inverted-hull ink outline scaled to their size. Building-scale boxes skip the hull — the inflated plates smear into black voids at close range (found via fixed street-camera capture) - Pylon wires render as flat ink lines; warmer wood + hotter vermilion for flat shading (the grid multiply used to brighten tints) - visual_capture: deterministic street-level shot after the aerial for style comparisons Street capture now reads properly BoomerangX: flat lavender asphalt, hard light bands, torii framed down the underpass, neon strips + sign glow. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
0813d0b40d |
feat: Neon Alley — urban-Japan movement map built on the acoustic materials
New map (scenes/maps/neon_alley/, auto-appears in the level selectors): Layout for movement flow: - Main N-S street = the long sightline, crossed by a pedestrian bridge (slide ramps up both ends, underpass cover below, railed high ground) - West machiya row: wooden two-story houses with a jump route (awning -> balcony -> roof deck) and 25-degree slide roofs facing the street - East concrete towers with glass storefronts; brick wallrun alley between them (AC units to vault); metal fire-escape platform route to the roofs; angled rooftop billboard as cover + grapple anchor - Three power pylons with crossarms over the street chain a grapple route; the torii gate crossbeam at the north shrine plaza is a fourth anchor - South market: wooden stalls with neon canopies + metal vending machines = scattered mid cover; shipping container corner piece - Spawns ring the block and face the map center Acoustics as level design: every surface is tagged (machiya/stalls/torii wood, towers concrete, storefronts glass, alley+perimeter brick, escapes/ AC/rails/container metal) so occlusion tells you which structure a shot came through and reflections differ per street. Style: sunset sky + fixed dusk-lavender ambient (calibrated for the toon shader's 1/PI light response), warm low sun, neon sign columns, shop signs, lantern strings, billboard glow, underpass strip lights. Verified: aerial + street-level + third-person captures; movement 11/11, smoke 0 failures, acoustics ALL PASSED. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
a51595e3b9 |
feat: material-aware sound occlusion + early reflections for localization
New Acoustics system (globals/acoustics.gd): - Occlusion: rays from listener to source collect up to 3 occluding bodies; each surface's material adds transmission loss and lowers the lowpass cutoff. A gunshot through wood stays warm (-8dB, 1.4kHz), brick muffles hard (-15dB, 600Hz), concrete harder (-18dB, 450Hz), metal keeps more highs (-11dB, 1kHz), glass barely muffles (-5dB, 2.6kHz). Applied via each AudioStreamPlayer3D's attenuation filter. - Early reflections: loud sounds (gunfire, explosions) probe 8 directions for nearby walls; each close surface plays a quiet, delayed (path/343ms), material-filtered copy from the mirror point — shots audibly slap back off structures so players can triangulate. Sub-30ms echoes are skipped (they perceptually merge with the direct sound). - Surface classification: builder-set acoustic_material meta -> node-name keywords -> metallic-material inference -> concrete default; cached. Integration: - AudioManager.play_3d applies occlusion at fire time and re-filters all playing positional sounds every 0.12s (walking behind a wall mid-sound audibly muffles it); flight loops opt in via "acoustic_occluded" group - Remote players' gunshots were entirely SILENT — rpc_play_fire_effects now plays the right weapon's shot at the shooter's position, occluded and reflected like everything else - Remote players' footsteps were also silent — now positional + occluded, cadence scaled to their speed - Test level tagged: brick arena walls, wooden platforms/obstacles, metal wall-run corridor/rails/dash platforms; dust2 sandstone reads as brick Tests: debug/acoustics_test.gd (12 checks: per-material loss ordering, multi-wall stacking, reflection delay/filter, name classification) — all pass; movement 11/11; smoke 0 failures. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
44460b52ae |
fix: exactly one bang per bullet — cut bursts and range echoes from gun audio
The library's master sheet revealed the primary AK-47 sample (C_27P) was a full-auto LONG BURST, and two other slots used burst takes (C_34P, P_22P) — one trigger pull audibly played several rounds. Beyond that, the single-shot recordings carry outdoor-range slap-back echoes arriving as discrete pops at ~0.23s/0.33s/0.45s, which also read as extra shots. - All fire sounds rebuilt from sheet-verified SINGLE-shot takes only (AK-47 gets C_28/C_31 + same-caliber SKS as third variation; MP7 gets single PPSh takes + Walther PPQ 9mm) - Every sample now ends before the first echo can play: full level through the crack (~0.145s), faded out by 0.21s (times scale with pitch rate) - Verified with silencedetect: every fire WAV is a single transient with no mid-file re-attacks Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
0155bcdf04 |
fix: tighten gun audio timing and replace off-character sounds
- Gunshots: strip lead-in silence from every firearm recording (the audible
delay between trigger and bang) and hard-trim to a single 0.7s crack with
a fast fade — the outdoor-range echo read as 2-3 extra shots. Big single
shots (AWP/shotgun/rocket/mortar) keep a 1s tail but still one boom.
- Hit confirm: short fleshy punch thock instead of the bell ("taco bell")
- Dash: clean synthesized air whoosh (bandpassed pink noise swell) instead
of thruster fire crackle; grapple shoot inherits it
- Jump: push-off foot scuff + faint whoosh instead of the balloon boing
- Wind speed-loop: deep lowpass so it reads as rushing air, not fire
- Grenade: silent in flight — the rocket-engine loop made it sound like it
was burning; bounces still audible
Verified: reimport + smoke test 0 failures, 11/11 movement tests.
Co-Authored-By: Claude Fable 5 <[email protected]>
|
||
|
Nicholas ButzkeandClaude Fable 5
|
a9b0775de3 |
feat: real gunshots, localized 3D audio, seamless music, better animations
Audio: - All ballistic weapons now fire real firearm recordings (The Free Firearm Sound Library, CC0): AK-47 uses actual AK-47 shots, M4=AR-15, MP7=PPSh, AWP=Mosin Nagant, DMR=Savage 10, shotgun=Mossberg/Nova, nailgun=Ruger .22, rocket/mortar layered with real booms. Plasma keeps its energy sound. - Reload is real lever-action foley instead of interface clicks - Projectile flight loops localized: unit_size 50->6, max_db 6->0, max_distance 45 — no more mortar/rocket drone in every player's ear; loops also got proper loop_end (was a zero-length loop) - Flight loops lowpassed into soft whooshes instead of sci-fi engine drones - Menu music converted to OGG with native full-track looping (47s seamless, replaces the broken manual WAV loop points) Animations (movement-shooter pass): - Rebaked miku.glb with 4 new clips from the CC0 library: Grapple (swim reach — reads as a swing), PistolIdle (armed idle with weapon up), PistolShoot, PistolReload - Armed idle: standing with a weapon now uses PistolIdle instead of arms-at-sides - Slide pose overhaul: legs kick out front (lead/trail thighs, knees straighten) — feet-first slide instead of "sitting in a crouch" - Wall run: forward drive pitch + inner arm reaches out to the wall - Per-transition blend times: dash/hit/jump cut fast (0.05-0.08s), locomotion cross-fades smoothly (0.2-0.25s); CrouchWalk speed-scales Fixes: - Third-person camera no longer renders the first-person viewmodel layer (the gun/arms floated in front of the third-person view) Verified: 11/11 movement tests, smoke test 0 failures (17 clips resolved), third-person run screenshot shows grounded animated model, no floating gun. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
6c8b0ddd28 |
feat: cel-shaded look & feel overhaul — real audio, comic UI, themed VFX
Audio (all CC0 — Kenney packs + OpenGameArt, see assets/sounds/SOURCES.md): - Replace every procedural synth WAV with forged sounds (ffmpeg pitch/layer mixes): distinct fire sounds per weapon with 2-3 variations, explosions, footsteps x5, land/jump/dash/vault, knife swing, hit/kill confirms, bullet impacts, reload, flight loops, UI hover/click/confirm/error, match jingles, menu music - AudioManager.stream_for(): AudioStreamRandomizer per sound id — every weapon now gets variation + pitch randomization on each shot - Explosions and bullet impacts play positional audio; landing has its own sound instead of a pitched footstep; ambient wind bed on every map Visuals: - ExplosionVFX: shared cel-shaded burst (white-hot stepped core, ink shockwave ring, star spikes, flat smoke puffs) replaces the orange sphere in both local and remote-replay paths - Comic star muzzle flashes on all weapons; unified cel tracer bolts with ink outlines across hitscan/shotgun/remote paths - Impact decals: hard-stepped ink-splat gradients instead of soft airbrush - Toon shading on first-person view models + arms, third-person weapons, and the procedural humanoid fallback (no hull outlines on FBX weapons — their hard normals tear the inverted hull) - Fix: giant soft "blob" highlight on floors — toon rim/specular disabled on level-geometry materials (pre-existing artifact since the cel commit) - Fix: own third-person weapon rendered into the first-person camera (shadows-only now covers first_person_mode) UI: - UITheme: comic theme on the root window — Bangers display font (OFL), paper panels with thick ink borders + hard drop shadows, papaya accent, themed buttons/inputs/popups; hover/click sounds on all menu buttons - Main menu: tilted comic wordmark, sunset toon diorama, looping menu music - Match HUD: themed scoreboard/killfeed/kill counter Viewports: - 4x MSAA project-wide + viewmodel/diorama viewports (crisp ink lines) - Viewmodel camera near plane 0.01; third-person camera FOV syncs settings - debug/visual_capture.gd: dev tool to screenshot menu + level for review Verified: 11/11 movement tests, spawn smoke test 0 failures, before/after screenshot comparison of menu and level. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
5bcbcfdc3f |
feat: emotive animations + anime speed lines — hit flinch, dance emote (B)
- SkinnedPlayerModel: generic play_oneshot() (generalizes the Land lock), Hit and Dance in the clip table (Dance loops), restartable clips - Hit flinch: victims visibly react on every peer's screen via the existing damage broadcast — no new RPC - Dance emote on B: toggles while grounded and idle, breaks on any movement; synced to remotes via synced_is_dancing (all three spawner configs) - Anime radial speed-lines overlay (canvas shader): fades in past ~1.2x walk speed, spikes on dash, widescreen-corrected clear center - New input action 'emote' (B) in project.godot 11/11 FSM tests, spawn smoke 0 failures. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
37c15bed1a |
feat: cel-shaded look — toon shader, ink outlines, stylized environment
- toon.gdshader: banded diffuse with cool-tinted shadows (3 tones), stepped specular, rim light, and an optional world-triplanar albedo path so level geometry keeps the 0.5 m grid with no UVs - toon_outline.gdshader: inverted-hull ink outline, applied via material_overlay so it works on skinned (deforming) meshes - LevelMaterials: tinted() now returns toon grid materials; toonify()/ apply_toon_recursive() convert imported character/prop materials in place - SkinnedPlayerModel: characters get toon shading + outline on load - LevelEnvironment: shared stylized environment for all maps — saturated anime sky, linear tonemap (filmic/ACES crush cel bands), bloom for emissives, saturation+contrast grade, light depth haze; test level and dust2 now use it and the procedural arena (which had NO environment) gets it plus runtime toonification of its baked geometry Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
2c7b5a1aca |
feat: lighter air control (steer + stronger strafe) and 2-charge dash
- Air: direct steering bends existing velocity toward input without changing its magnitude (air_steer_rate), on top of Quake accelerate with raised gains (air_strafe_accel 55->90, per-tick cap 1.2->2.5). No-input air drag nearly removed so held momentum carries. Steering skips opposing input to avoid flipping through zero. - Dash: charge system on the machine — dash_charges (2) spend instantly, each recharges in dash_cooldown (2 s). get_dash_cooldown_remaining() now reports time to the NEXT charge (0 while one is banked) so existing HUDs keep working; get_dash_charges() added for pips. - Tests: dash tests updated to the charge API + new coverage for spend-2-then-recharge; 11/11 pass, spawn smoke clean. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
198345177a |
feat: world-grid level materials + real movement test suite
- Generated CC0-style prototype grid textures (0.5 m cells) and a shared LevelMaterials factory: world-space triplanar mapping over every code-built level (test level, dust2, procedural arena) with the existing color coding kept as tints. Readable surfaces at speed instead of flat color boxes; materials are cached per tint so identical surfaces batch. - .gdignore + .gitignore the raw downloaded asset packs in addons/ whose overlong paths broke Godot import scans and spammed git warnings. - Replaced the rotted FSM test file (invalid call(t) on Callables, stateless stub nodes, hung forever without quitting) with a real suite: 10 tests covering state registration, jump bookkeeping, wall-run momentum preservation and upward-carry cap, per-player dash cooldown (regression for the old shared static), dash speed stacking, chain soft cap, landing events, and slide entry momentum. New headless entrypoint: godot --headless --path . -s res://movement/tests/run_fsm_tests.gd Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
7da7f9f3f2 |
feat: rebuild character skin with full 13-clip CC0 animation set
The shipped skin GLB only had Idle/Walk/Run/Jump, so Slide, WallRun, Crouch, Dash, Fall and Land all fell back to the wrong clips. Rebuilt via the Blender pipeline from the library-skeleton rigged model (the old miku_proper_anim was on a different skeleton, so retargeting silently baked flat clips — and the shooter pose layer's DEF-* bone names never matched it either). miku.glb now ships Idle, Walk, Run, Sprint, Jump, Fall, Land, CrouchIdle, CrouchWalk, Dash (roll), Death, Hit, Dance from the Quaternius Universal Animation Library (CC0). Verified per-bone keyframe motion in the export and rendered pose stills for deformation QA (no crossed arms / stretched feet). Also removed five stale experimental skin GLBs + extracted textures and the one-off editor import scripts; skins.json now lists only the working skin. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
0ba14a9469 |
feat: overhaul movement for flow — momentum-preserving states, smooth crouch, landing feel
- Quake-style air-strafe accelerate (real speed gain from strafing; external speed from dash/rockets never clamped) - Wall run: keeps entry momentum (incl. upward carry), accelerates along the wall instead of hard-setting velocity, gravity fades in over the run - Slide: slope physics (gravity projected along floor accelerates downhill), flat-ground decel instead of multiplicative friction, entry boost, direct slide->wallrun and slide->dash transitions - Dash: cooldown 10s -> 2s, per-player (was a static shared across instances), momentum fully kept on exit, FOV punch event - Grapple: taut pendulum with active rope control (W reels in, S pays out), release keeps swing energy - Wall climb: carries upward momentum in, jump-off kick, shared vault helper - Crouch capsule: single owner in the machine, smoothly lerped, ceiling check; camera eye height follows via crouch factor (no more head snapping) - Landing: machine emits 'land' events scaled by impact; camera dip + pitched down thud; footsteps get pitch variation - Camera rig: event-driven (land dip, dash FOV kick, vault pitch impulse), slide roll tilt - Model: Jump vs Fall split by vertical velocity, Land one-shot on heavy landings, wall-run body lean (synced to remotes via synced_wall_side) Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Opus 4.8
|
c4a538a469 |
chore: add miku_test skin textures and script .uid files
Godot import artifacts that pair with already-committed assets: - miku_test_Image_0..3.png: textures extracted from miku_test.glb on import - .uid files for spawn_smoke_test.gd and audio_manager.gd Co-Authored-By: Claude Opus 4.8 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
29fdca3565 |
feat: shooter animation feel — directional lean, slide, composed airborne, weapon hold
Layer a procedural SkeletonModifier3D (ShooterPoseModifier) on top of the base clip so the character reads like a movement-shooter avatar: - Directional lean: banks into the movement direction (right/left/back) and blends smoothly for diagonals, driven by velocity relative to facing. - Slide: leans the torso back and pitches the head up to look forward, instead of the base clip's forward-torso/legs-out "spine break". - Airborne: plays a composed Jump pose (weapon ready) rather than a flailing fall. - Weapon hold: the base clip already keeps the arms down (weapon at the hip); on ADS both arms lift and swing in toward centre-front to aim. ADS is read from the active weapon and synced (synced_is_ads) so remote players raise their weapons too. The controller feeds movement direction + ADS to SkinnedPlayerModel.set_locomotion() each frame (works for local and remote via synced velocity/rotation). All rotations are authored in skeleton space (fwd=+Z, up=+Y, right=-X) and converted per-bone; tuning constants are at the top of ShooterPoseModifier. Verified by rendering the poses (idle/strafe/back/slide/ads) in a real Godot viewport. Smoke test 30/30. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
9939e7e524 |
fix: correct rig deformation — arms no longer cross body, feet no longer stretch to center
The model animated but deformed wrong: arms crossed the torso and foot heels stretched to the model's center-bottom. Two root causes, both fixed: 1. Pose mismatch. Sketchfab models are modelled in an A-pose (arms angled down) but the Quaternius library rests in a T-pose. Binding the A-pose mesh to T-pose arm bones misweighted the arms, and the library clips (which rotate arms ~70° down from the T rest) then shoved the already-drooped arms across the body. Fix: autorig.fit_arms_to_mesh() reorients each arm bone chain along the model's real arm direction; merge_animations retargets every clip from the library's T-pose rest onto the fitted rest via world-space constraint bake (Copy Rotation/Location + nla.bake), so world motion is reproduced regardless of the rest difference. 2. Feet-to-center stretch. The library's deform-flagged `root` bone runs up the body centre-line; nearest-bone weighting assigned inner-foot/heel verts to it, stretching them to center when animated. Fix: exclude root/control/mechanism bones from weighting (_NON_DEFORM_HINTS). Also upgraded nearest-bone weighting from rigid (1 bone/vert) to a smooth inverse-distance blend across the nearest 4 bones, so joints deform cleanly. Bone-heat still fails on Miku's joined hair/clothing mesh, so this is the primary path. Verified by rendering Idle/Walk/Run poses (Blender): natural stance, arms at sides swinging correctly, feet planted, proper running stride. Smoke test still 30/30. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
22cb0a58b7 |
fix: T-posing skinned models — autorig produced an orphan skin with no weights
The model animated its skeleton but rendered a permanent T-pose: the mesh wasn't skin-bound. Root cause was in autorig's binding, introduced while chasing an earlier "skins:0" export: - The earlier "skins:0" was actually caused by bone-heat weighting failing (0 weighted verts → empty skin gets dropped), NOT by the Armature modifier. - The "fix" then stripped the Armature modifier and used parent_type=ARMATURE. That makes the glTF exporter emit a skin OBJECT but with no node.skin reference and no per-vertex JOINTS/WEIGHTS — an orphan skin. The mesh then renders its bind pose (T-pose) forever while the skeleton animates unseen. Fix: keep the standard ARMATURE_AUTO result (Armature modifier + vertex groups). With the nearest-bone fallback ensuring real weights, the exporter now writes a COMPLETE skin (verified: meshnode.skin=0, JOINTS/WEIGHTS present). Also: - skinned_player_model: _ensure_meshes_bound() re-binds any skinned mesh whose skeleton NodePath doesn't resolve at load — graceful degradation instead of a silent T-pose for imperfect GLBs. - smoke test now asserts the spawned player's mesh is bound to its skeleton, so this class of bug fails the test instead of shipping. 30/30 pass. - regenerated miku_test.glb with the corrected pipeline. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
e2fbc424a7 |
feat: third-person camera toggle (V) + fix first-person showing inside the model
The first-person head-shrink (SkeletonModifier3D) left the camera looking at the inside of the neck/torso/hair. Replaced it: the owner's model now renders shadows-only in first person (clean FPS view, still fully animated and visible to others and in shadows). Added a third-person toggle (V / toggle_camera_view) so you can actually see your own animated model — the easiest way to verify a new skin's animations: - over-the-shoulder SpringArm3D camera (wall-collision aware) on the local player; press V to swap, press again to return - firing still uses the first-person camera, so aim is unchanged - reveals the owner's model via set_owner_visible() on both SkinnedPlayerModel and HumanoidModel; hides the first-person weapon viewmodel while in TP - death forces first person so the toggle can't fight the death cam Smoke test extended to cover the toggle (camera boom created, becomes current, round-trips) — 28/28 checks pass for both color and GLB skins. Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
64bbbf93c6 |
fix: make the character pipeline work end-to-end in Blender 5.1 + bundle CC0 animation library
Verified the full chain on a real Sketchfab model (Miku UID -> rigged -> 13 clips -> loads and animates in-engine, 24/24 smoke checks pass). Fixes found while running it for real: - sketchfab_import: read .sketchfab_token as UTF-16/BOM too (PowerShell's `echo >` writes UTF-16LE, which crashed the UTF-8 reader) - autorig: rig to the animation library's OWN skeleton when _library.glb is present (zero retargeting); robust binding — fall back to rigid nearest-bone weights when Blender bone-heat fails on complex meshes (Miku's joined hair/clothing gave 0 weighted verts); export as parent_type=ARMATURE with no modifier (Blender 5.x only emits a glTF skin in that exact form — a lingering Armature modifier gave skins:0); export_apply=False (applying modifiers baked away the skin); flatten the Sketchfab empty hierarchy before binding - merge_animations: support a single multi-clip library GLB via LIBRARY_CLIP_MAP; version-safe fcurve access for Blender 4.4+/5.x slotted actions (Action.fcurves was removed) Assets/tooling: - bundle assets/characters/animations/_library.glb — CC0 Quaternius Universal Animation Library (13 game clips), + .gdignore so Godot skips the pipeline-input folder - requirements.txt (stdlib-only; documents Blender-python separation) - pipeline docs updated for the bundled library + swap instructions Co-Authored-By: Claude Fable 5 <[email protected]> |
||
|
Nicholas ButzkeandClaude Fable 5
|
d05477c135 |
feat: Sketchfab-to-game character pipeline, FP/TP animated views, client-auth netcode, audio system
Character pipeline (tools/): - sketchfab_import.py: search/download via Sketchfab Download API with license/attribution tracking (SKETCHFAB_API_TOKEN) - autorig.py: headless Blender auto-rig — fits a Mixamo-named skeleton to unrigged humanoids, binds automatic weights - merge_animations.py: merges the shared Mixamo-skeleton animation library onto any rigged character, strips root motion, canonical names - pipeline.py: one command chains download -> rig -> animate -> register In-game skin system: - SkinManager autoload reads skins.json (auto-written by the pipeline) - SkinnedPlayerModel rewritten: canonical clips with fallback chains, blend times, speed-scaled locomotion, weapon bone attachment - First-person: full animated body for the owner, head hidden via SkeletonModifier3D; third-person: full model for other players - Skin selector in main menu; skin id synced in multiplayer - Fixed GLBLoader crash (GLTFDocument.get_animation_count doesn't exist) Multiplayer sync overhaul: - Movement is now client-authoritative: the owning peer simulates locally (no input round-trip), server keeps health/kills/death - Remote players interpolate synced_position/velocity with extrapolation and snap-on-teleport - Knockback/impulses routed to the simulating peer Audio: - AudioManager autoload: SFX/Weapons/Footsteps/UI/Music buses, pooled 3D players, variation + pitch randomization, auto-registration from assets/sounds Docs: 3D_ASSET_PIPELINE.md rewritten end-to-end, new ASSET_SOURCES.md (non-procedural animation/map/sound sources) and SOUND_DESIGN.md. Verified with debug/spawn_smoke_test.gd (headless: 24/24 checks pass). Co-Authored-By: Claude Fable 5 <[email protected]> |