Roadmap
Tasks in this roadmap are arranged roughly in the order in which we plan to approach them. If you urgently need one of these problems solved, or you need a feature which isn't present in the roadmap, please contact us via email or Discord to discuss custom development.
1. Longitudinal landscape adjustment within the Path length
Errant Paths 1.0 introduced longitudinal landscape adjustment, which functions effectively even beyond the ends of a Path. However, issues can still arise within the Path itself, such as at tunnel entrances and exits, where adjustment settings change mid-Path. We are planning to enhance control over longitudinal landscape adjustments to better handle these scenarios.
2. Heightmap based landscape adjustment
When making rivers or dirt roads, it would be useful to be able to add noise or other texture based offset to the landscape adjustment.
4. Performance improvements
Long Paths currently take too long to generate. We have several optimizations planned to improve performance, including:
- Reusing components to avoid unnecessary spawning and destruction
- Implementing multi-threaded spawning
- Updating only the portion of the Path modified by the user (when adjusting a spline)
- Streamlining and optimizing the code
5. More examples in the ErrantPathsAssetLibrary
We'll also be adding examples to the Asset Library to showcase existing plugin features. We will certainly add more versions of the asphalt roads, with various intersections, roundabouts, transitions between 1-2-3 lane variants, additional turn lanes, etc.
We will also add new types of Paths, such as rivers, fences, etc.
Each of the existing Path types will also be further developed to add detail and automation.
6. UX improvements
There are many operations currently which take too many clicks and are too cumbersome. For example, adding an intersection to a road requires splitting the road, making a room for the intersection, then spawning the intersection and connecting both ends of the road to it.
We plan to streamline such operations significantly. For example adding a an intersection should simply require drag&dropping the intersection asset onto an exisitng Path. Then user should have a chance to rotate the intersection and spawn it. The Path should split automatically and attach to correct ends of the intersection.
We have ideas for improvements to many aspects of the plugin, including UI, visualizations, debugging, etc.
7. Scaling spawned content and landscape adjustment with spline point scale
In order to make Errant Paths a good tool for making rivers, we need to add support for scaling the Paths based on spline point scale.
8. Tools for "painting" PathTemplates over a Path
Currently, users must rely on procedural logic (PathLabels and SpawnConditions) to control which PathTemplates are spawned along a Path. This approach requires a solid understanding of various systems in Errant Paths, which can be challenging for new users. To improve ease of use, we plan to introduce a tool that allows users to manually select a PathTemplate and paint or fill the Path with it. This will simplify the learning curve while providing more manual artistic control. Additionally, procedural generation can still influence these manually placed PathTemplates, preserving programmability.
9. Advanced Path Labels that affect landscape/biomes/width/tilt and much more
Path Labels used for conditional spawning currently can only have two states at a given position along a Path - either true or false. This limits their use to making binary choices about the Path. We would like to add support for storing all kinds of data in Labels, including floats and custom structures, as well as providing ways to customize the Label visualization and input handling depending on the stored data.
Through these improvements, Labels would become a universal way of controlling all aspects of a Path, including its width, landscape adjustment, tilt/roll, the amount of spawned objects, dirt, snow, and much more.
10. Integration with PCG
We plan to add integration with PCG at different stages of the generation.
11. MultiPointSplineMesh
When adding meshes in PathTemplates, we sometimes want to place long meshes that span over the entire template. Especially in intersections, we often want to place lane markings across the whole intersection and bend that mesh along with the asphalt meshes underneath.
Unfortunately, SplineMeshComponent in Unreal has only two control points and can't be used conveniently in such scenario. We need a mesh that can have any number of control points and repeats along the spline. These control points can then be anchored to the meshes underneath to ensure correct bending.
Such a feature would also requires additional UI and visualizations.
12. Bendable intersections
We already support bending intersections with the main/secondary PathSplines. However, we lack tools/visualization for users to control how each part of the intersection bends with a given PathSpline (blend weights, similarly to skinning weights in skeletal animation). Currently we use a simple distance-based heuristic to calculate blend-weights, but this isn't enough.
Aside from that, we also need to add ways to ensure that certain parts of the intersection stay attached to each other. For example a curb on the corner of a street shouldn't desintegrate as you change the shape of the intersection.
13. Pathfinding
We already have Pathfinding, but it is disabled by default (in Editor Preferences) as it lacks performance, reliability and intuitive user interface. We plan to significantly improve all of these aspects.
14. Dividing HISMs into smaller components for better culling
We currently group StaticMeshes into a HISM (Hierarchical Instanced Static Mesh Component) even when these meshes are very far apart (within the same SubActor). This leads to large HISMs that might now work well with culling or other rendering optimizations. We plan to introduce a mechanism that only groups meshes that are close to each other.
15. Spawning/placing Paths at runtime (in-game)
As part of our push to make all of our plugins work at runtime, Errant Paths will also undergo architectural changes to allow for spawning Paths as part of gameplay.
16. Using different mesh variants depending on the Path shape
Curvy Paths made of SplineMeshes sometimes lead to overstretching these meshes, which doesn't look natural. We plan to add support for a SplineMesh and StaticMesh that contains several variants of the same mesh that represent various shapes (straight, 90-deg-left-turn, 45-deg-right-turn, etc). Errant Paths would then pick the variant that best matches the spline curvature, to avoid overstretching the mesh.
17. Better placement of UI for conditional spawning in PathTemplate blueprints
Currently, to edit a spawn condition for a mesh, user needs to click on the actor in a PathTemplate blueprint. Then the list of spawn conditions is displayed in a UI panel. We would prefer to show these conditions in mesh details panel or in the viewport. We haven't found a way to achieve that yet, but we will be trying to make that UI more intuitive.
18. Auto-conversion of straight-line spline-meshes to static-meshes
Spline-meshes that have a straight-line shape after spawning can be replaced with static-meshes without any loss in visual fidelity. Such conversion improves the rendering performance of Paths as static-meshes are cheaper to render than spline-meshes.
Errant Paths automatically performs this conversion when spawning meshes, but it currently converts only the meshes that have no attached children. We plan to enable it also for meshes with children.
Note that this system is disabled by default and needs to be enabled in Path properties and in PathTemplateStaticMesh/PathTemplateSplineMesh properties.
19. Complex Paths - combining multiple Paths into one
We would like to add support for combining different Path types into a single Path types. For example combining an "Asphalt", "BikeLane", "SideWalk" Paths into a single, "Street" Path.
Currently, this can be achieved via Dependant Paths, but we would like to explore this idea in much greater depth.