I have solved most of the remaining issues with the traffic system.
I have found some problems related to paging the cities in and out, but these were preexisting.
There is an also an issue with the AI spawning in the wrong location that I need to fix, and I need to do some more testing on the mechanics of the system, but it is mostly done.
The only work remaining is to add the placeholder art and some final, last-minute, improvements.
The idea that I had to solve the direction of travel problem seems to work, but it was more complex that I thought.
Searching for the nearest intersection node in the grid was quite complex, especially when I needed to make sure that it was an intersection with no obstructions (such as buildings, etc) in between.
I was eventually able to solve this, but there were still other minor issues relating to collisions between vehicles, etc.
I also had to add a solution for a situation where the AI could no longer travel in any direction. To resolve this case, I simply had the AI change lanes if there was no path possible on their current lane.
This solution now works reasonably well.
There are still some minor issues to fix, and I still need to add some simple placeholder art, but the main work on this seems to be done.
I can now generate all of the required graphs for the vehicles, and it can be done without any noticeable performance impacts.
The next goal is to get the AI vehicles to travel around the graph to random points without colliding.
I tried a few solutions to this problem, but none have worked yet.
The main problem is that the A* graph system does not respect direction, so the AI vehicles can travel in both direction on the same “lane”, which causes them to collide with the vehicles behind them.
The next solution that I am about to try is to allow the AI to only travel in two directions, forward, and either right or left depending on which lane the AI is in. Then, I can search for the nearest intersection node on the graph that is in that direction, and move toward that.
In addition to finishing the ground cover exclusion system, I have also fixed several bugs with the project. These were mostly minor bugs related to object positioning in the world, etc.
I also fixed a minor issue with the new road system.
There are still a few minor bugs that I want to look at in the next few days, but I am more or less ready to move on now.
The next goal is to work on adding a better decal system to the project that works properly with the terrain system tha I am using.
Then,I want to work on a “traffic” system for cities. I want to have AI generated vehicles driving in a reasonably realistic manner on roads, etc.
Eventually, I want to extend the traffic and road systems, so that I can have roads being drawn across vast distances, with AI vehicles traveling along them.
After a lot of work, I have managed to get the ground cover system working.
I have rewritten the point and plane projection code to use non-unity methods, which should, first of all make it faster, and second of all, it will allow me to use this code from another thread.
I am using a variety of techniques and improvements, but the main one is async/await. I have never used this technique before (Although I have used other multithreading techniques) but async/await should be massively useful for my project in the future.
It differs from other multithreading solutions in its ability to return data from it’s task, which greatly simplifies its usage.
I also changed my logic for the ground cover system once again, and, due to a combination of solutions working together, I was able to get very good results even in highly-dense parts of the world.
This is fortunate, because the only other solution that I could come up with was to dynamically decrease the resolution of the generated textures when the user approached settlements, and increase the resolution again when they left. This worked, but was not optimal.
I replaced the build in terrain function with another solution, which projects a point onto a plane. I could use this to get all of the needed points onto the same plane, so that I could get the distance between them. I could then use this distance to determine which pixels should contain ground cover, and which shouldn’t.
This solution was much faster, and seemed to work, but when the player approached areas with a lot of ground cover exclusion objects (such as settlements, etc), it too became slightly too slow.
I am now looking into multithreading as a solution, but I will need to rewrite quite a lot of code to make it thread safe (transform.transformpoint, etc).
I cannot call setpixels from another thread, but the main bottleneck is in loading the array for setpixels, this is where I need to improve performance, so multithreading should be useful.
I had a solution working, however it was much too slow (I was getting the exact world space position of every UV coordinate on the terrain, using the terrains own function for this purpose, however this function was never meant to be called in a loop like this).
Even with extensive refactoring and improvements (changing from setpixel to setpixels, etc) this function was still too slow, so I either need to work on multithreading, or find another solution that is faster.
I can also reduce the resolution of the actual ground cover exclusion textures, but this is not ideal, since it means that smaller objects can easily get lost in the ground cover.