01Overview
This section is scaffolded to match the completed case-study structure. The final copy can drop into the same rhythm: overview, problem, tool design, architecture, interaction media, and lessons learned.
{item.placeholders.map((title, index) =>
)}
02The System
Placeholder text for the system design. This will describe the authoring model, where the procedural state lives, and how artists interact with the tool.
WORKFLOW / PLACEHOLDER
{item.project}
{["Input", "Tool State", "Procedural Solve", "Output"].map((node, index) => (
))}
NOTES
CONTENT PASS
{`case_study = {
"status": "placeholder",
"media": "pending",
"copy": "pending",
}`}
03Next Content Pass
Once the final material is ready, this tab can be filled with real media, specific workflow notes, and the same production-minded tone used in the Building Tool case study.
);
}
function RoadGeneratorBody({ item, onOpen }) {
return (
{item.headline}
{item.subtitle}
01The Problem
Road tools can become brittle when the road surface, intersections, sidewalks, curbs, and markings are treated as one swept mesh. The result is hard to clean, hard to shade, and hard to debug once multiple roads overlap.
This tool keeps those systems related, but separate enough that each layer can be solved, inspected, and cleaned with its own rules.
02The Approach
{item.intro}
- Asphalt is solved as polygon footprint geometry
- Curbs and sidewalks are generated from cleaned boundary curves
- Lane markings are independent guide/decal curves
- Intersections are masks and custom logic
- Attributes act as the contract between generation, materials, debugging, and cleanup
03Interaction Reels
These clips show the authored curve workflow and the procedural intersection response: the artist edits path input, while the generator rebuilds road footprints, lane guides, and cleaned boundaries from the same network state.
{ROAD_MEDIA.map((media) => )}
04Profile System
Road width is derived from lane count, lane width, two-way traffic, bike lanes, gutters, curbs, sidewalks, lane dividers, and center divider widths.
Profile segments are tagged with attributes such as sidewalk, curb, gutter, pavement, bike_lane, travel_lane, lane_divider, and center_divider so downstream systems can reason about what each generated strip represents.
05Intersection Strategy
Intersections are solved in 2D plan view rather than by overlapping full swept road meshes. The asphalt footprint is unioned first, then masks and custom logic handle intersection regions before boundary curves are extracted.
06Boundary Cleanup
Boundary curves are cleaned with Fuse, Polypath, colinear point removal, graph-based neighbor logic, and corner rounding. Curb sweep orientation is stabilized using outward normal solving against asphalt reference geometry.
Curve rebuilds preserve vertex UVs, and small isolated geometry fragments are removed through connectivity-based cleanup.
07What I Learned
The useful abstraction is not the center curve by itself. It is the contract between center curves, profile attributes, footprint geometry, boundary cleanup, and sweep-ready outputs.
Keeping those layers explicit makes the tool easier to debug and gives production artists cleaner handoff points for materials, decals, sidewalks, curbs, and other city-layout systems.
08Future Plans
The current road generator focuses on the foundation: profile-driven road widths, intersection footprints, curb and sidewalk boundaries, lane guide curves, cleanup utilities, and material-friendly attributes.
The next pass would move the tool from procedural road construction toward a more complete city-layout authoring system. Planned work includes intersection dressing, traffic-light placement, road markings, sidewalk props, and custom Viewer State controls for editing lanes, sidewalks, and intersections directly in the viewport.
{item.futurePlans.map((plan, index) => (
{String(index + 1).padStart(2, "0")}
{plan.title}
{plan.text}
))}
);
}
function RampRoadTerrainBody({ item }) {
return (
01Overview
{item.intro}
{item.description}
02System Breakdown
{item.breakdown.map((step) => (
-
{step.num}
))}
03Reusable Attachment Pattern
The important part is the relationship between the Unity-authored source curve and the generated Houdini assets. The path remains the source of truth, while attached tools read its output and solve their own procedural result from that relationship.
That makes the setup useful beyond the quarter-pipe example: the same pattern can drive curbs, rails, barriers, ledges, sidewalks, and other border assets that need to stay editable as gameplay layout changes.
);
}
function CaseStudy() {
const [lightboxItem, setLightboxItem] = useState(null);
const [activeId, setActiveId] = useState(TECH_ART_CASES[0].id);
const activeCase = TECH_ART_CASES.find((item) => item.id === activeId) || TECH_ART_CASES[0];
const isBuildingTool = activeCase.id === "building-tool";
const isRoadSystem = activeCase.id === "road-system";
const isRampRoadTerrain = activeCase.id === "ramp-road-terrain";
useEffect(() => {
function handleSelect(event) {
const nextId = event.detail?.id;
if (TECH_ART_CASES.some((item) => item.id === nextId)) setActiveId(nextId);
}
window.addEventListener("tech-art-select", handleSelect);
return () => window.removeEventListener("tech-art-select", handleSelect);
}, []);
return (
{w.logoRight && 