6197ee7f5e
All checks were successful
Deploy to Production / deploy (push) Successful in 1m1s
Two coordinated polish moves the owner asked for.
## 1. Hero particle field — "no white dots, just a glow that follows the mouse and is always in motion"
Previous tuning (uPointSize 2.8, uBaseAlpha 0.6) gave discrete indigo
dots that additively saturated to near-white in dense clusters. The
owner wanted no granular dots visible at all — a continuous indigo
cloud that the cursor pulls toward itself.
Changes:
- **Render fragment**: replaced the anti-aliased disc SDF
(`smoothstep(0.5, 0.42, d)` — hard edge) with a Gaussian falloff
(`exp(-d * d * 6.0)` — smooth blob, no edge). Each particle is now
a soft volume that blends seamlessly with neighbours.
- **Sim fragment**: replaced the outward-gradient ring push with a
mouse-halo attraction. Particles drift toward an ideal radius
(~0.20) around the cursor, with exp-bell falloff so they don't
collapse onto the cursor or feel influenced from across the canvas.
`ringField()` helper is now unused but kept for future use.
- **JS uniforms**: `uPointSize` 2.8→14 (256-tier) / 3.6→20 (128-tier);
`uBaseAlpha` 0.6→0.055. Individual particles are below the
perception threshold for "dot" but 65k of them additively composite
into a continuous cloud. With the much lower per-particle alpha,
the cumulative brightness never saturates to white.
- **ParticleField tick loop**: asymmetric ring-active fade — `alpha
= 0.14` ramping in (fast cursor response), `0.012` decaying out
(slow glow trail after the pointer moves away). Matches the brief
"glow longer + attractive to mouse but always in motion".
- **ParticleHero index.tsx**: added an always-on indigo radial
gradient behind the WebGL canvas, so the hero never reads as
visually empty between frames — the canvas additively paints the
dynamic cloud on top. Removed the white-dot stipple from the
static fallback (it was the most likely source of the "weisse
punkte" complaint for any visitor on the fallback path).
## 2. SMS login — pre-select country picker from visitor's geo-IP
The country picker on `/login` previously defaulted to `'CH'` for
everyone. Visitors from DE / AT / US / etc. had to manually scroll
to their dial code — small friction but it sits on the highest-stakes
conversion step in the funnel.
- **New API route** `apps/api/src/routes/geo.ts` →
`GET /v1/geo/country` returns `{ country: 'CH' | 'DE' | … | null }`
by reading Cloudflare's `CF-IPCountry` header. Public, no auth —
reading a 2-letter country code from a geo-IP header isn't PII
under GDPR / DSG. `'XX'` and `'T1'` (CF's "unknown" + Tor) are
normalised to `null`. Outside CF (dev), header is missing → null.
- **Login page** picks up the result in the existing `useEffect`,
guards against codes not in our country list, and calls `setCountry`
to override the `'CH'` default. Stays at `'CH'` if the detection
fails or the visitor is on a Tor exit. Verified live: the endpoint
returns `{"country":"DE"}` from CF's German edge.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| videos | ||
| llms.txt | ||
| sw.js | ||