Talk:Roads
From Rise: The Vieneo Province
Roadside sign development notes
The player reference is Roads: Roadside signs. Development, rollout and optimization discussion belongs on this Talk page. Main-namespace articles and player-facing categories should describe implemented behavior directly, without release announcements such as "(upcoming client update)" or "The next client update".
Implementation notes below describe the client code checked on 30 October 2026.
Moore neighborhood and cached geometry
- Dynamic signs are generated for a 3 by 3 Moore neighborhood of full plots: the current plot and its eight surrounding plots. The placement loop covers terrain-grid indices 30 through 32 on each axis. Only built user roads with the necessary terrain elevations qualify; RTS district plots are excluded. District signs remain part of their authored road meshes.
- This follows the same neighborhood idea as rocks, but the cells differ: rocks use a 3 by 3 neighborhood of plot quadrants, while signs use full plots.
- The nearby signs share one vertex buffer with bounds and draw ranges for each sign. Unchanged terrain/road data reuses the buffer rather than rebuilding the sign geometry every frame.
- Cache invalidation inspects a wider 6 by 6 dependency region (indices 29 through 34). It includes terrain positions/control points, road flags, plot type/zone, elevation availability, build-zone assignment and loaded RTS tile texture/rotation data. This catches neighboring road edits and district data arriving after terrain. This wider metadata check does not generate signs for all 36 plots.
Distance, camera view and lifecycle filters
- Before a sign's lighting setup or draw call, its bounds must be within 1.5 km of the player/vehicle position. Distance is measured to the nearest point on the sign's bounding box, not to the plot centre.
- The same bounds must intersect the current camera view frustum, using the world, view and projection matrices. Signs wholly outside that view are skipped; partial intersections remain eligible. Cached geometry outside the view is not automatically a draw call.
- These are distance and view filters, not an occlusion query or a promise of readability. Terrain, buildings, rocks, darkness and weather can still obstruct or limit visibility.
- The sign cache is cleared in the in-world simulator, when terrain patch geometry is absent, or above 780 m AGL. The update runs before the rendering branches, so simulator entry clears cached exterior signs; returning to eligible conditions rebuilds from current data. The draw path also rejects simulator rendering.
- Device teardown releases the sign buffer/texture and resets asset loading for the next initialization.
Distributed assets and night rendering
The client loads 20 standard Makeship DAWs directly from Meshes/Signage, with one shared Textures/Signage-Atlas.png. There is no distributed WLD Source subfolder or custom sign bundle. DAW positions are already in kilometres. Printed sign faces return headlight illumination toward the driver; posts and backs retain ordinary lighting. Sign placement, the 80 km/h policy and the first-bend-only district warning are independent of this asset-format choice.
Verification and rollout discussion
The local x64 Release and 1,014 road-sign checks passed after the DAW migration, including all 20 models, malformed-file rejection, placement and offscreen rendering. Nighttime fixture measurements matched the previous geometry. These checks establish implementation behavior; they do not establish live driving acceptance or public client distribution status. Keep deployment timing and future implementation proposals here rather than adding release-status qualifiers to the player article.
Code references: Viewscreen/RoadSignRendering.cpp, Viewscreen/RoadSignAssets.h, Viewscreen/GeometryBounds.h, and Viewscreen/render.cpp. Detailed local verification records are in docs/UserRoadSigns.md, docs/RoadSignNightLighting.md, and docs/RoadSignDawMigration.md.