Collision, Camera, and Bug Fixing
Last week I said I would do:
- implement collision generation for transition roads
- implement rendering generation for left junction (currently only right side supported)
- implement collision generation for left and right junctions
- test a basic procedurally generated world including those junctions (not just the straight line we've seen so far)
Can you guess what did(n't) happen? Let me walk you through this week's worth of work.
Transition Road Collision
Pretty much as the title says. This allowed me to start testing the infinite road generation algorithm with different types of roads and transitions between them. For that I created 5 road section profiles with their respective rendering and physical materials (half of the textures I don't own and were borrowed for testing):
- flat asphalt road
- bumpy asphalt road
- dirt road
- bobsleigh road
- crash barrier
If you play a specific racing game, you may have recognized what inspired them. I made sure to test the systems by adding a lot of geometry to the sections, more than I had used so far. Of course a lot was broken both with collisions and rendering, which I fixed.
Camera Improvements
You may have noticed in previous blog's videos that camera was a bit jittery. I had assumed this was due to the (for now) long time it takes me to generate chunks (maybe? didn't profile). I was wrong, this is because I was interpolating movements with a very poor poor poor algorithm which was far too sensitive to FPS changes.
New algorithm has camera decide where it would want to be around car (depending on car's facing, velocity, steering, etc.) in local space, then moves (still in local space, so if car is teleported, so does camera) slowly towards its new desired offset. Same thing for the virtual point camera is aiming at.
Physics Performance
So after implementing transitions, adding their support in my endless road generation algorithm, implementing more interesting road profiles, and improving camera follow, I drove. For a while. 300km, synthwave blasting. And I couldn't help but notice that the physics tick update duration was getting dangerously close to 10ms.
It's actually pretty straightforward why: my road segments are 1km long with many triangles, and the binary tree I use to help find colliding triangles is pretty light: it only splits the road along its longitudinal subdivisions. This means that, after implementing more complex road profiles, too many triangles are placed in any single leaf of the BSP tree and therefore too many complex collision tests are performed for every slice of the road the car is above of.
Fixing this is as simple as extending the tree to add dividing planes along the road's cross section (well.. implementing this is no easy feat) :
If you are colorblind, too bad for you.
In the end, the performance was definitely improved (cost about halved), here is a video showing the new tree for transitions (the most complex case); it ends with an example of all the nodes the new tree contains for a section VS what it used to contain (only the red planes in the middle):
Demo
Here is a short recording of current state of things. I added the first royalty-free AI-generated synthwave music I could find to help build the atmosphere (yes, I did attempt to drive to the beat) :
The feeling of speed is not really present when not with the controller in hands. Maybe it would be time I add car engine sound and narrower FOV at higher speed, because of the most part I was driving at 400+km/h.
Work to come soon (notice I'm not saying "next week/update"):
- left junction render model
- junction collision model
- procedural chunk type (right now it's only straight line)
- scripting support
- intersection render and collision models (the 4-way kind)
And off course major systems still missing:
- Game mode
- UI & menu
- Sound & music