Project Description
ApexRR is a browser-based cycling and running platform that places 3D athletes over real-world route video, so this is not a full 3D game world. Assets must be designed for clean silhouette, believable athletic motion, strong Garage presentation, efficient WebGL/browser runtime, clean GLB import, and scalable quality across a range of hardware. The product needs cycling and running, a high-quality Garage/customiser view, a race/session view with distance-based quality reduction, support for around 30 visible athletes, GLB delivery, and one shared athlete platform across male and female variants.
The brief is asking for one shared ApexRR athlete platform, not separate HD and LD products. That means one shared human rig standard, shared export/naming standards, shared male/female body archetypes, shared head/hair/material logic where practical, and separate sport-specific clothing, shoes and animation only where genuinely needed. The delivery model is one Garage hero asset per category, one race asset family per category, and race assets supplied as LOD0, LOD1, LOD2 and LOD3, with texture/material scaling built into the delivery approach.
For MVP, the shared male/female system should use 4 body archetypes: Male Standard, Male Lean/Sprinter, Female Standard, and Female Lean. All should use the same core skeleton, naming, animation compatibility, runtime attachment conventions, and broadly the same UV/material logic. Garage heads can be premium and suitable for front and 3/4 inspection, while race heads should be simplified, with detailed facial modelling not required. Female-specific garments should only be created where genuinely needed, such as sports bras or female running tops. Hair should use one modular system where practical, and facial hair can remain male-only unless otherwise agreed.
The runtime context is important: ApexRR is browser-based, the background is filmed route video, up to about 30 athletes may be visible, quality should reduce with distance, and the user’s own full avatar is usually not the main visible object in the primary POV. Because athletes are composited over filmed footage, the design priorities are silhouette, animation clarity, pose readability, compositing support, and runtime efficiency rather than tiny geometric detail.
The cyclist family should include 1 Garage hero cyclist and 1 race cyclist family delivered as LOD0–LOD3. The cyclist should include an athletic road-cycling body, jersey, bib shorts or shorts, cycling shoes, helmet, visor/glasses, optional gloves, and clean animation-ready topology. Target triangle counts are: Garage hero 30,000–45,000; LOD0 18,000–25,000; LOD1 9,000–12,000; LOD2 4,000–6,000; LOD3 1,500–3,000. Race face detail should drop quickly: simplified at LOD0, reduced at LOD1, effectively gone by LOD2 and LOD3.
The runner family should include 1 Garage hero runner and 1 race runner family delivered as LOD0–LOD3. The runner should include an athletic running body, running tops/bottoms, running shoes, and animation-ready competitive proportions. Target triangle counts are: Garage hero 20,000–30,000; LOD0 12,000–18,000; LOD1 6,000–10,000; LOD2 2,500–5,000; LOD3 800–2,000. Again, race face detail should be simplified heavily.
The bike family should include 1 source/master road bike per frame family, 1 Garage bike export derived from that source, and 1 race bike family derived from that source and delivered as LOD0–LOD3. The bike must remain a separate asset from the rider, align cleanly in ApexRR, support wheel and crank/pedal motion, and prioritise silhouette over tiny hidden detail. The intended workflow is not a separate hero bike sculpt plus a separate race redesign. Instead, the studio should build one strong source bike per frame style, then derive the Garage version, LOD0, and progressively simplified LOD1–LOD3 from that same source. Extra bike workload should mainly be simplification, cleanup, optimisation, and material/texture reduction, not repeated redesign. Triangle targets are: Garage bike 18,000–25,000; LOD0 10,000–15,000; LOD1 5,000–8,000; LOD2 2,000–4,000; LOD3 500–1,500. Suggested variants can be priced separately, such as all-rounder, aero, climber and endurance/gravel, plus standard and deep-section wheels.
LOD delivery is important. ApexRR will use distance-based quality reduction in race view, but the studio is expected to deliver separate LOD assets. For each race family, LOD0 is for nearest visible athletes/bikes, LOD1 for near-mid distance, LOD2 for mid distance, and LOD3 for far distance with only strong silhouette and minimal material complexity. The brief specifically says not to rely on vendor-specific GLTF LOD extensions. Instead, separate named GLBs should be delivered so ApexRR can manage switching directly. In practice, the authoring expectation in tools like Blender is to create one approved source asset, duplicate it into Garage/LOD variants, simplify geometry progressively, reduce texture sizes and material complexity progressively, and preserve pivots, names, hierarchy and rig compatibility across all exports. Bikes especially should follow this derive-and-simplify workflow. Humans should also derive from one approved shared athlete platform, but with more work needed because of topology, clothing fit, rigging and deformation.
Texture and material rules are browser-first. Material counts should stay low, UVs should be efficient, atlasing should be sensible, and exported materials must be GLB-safe using PBR metallic-roughness. Human Garage hero assets should use 2K textures, with 4K only as an optional premium extra. Race textures should scale down by LOD: LOD0 up to 2K base color, LOD1 1K, LOD2 512, LOD3 256/shared atlas/tint-based. Bike Garage textures should be 2K, with race bike textures stepping down from 1K–2K at LOD0 to 256/shared atlas at LOD3. The platform should support shared skin tone logic, shared hair color logic, modular hair, modular facial hair where applicable, cycling kits, running kits and ApexRR house branding.
The brief also asks for scaling/runtime-ready delivery extensions. Base format is GLB, Y-up, metres, clean transforms, correct pivots and baked animation clips. Geometry should be suitable for Draco compression, and preferably also Meshopt-ready. Texture delivery should be compatible with KTX2 / BasisU workflows for browser compression. The brief does not want reliance on complex runtime material-variant or LOD extensions; instead it prefers consistent UV templates, swappable kit textures, tintable materials, simple modular meshes, and separate GLBs for Garage hero and LOD0–LOD3. Optional extras can be priced separately, such as KTX2-ready packaging, Meshopt-optimised delivery, impostor/billboard far-distance assets, and automation-friendly kit prep.
Rigging and animation should be standardised. The studio should provide a clean skeleton, named bones, consistent rig structure across male/female bodies and LODs, clean skinning, and stable deformation. Cyclist assets must support seated pedalling, hard seated effort, seated climbing, standing climbing, sprinting, coasting/idle, and rider-bike contact alignment. Runner assets must support easy jog, steady run, hard run, sprint, idle, and optionally walk/recovery jog. Animation packs should be loopable where appropriate, clearly named, and suitable for runtime speed control. The quote should cover cycling clips, running clips, Garage idles, and optional transitions or extra variants separately.
Finally, the quote should be broken down clearly into shared athlete platform setup, four body archetypes, cyclist hero + race LOD family, runner hero + race LOD family, bike hero + race LOD family, cycling animation pack, running animation pack, GLB export and source delivery, plus separate optional pricing for extra bodies, heads, outfits, bikes, wheels, transitions, impostors, KTX2 prep, Meshopt support, Garage upgrades and accessories. The overall requirement is a shared ApexRR athlete platform with premium-looking close assets, efficient race assets, strong animation and silhouette, and a clean scalable browser-ready delivery model.
Please review Mywhoosh, Zwift and Roovy systems for reference of animations.