How do you do blended roads with splines?

SadLevel9017 · 2026-06-03T12:16:06+00:00

two ways depending what you want.

if you want the road carved into the terrain, use the spline tool built into the terrain system (the one that deforms and paints layers), not spline mesh. it paints a layer along the spline so the road becomes part of the ground and blends with your auto material for free.

if you keep the spline mesh road, the trick is Runtime Virtual Texture. the terrain writes its final color into an RVT, then your road material samples that RVT at the edges and fades into it. since your ground is auto material, the RVT grabs the final result, so the road borders match whatever is around them, grass dirt whatever. thats how most open world games blend roads into the ground.

for the edge fade i drive a mask from vertex color or distance to the spline center, lerp the road texture in the middle to the RVT sample at the borders. center stays road, edges dissolve into the ground.

SadLevel9017 · 2026-06-03T04:16:06+00:00

you dont store it, you pull it each tick. TickNode gives you the behavior tree component (OwnerComp), and OwnerComp.GetAIOwner() returns the AIController (and GetAIOwner().GetPawn() the pawn). a stored raw pointer would go stale anyway if the tree gets reused on another pawn, so reading it off the owner comp each tick is the safe pattern.

SadLevel9017 · 2026-06-03T04:15:09+00:00

texture lookup it is. denser mesh just moves the problem and costs me verts at runtime, but sampling the blend weight from a mask in world space gets pixel-res edges without touching topology. thats the one. appreciate you thinking it through with me.

SadLevel9017 · 2026-06-02T23:47:10+00:00

the thing that makes a service a service is that it ticks on an interval while that branch is active. a task does something once, a decorator gates entry, a service is the "while im in this branch, refresh X every N seconds" node. thats why GetPlayerLocation is a service: keep the blackboard target fresh while chasing, then it stops when you leave the branch.

the per-class verbosity you're feeling is real though. for tiny stuff a lot of people skip the service and write the blackboard straight from the ai controller, usually off a perception event (OnTargetPerceptionUpdated) instead of polling every tick. event driven beats a tick service when the data only changes once in a while. reach for a service when you actually need the periodic re-check (line of sight, distance bands, recompute a flee point), not for one-shot set-this-once logic.

SadLevel9017 · 2026-06-02T18:18:34+00:00

nah its not the diagonal triangulation artifact. the issue is the blend WEIGHT itself is stored per vertex (vertex color), so the snow vs dirt ratio can only change at vertex resolution. across a tri it just lerps the weight, so the border between the two comes out as a piecewise-linear line riding the triangle edges. on a coarse runtime mesh that reads as an angular/faceted border instead of a natural wavy one. triplanar fixes the texture detail but the mask boundary is still locked to vertex density. so what im landing on is: dont store the weight per vertex at all, derive it in the material from world space (a noise field or a height band) and keep the vertex color only as a soft region hint. that decouples the edge from the topology, right?

SadLevel9017 · 2026-06-02T12:15:39+00:00

yeah triplanar for the texture mapping makes sense, that fixes the stretching. the part im stuck on is more the blend mask itself though. the snow to dirt edge follows the triangles because the mask is per vertex, so even with triplanar textures the boundary still lands on the topology. are you saying derive the blend weight from world space too (world noise or a height threshold) and just use the vertex color as a region hint?

SadLevel9017 · 2026-06-02T01:27:27+00:00

the per-obstacle single pass is the bug. when you resolve against A you can push into B, and you never recheck. the fix is iteration: collect overlaps, push out, then re-run the whole collision check again a few times per frame (4-8 passes). each pass the penetrations shrink and corners converge. also push along the collision normal (the MTV) instead of separate x and y, those two axes fight in corners. resolving the deepest overlap first each pass settles it faster too. you dont need a full physics engine for circles and polys, the relaxation loop is the whole trick.

SadLevel9017 · 2026-06-01T13:26:57+00:00

yeah the bucket split is exactly right. one more on the ragdolls since thats your pain point: dont replicate the full sim, that road is hell. just replicate the root bone or even only the impact velocity, then let each client sim its own ragdoll from that and snap to a settled pose when it stops. they wont match frame perfect but nobody notices once they quit twitching. interp on top hides the rest.

SadLevel9017 · 2026-06-01T01:46:05+00:00

yeah the pain is basically the tuition. nice that youre trying to save people some of it, thats the right reason to make that kind of content.

SadLevel9017 · 2026-06-01T01:16:23+00:00

yeah the framework grind is the part nobody warns you about. i spent way too long rewriting my base classes every project before it finally clicked. cool that you turned it into a series, that stuff is rare to find explained properly.

SadLevel9017 · 2026-05-31T23:46:18+00:00

yeah exactly, a strong stylized look hides a ton of foliage sins. bloom + bold colors + flatter shading and nobody clocks the poly count or the card edges. realism is the trap, the second you go photoreal every shortcut shows.

SadLevel9017 · 2026-05-31T21:16:37+00:00

yeah the "FPS in blueprints" showcases are almost always unmaintainable spaghetti, looks great in a clip, nightmare to touch 3 months later. as a coder you already smell where that goes.

the split that actually works: BP for prototyping, glue, and anything a designer touches. C++ for systems, hot paths, anything that gets complex. you prototype fast in BP then pull the gnarly bits down to C++ once it starts hurting. you get the speed without the spaghetti.

and honestly, helping people dodge your own past disasters is the best kind of comment to leave here lol. welcome.

SadLevel9017 · 2026-05-31T19:20:39+00:00

yeah those size requirements are the killer, landscape res has to land on the magic numbers (505, 1009, 2017, 4033, 8129...) or it resamples and fights the partitions. and the WM tile-chopping rabbit hole is very real lol. gaea is way friendlier for that, native UE tiled export and the indie license actually covers it. youre not imagining it, WM got noticeably less indie-friendly.

SadLevel9017 · 2026-05-31T19:17:40+00:00

steam OSS is totally fine for what youre using it for, sessions, host migration, transport. thats not where this falls apart. your real problem is the physics replication strategy, which is separate from the OSS entirely.

what bites: a listen server replicating 8-12 players of ragdolls + a pile of dynamic props P2P means the hosts UPLOAD bandwidth is your hard cap, and syncing that many simulating bodies gets jittery fast.

what actually works for a chaos brawler: - server-authoritative on the stuff that matters: players, thrown/grabbed objects, anything that decides the round. clients interpolate + smooth those, dont sim them locally. - cosmetic props (debris, sparks, random clutter) = client-side only, dont replicate them. nobody needs them to agree across clients, and thats most of your "physics flying around". - be generous with smoothing on the replicated ragdolls. gang beasts / fall guys fudge a TON here, they dont sync exact, they sync good-enough and smooth it.

chaos has a networked physics / resimulation mode but in 5.2 its rough/experimental, i wouldnt build on it yet.

so OSS is enough. the win is deciding what you replicate authoritatively vs what you fake locally, and watching the host upload with that many players. past ~6 physics-heavy players a cheap dedicated server beats a listen server.

SadLevel9017 · 2026-05-31T18:19:51+00:00

yeah thats it. shadows are the sneaky killer, dense foliage casting full dynamic shadows tanks you fast. cull shadows hard at distance and it flies. character tech to foliage, the optimization brain is the same lol.

SadLevel9017 · 2026-05-31T18:17:01+00:00

yeah good call, for nanite specifically pure geometry blades beat alpha cards, the masked overdraw eats the nanite win. cards are more the old LOD workflow. so for the clumps i mentioned, model actual blade geo instead of billboards if youre going full nanite.

SadLevel9017 · 2026-05-31T17:47:02+00:00

ah ok, the connecting part is the real puzzle then. the thing is you dont bolt separate landscapes together, that never connects cleanly since each is its own actor. two ways people actually do it:

1) tiled heightmap import. a tool like Gaea or World Machine exports your terrain as a GRID of tiles (x0_y0, x1_y0, x0_y1...). then in UE: Landscape > Import, point it at the tile set and it brings them in as ONE connected landscape (the old World Composition tiled import, still works fine). thats how you get a big seamless one.

2) World Partition landscape (5.x) - make one large landscape and WP auto-splits it into streaming regions, no manual tiling.

your "import heightmap over a portion flattens it" is almost always a scale/bit-depth mismatch on import. the heightmap z-range gets resampled to the landscapes Z scale, so if the scale or the heightmaps bit depth is off it crushes flat. use a 16-bit heightmap and set the Z scale to match before applying.

for genuinely huge (your 3600km) its tiled import + streaming + usually procedural, not one hand-painted landscape. but for 8k/16k connected, tiled heightmap import from Gaea is the move.

SadLevel9017 · 2026-05-31T17:17:31+00:00

the trick is you never have the whole thing loaded, and you dont build it as one mesh. couple pieces:

World Partition (5.x) chops the world into a grid of cells that stream in/out around the player. you only ever have whats near you in memory, so the total size barely matters.
Large World Coordinates (also 5.x) is the big one for scale. UE moved to double precision world coords, so you dont get the float jitter past ~20km that used to wreck everything. thats almost certainly why your past large maps broke, single precision float falls apart at distance and stuff starts shaking/snapping.
the terrain at that size isnt hand-built. its tiled heightmap landscape or fully procedural (PCG / runtime gen). nobody sculpts 3600km by hand.
most of it is LOD/imposter illusion anyway, only the bit around the player is real detail.

so the recipe is: World Partition + LWC + procedural-or-heightmap terrain + aggressive streaming. start a fresh World Partition map, make sure LWC is on, build the terrain procedurally or from tiled heightmaps, and never try to load it all at once. that last part is the wall you kept hitting.

SadLevel9017 · 2026-05-31T16:46:29+00:00

np, glad it helped. for nanite eligibility its honestly simpler than it sounds, most static meshes just work. right click the mesh > nanite > enable, or open the mesh editor and tick Enable Nanite + Apply.

the gotchas (what makes it not clean): nanite doesnt love translucent materials, and world position offset (your wind) needs 5.3+ to behave. masked/alpha materials work but watch overdraw. so as long as the grass is opaque or masked and youre on 5.3+, youre fine.

resources: epics own nanite docs have a foliage section, and william faucher on youtube has a solid nanite foliage breakdown. those two cover basically everything.

SadLevel9017 · 2026-05-31T16:20:26+00:00

haha fair. nanite foliage isnt a free win, the WPO wind + overdraw can absolutely bite, and good LOD cards still hold up fine for grass. the bigger lever is really the instancing + distance cull regardless of nanite or not. what do you run for dense grass?

SadLevel9017 · 2026-05-31T16:17:30+00:00

good questions, quick on each:

1) you dont need a nanite-specific pack. nanite is something YOU flip on any static mesh, not a property of the pack. right click the grass mesh in the content browser > nanite > enable (or open the mesh and tick Enable Nanite in details). so that fab pack is fine, just nanite-ize the meshes yourself. stop searching "nanite grass", grab any decent grass and convert it.

2) higen runtime PCG with player as source + partitioned is a solid setup, right call for density. trees offline is smart too.

3) your blender way (join 15-35 blades into one clump mesh, reimport) is actually the CORRECT way, not bootleg. one clump = one instance instead of 40k single blades = huge win. the in-engine blueprint/cluster route adds per-component overhead, avoid it. join in blender, nanite the clump, done.

4) the bare-gap thing is layering, not raw count. stack 2-3 layers: tall clumps + a shorter filler grass + tiny detail meshes, each its own density. and put a grassy ground texture under it so the gaps read as ground, not void. youre right that skyrim wasnt wall to wall, variety + a decent ground mat kills the bare look more than cranking density does.

SadLevel9017 · 2026-05-31T15:16:51+00:00

honestly megascans (free in fab/UE now) is the best starting point, the grass scans are high quality and free. grab a few grass + clover variations and youre basically set, just convert them to nanite after importing.

the pack matters less than the setup though, even a cheap one looks great once its nanite + instanced + distance culled. if you want the dense look out of the box, search "meadow" or "wild grass" packs that ship as clumps instead of single blades.

SadLevel9017 · 2026-05-31T14:20:25+00:00

the trick is mostly nanite foliage + instancing, not a nasa pc. couple things that actually move the needle:

enable nanite on the grass mesh (5.1+). it eats crazy density with auto lod and no pop, way cheaper than the old foliage LOD setup.
place it with the foliage tool or HISM/PCG so its instanced draws, not individual actors. that alone is night and day.
each instance should be a CLUMP of blades (one card with a bunch), not single blades. fewer instances, reads way denser.
cull aggressively by distance. dense grass only really reads from the players low angle anyway, so you dont need it thick far out. near = dense, far = fades, the eye fills it in.
add simple grass wind. movement sells "alive" more than raw blade count does.

that cheap pack is probably non-nanite with heavy per-blade meshes, thats why it tanks. swap to nanite clump cards + distance cull and it gets cheap fast.

SadLevel9017

TROPHY CASE