That's really cool. When you get the code in shape for people to look at, I'd love to see it, just to learn about how it's working! So if I understand you right, you're essentially using OpenGL triangles to record the coverage and using OpenGL to calculate the collisions (overlap)? That's a very novel approach!
Seems to me that implement path calculation should be possible with some linear algebra (vector math). I was hoping to find some basic algorithm that could work it out, but I suspect it's more involved, as you are dealing with changes over time that are inter-related. I want to look into this more, but I seem to have too many unfinished projects that take my time and energy. I must be spectrum ADD or something. Nice to see you making so much progress!
I hear you about C# vs C++. Although actually C++ isn't as hard as people sometimes fear. I have to confess I do all my personal projects in Python these days (using PyQt for graphical user interface), which is the fastest language for development I've ever used. Though anytime you have to program a GUI, things get a bit more complicated.
In terms of detecting collisions, no i don't calculate a single thing. I asked a bit ago how how sections worked and one person joked well you have the picture, you can just see it. So it got me thinking. What i do is send the triangles to another opengl rendering window that is 400 pixels square that is in behind the main window. So 1 pixel is about 4 inches of section. I then draw a close up image of the area around the section or boom. There is a command in openGL that is gl.ReadPixel that can read a line of pixel data so i take a snapshot of a few lines at the boom up t0 what will be the "lookahead" point and then just look for a black pixel. Its black because triangles as placed make everything green where applied.
So i look for a zero color and turn on the boom if i see one. If all the lines come back as green, its already been applied so turn the section off. Collision is a nightmare because you can have little wedges of unapplied and to calculate those is very difficult.
In the main window the sections that are green are semitransparent. As you go over a second time the green's transparency keeps subtracting so it will look a little darker with every time a triangle gets drawn over the same spot. that way you get contrast of over applied and overlap.
The implement tracking is very complex as the tractor doesn't just make a turn, it can zig and zag and slide and..... Also, the boom will begin to back up at some point if turning too sharp. An implement will do exactly what the tractor does, except it will be delayed. It starts the corner late so if you chop up the path from the last 20 readings and average them, it takes time for the implement to see "the turn". As the tractor keeps turning the averages also start to pile up as changing so the implement now turns too but since its later, the arc is smaller. Tractor straightens out and now the averages start cleaning out so while the tractor goes straight a while the implement will continue to slowly straighten out. Using the fixes based on the section, you can easily "simulate" quite closely the implements turn without a single calculation.
Just like in writing a game, speed is of the essence. So the less calculations the better and if you can get to 90% of reality without any calcs at all its easier to code and is fast.