PREAMBLE OK I've tried ALL the methods we've discovered so far, and only one in fact works so far. My findings seem to be consistent with what has been discussed above. The only process that seems to working at this point in time (most of the info we have so far is outdated, going back to 2011 no longer working, or is not appropriate, as in the case of the photogrammetry example ) is the Render Doc / Chrome / Blender 2.80 / Maps Importer plugin method. Here is my initial exploration into this wrt to Kyalami. PART 1 Q: What are the elevation data options for hobbyists in recreating a race track environment, when we dont have access to Lidar? A: Generally speaking, at this point in time, as far as I can tell, we only have Google Data. There are two issues with this: 1. Accuracy of the data 2. Accessing the data in useful way. https://developers.google.com/maps/documentation/elevation/intro Here is a paper on the INVESTIGATION OF THE ACCURACY OF GOOGLE EARTH ELEVATION DATA https://www.degruyter.com/downloadpdf/j/arsa.2016.51.issue-3/arsa-2016-0008/arsa-2016-0008.pdf Their conclusion: More info on assessing the geometric accuracy of UAV-based orthophotos if you're interested: https://www.ajol.info/index.php/sajg/article/view/162487 So, bottom line, the technology isn't as accurate as what we would want. In fact, its not nearly as close as we would want, if we were to emulate a race track with pinpoint accuracy, like we can with Lidar for example. Conclusion: :-/ PART 2 Digging into Google Earth elevation data. RACE TRACK BUILDER: When I accidentally came across a video tutorial on Race Track Builder some months ago, it sparked excitement: because on the surface - this was an easy way to access elevation data, compile it into a usable format for testing, and create the foundation for building a mod track onto. It does that all very well actually. But it frustratingly falls just a touch short on a few aspects, that causes it to be a deal breaker for many. (Close but no cigar?) Im sure these elements could easily be adapted and implemented into RTB by the author if he wanted to, but thats another discussion. One of the issues regarding RTB that relates to this topic is the subdivision level that we are able to go down to. Its not small enough, and as a result, interpolates the Google data further, smoothing it out, but losing too much detail for true accuracy. When we look at the raw wireframe data from Google, its fair to say that the super clean mesh that RTB spits out based off the G data is impressive nonetheless. Just wish we had 1 or 2 more levels of subdivision. GOOGLE EARTH ELEVATION TOOLS: One thing that struck me when I first started playing around with RTB wrt to creating the terrain mesh for Kyalami was that IT DIDNT TAKE MAN MADE CIVIL ENGINEERING CHANGES to the terrain into account. Now at first I just brushed this off thinking the data was collected prior to the earth moving. But this is not possible. Google Earth was launched on 11 June 2001 and Google Maps was launched on 8 February 2005. The second iteration of the Kyalami Race Track was built in the early 1990's. CASE STUDY I'll use the final corner to demonstrate this: Note the man made elevation of the Turn below. This was constructed in 1991. This is the "out the box" terrain mesh created by RTB: Kinda looks like the original lie of the land right ? Lets look at Google Earth: Look at the elevation graph along the bottom. At the mid point (red arrow on yellow measuring line) in my measurement - its at 1464 meters above sea level. At this point, it DROPS to 1460 meters. That would make sense if it was measuring the natural lie of the land, not the elevated Turn 13. So the visual on Google Earth has the track elevated, but the data doesn't seem to correlate? OPEN TO INTERPRETATION This is where we start treading on thin ice. Without actual data to back things up, starting to eyeball things. Looking from different angles. Test driving etc. We start degrading accuracy. In the image above I had to eyeball the height and elevation characteristics of Turn 13. PART 3 Extracting meshes from Google Earth, importing into a standard 3D Application, and rebuilding a track scene off the mesh as a template. The process as described in the Youtube Video by Élie Michel, Published on Apr 2, 2019, seems, at least at this point in time like it could be an option. His tutorial fails to mention a couple of key details, which Ill outline a little later. Here are the results of my tests. Lots of cleanup, but a fairly detailed mesh to build over. The next steps Im going to be exploring is how to automate as much of the "Cleanup" and re-creation of a road mesh, referencing the Google mesh as possible.
You must do presentations for a living, So, if im following your thoughts correctly, you will attempt to use the Google photogrammetry and rebuild on it? It is a royal pain to take so many steps back in a project, BUT, considering you have most if not all of your track side objects, trees and all, they can be re-used saving you a ton of time, perhaps needing a little re-scale to match the scan. IMO, even though it is not lidar, it should be accurate enough to keep the opinionated folks quiet... And peace of mind that you used the very best reference available without spending a ton of money . Im happy my googling and info digging might be of use after all! Side note.... Building on a reference mesh, usually we use splines (or curves in blender language). We trace these lines along the edges of the road, walls, etc, then shrink to the scanned mesh to capture its Z properties.
Do you know this drone mapping project? https://www.mapsmadeeasy.com/ It sounds promising but at least you have to have a drone and permission for taking these areal pictures.
Ha ha yeah I do a lot of presentations . Its part of being in the tech startup world. I do spell checks and typos and grammar checks for those though ! Yup, thats what I was thinking, capture the race track in pieces, group each capture together to make up a full 3D track template. Then building a new track mesh referencing this "template mesh", as well as the immediate detailed terrain areas, and then merging the existing RTB mesh in for the outlying horizon areas. F#gk, when I actually type that out it makes me feel tired. Yup. Thats one of the redeeming factors to this. Yeah. Its easier to defend your position when you can back it up with someones elses' data ! And pass the buck. :-D For sure man, you started something pretty interesting here. If we can streamline a process and develop a usable pipeline, this could come in handy for a lot of folks, and help produce better outcomes. The spreading of knowledge is critical, in all walks of life. RIGHT! Yes that makes sense. Thanks for that. .... Blender .... I cant even navigate the camera around a pivot on the screen. I looked up tutorials on how to do this, and eventually just gave up in frustration. This is a real (stupid) barrier, not using CONVENTIONAL ways of just being able to move around stuff. Any help in pointing me in the right direction, would be great. Sigh. Another app to learn. :-/ Maybe Ive just got the thing set to a weird setup or something. Wow, thats pretty amazing! I mean, you just send them the pics, they do the grunt work and you get an OBJ back. Definitely worth looking into. Thanks for sharing. --------------------------------------- The main philosophical issue at hand right now for me, is - this is a hobby. This is meant to be fun. As soon as its not fun any more, then why would I put the time and effort into it? The part of me that drives me to try and do things as well as I can doesn't always serve me well. Sacrifices get made - time with friends and family, making money, other projects that might be more meaningful long term. etc So what are the motivations in continuing this project? Is it worth going back so many steps? If I didnt rework this, would I ever be happy with it? Probably not. Dead end? Need to figure that out.
Right-click to select object of interest. press "." on the Num pad to zoom on that. Press mid-mouse button and pivot away . Indeed it is. However, for a full sized track, some costs will be involved. I did some rough calculations and the "free" points are not enough for a full track. Doing it in chunks might be an option maybe - but it comes with the obvious short-comings. Felt this way a few times along the way. Took a break, but after some time, I felt the need to go back. It's just something I like doing. Of course this places stuff on a never-ending schedule, but at least the pleasure is not lost . If money would be involved, that would be another story (to which I cannot add anything ).
For my first track (Borgloh) I only had elevation data from Google and it took me a long time to remodel all the smaller hills and ditches from photos and video footage again and again. And luckily I could visit this place often cause I live near to it. For Goodwood I could use Lidar from an open lidar data base. Very nice but not so easy to work with it as it seams. For my next track I'm sure to use this method.
Thanks @luchian - cool now I can pivot, I guess Ill get used to it. Next lesson - how to pan ;-) This is actually pretty damn amazing. So much 1:1 direct reference to work from. From exactly how the ground has been worked, with the all the roadwork etc around the track. Being able to replicate exactly the foliage and tree silhouettes. The exact height and size of buildings and so on.
my local town just got lidarified I notice. blackpool England. the animated shader would work well on this I bet. .....think las vegas of the north west of England but way shittier
MORE TESTS: Wanted to see if there was some kind of LOD wrt to the data thats dumped onto the GPU. Thinking was, if whatever is on screen at one time, if allowed to load to 100%, there might be the slight chance that we could capture an entire track in one go, and then not have to stitch pieces of higher res captures together. Sadly! this is not the case ! This is the mesh resolution that I feel is good enough to work from: Heres the entire track captured in one go: (adjusted levels in PS to make it easier to read)
Thanks for answering this question I had in mind, too. Is it difficult to stitch the pieces together?
CAPTURES DONE! Well you dont need to stitch them together, you just have to position them. Most captures came in at the same Z position, which made things easier. Took quite a few captures (and time) to build up the whole track. And as you can see its fairly big memory wise!
Wow, fantastic job you did here @Prototype ! We are away now, but when I get home, I need to sort this somehow also in a separate thread. It's an extremely useful method (..as long as ggl will not change stuff again). Thank you for your tests.
Sure @luchian , LMK if I can help in any way. Couple of issues I ran into which are not documented, which are worth noting: Latest version of RenderDoc is 1.4, (which does NOT work) - ONLY RenderDoc 1.1 and 1.2 work. Current version Chrome DOES work. BUT ,make sure Chrome is accessing the GPU, and not the on-board graphics.
SCALE The captures came into Blender at around +- 20x too small. Ive re-sized the mesh, but not easy to get 100% accurate results due to not being able to take identical measurements off Google Earth and in Blender. Mostly to do with the fact that the image resolution isn't crisp enough. Took around 10 measurements around the track in various places. QUESTION: Probably accurate enough ? Google Earth: 18.15 metres Blender: 18.17 Google Earth: 10.29 metres Blender: 10.32 Google Earth: 14.62 metres Blender: 14.69 Google Earth: 11.75 metres Blender: 11.83
Definitely good enough. I've had a CAD plan for Motorpark, and there are still errors here and there in the range of centimeters. Also, people with real-life experience on track might have the impression that the dimensions are not right, but most often than not it is a case of FOV error/perception. In my case I've checked with drone photos and my digital version was in fact a tad larger (some pilots were reporting "too narrow"). - on Tapatalk
But it does beg the question, how do we know that our tracks are the correct scale in the Editor? How do we double check that? How do I know that the car I'm driving is 1:1 real world scale and the track is also 1:1, so that the car and track are synced 100%
When dealing with 3ds Max or blender, their units and how they are setup can be tricky. When you import a mesh, usually they’ll get converted to the default measurement, say 1 unit = 1 meter. But if it wasn’t exported that way from renderdoc or wherever, blender will still use that default and the track might guy look super small. Not a big deal, but when you export again to fbx, you have to make sure the export options reflect the right measurement. In my case of using the metric system, I can export in centimeters or meters. If you export with the wrong one, you’ll be able to tell right away in kseditor that the scale is wrong. I don’t thing renderdoc would fudge the scale of the captured objects... it’s definitely using something accurate, just have to make sure what that is and make sure Blender is changed to use that or convert correctly
