I'm not exactly sure what causes performance issues with mesh roads, but after certain amount of them, CPU can't handle all the computing anymore, which causes performance to drop very steeply. It does happen on any maps that uses mesh roads to large extent, but it is probably more of combination of things. Turning shadows off makes those map run perfectly well in most cases as that relieves some computing resources. Certainly it is not the polycount that is the issue, but something to do with number of object/collisions, that together with number of objects casting shadows is the reason single core limits are faced. It is interesting phenomena which so easily evades all attempts of pinpointing what it exactly is, maybe it is just combination of several factors, but I know everything will look to be fine, until few more pieces are added, then all of sudden, there is FPS drops. Reason Torsion is warning about this (or at least why I'm writing this) is that putting lot of time to craft mesh roads and finding out this harsh reality with them near the completion is kinda devastating. My suggestion is to make rough mesh road that runs above current road for testing purposes and pay close attention to CPU load, if all looks good, then it might actually work and that would save lot of time and pain.
There is a reason I wrote 'road mesh' rather than 'mesh road'. If I understand correctly, you were talking about the mesh roads that we can create with the in-game editor. What I meant is a solid 3D mesh that has the shape of the road : Since Ewanc has the LIDAR data for the whole mountain, I think It should be possible to extract just the part of the mountain in-between the forest walls and then import it as a static object. The rest of the mountain scenery that's only visible from the top most cleared out part (top part which will be on the terrain object) could also be a different static object with really low poly-count, the same way as how the backdrops from the official maps are made.
Ah yes, mixed up them two, it gets confusing easily Making road mesh in Blender etc. certainly is different animal all together, engine can put huge number of those on screen without much effort at all. Lidar route or this route should work, at least that is my guess with my very limited understanding: https://www.beamng.com/threads/tutorial-adding-heightmap-roads-with-blender-v2.39903/
This game can handle triangles amazingly, which is why I had picked a mesh as the solution. I have the proof that it will work, so that's not an issue. The only down-side to the mesh road is that modeling it would take 10-20+ hours. Edit: the LIDAR mesh is more bumpy than the current terrain due to "noise", so I would need to actually 3D model it using my race track modeling techniques. OTOH, if I split the terrain into 2 parts, it would alleviate the bumps. You could even load both terrains at the same time, giving the illusion that the whole thing being there, but only the first one loaded in the items.level.json will be collide-able. This would be the ideal choice if Torque supported terrain stitching and both were functional. There's are pros and cons to all the solutions. This is the stuff that keeps me up at night with cold sweats, lol.
How about have upper part as a modeled mesh road, splitting it two, but instead of need to have two terrains, you would have one terrain and one mesh, joining them would be delicate task, but bending mesh under, having them overlapping a bit might help there. That would perhaps save some of time working on it and you would have bad points of both worlds, or good, who knows how it would end That method LJF Hutch shows, could save time of modeling the road as with node setup in Blender it should be possible to get road made quite quickly, if that just works in this case.
Making the bottom half terrain and the top half mesh would be possible, but if you fly out to the outer scenery mesh you'll see that the multitexturing has an ugly transition, even if they are smoothly lined up. Maybe a hybrid of 2 ideas; 2 terrains, the bottom collidable and the top one fall through, then a mesh "hitbox" to solidify it. It could be made from the LIDAR mesh, with a road mesh on top. This would reduce the modeling time and eliminate the need to redo forest, decals, ect. Downside would be; the mesh might not match up perfect with the visual terrain and cause immersion loss. A mesh will certainly have a different feel than terrain leading to the same problem. I use 3DSMax, so Blender is alien to me. Those tools look impressive though. If it generates banking, it could be useful. --- Post updated --- On second thought, making the bottom half hybrid, would allow for better optimised geometry and more consistency for the upper section. This is all hypothetical of course, and I still need to do more testing as well as sit down and try Torsion's POC and see how it "folds".
Frankly, none of these ideas are very productive. I'm including my own in that statement. The game has serious limitations. Some of these limitations are likely to change in the future. Putting lots of work into working around a problem which the devs then fix 6-12 months later is guaranteed to lead to discontent/resentment - so it's best not to put yourself into that situation! AFAIK the Blender technique requires a fair amount of learning and then a good bit of work... in order to carve new roads into a blank heightmap/mesh! In this case the interest is in in reproducing existing roads and effectively projecting them onto an existing heightmap/mesh which has existing carveouts for them. I think that for the devs this isn't a 1-way workflow either: they jump back and forth between Blender and WM, bringing the Blender-generated surfaces back into WM. @RyvyLo - I disagree! This mod uses a 1.2m square size. Frankly 1ft resolution aerial LIDAR is never good enough to make an accurate track surface, but even if it was... baking that down to 1.2m resolution destroys what you started with. Have you looked at your suspension movement while driving over a surface with such a low resolution? I took about 5min and recorded some (very poor ) footage to try and illustrate my point. Unfortunately I'm weaving all over the road for most of this 18s video, but there are a few stable moments where you can easily identify the suspension travel. The video has 3 clips. Some of that suspension movement is pretty large. IMO any virtual track where you've got that much suspension movement on a smooth surface will NEVER yield competitive times vs the real thing. At that point it's much better (IMO) to smooth things out and tolerate a fantasy turn. If replacing one short straight with a sweeping turn slows you down more than driving over huge washboards for 15min then you're doing it wrong. Bottom line? I think that implementing all the track surfaces as static meshes (but not "mesh roads") could produce an enjoyable result. None of these solutions are significantly more accurate than a 3-meter resolution GIS grab... (I have some beef with everyone who applies the "LIDAR" label to their BeamNG mod. It means something different when you grab a noisy 1ft resolution file from some GIS provider vs when someone uses a laser scanner to generate a sub-1in resolution point cloud of an area. [1] ) With meshes for roads at least it could be fun though! From my perspective there are two reasons for considering a heightmap instead of a mesh: Tire grabbing. The devs have made impressive progress on this issue, but it's still a thing. Technical or design mistakes on a mesh can make the problem much worse. Workflow / labor. The Blender workflow is likely to be less effective for this than for new fantasy roads. It's also a foreign workflow to Ewanc, who's already familiar with working on terrains. [1] For the record, this is what iRacing means when they say LIDAR. Back in 2010 they appear to have been using a Leica HDS3000 which has a spot size of 6mm at 50m. EDIT: Ewanc, obviously none of the above is meant to take away from your hard work. You've done good work so far and I would not have bothered posting in the first place if I didn't think it was worthwhile material.
Please keep the ideas flowing, its all greatly appreciated and why I released the map as it is. I agree about aerial LIDAR not being of much value to race sims. Its only really use is for making high res maps. I've always had to build over crummy GPS tracks and topo map spines, so it is a step above that, but certainly not comparable to ground base sensing. My idea is that at 1 meter resolution, and Beam terrain 1m too, it's a rough equivalent and light years ahead of the alternative.
Disclaimer: I've never made a map, don't know much about blender and I'm not sure if I understood all what was written here. So yeah, I feel qualified to talk about this . Either way. Is it maybe possible to make a map with higher accuracy, make the top half of the track on that using decal roads and make a mesh road/road mesh noodle with lower half of the track over the map edge? And add 5-10 meter sides with forest. Kinda like in old games where you had just the road and sides with stuff. Of course this would ruin the part with doing the side roads and buildings find deeper into the forest, but there are sacrifices. Unless you made more mesh road/road mesh to accommodate those small roads. You could then use low poly to fill the space beyond road+forest noodle. (Sorry if that was said before and I didn't get it)
Some perhaps interesting footage (real one is sporty car, you need to compensate for camera shake in your brain and try to look how wheel moves up and down in relation to door bottom, that is perfectly smooth racetrack, not a road): Maybe should drive with ETK800 for more proper comparison, but of course road needs smoothing, however I want to point out nothing is perfectly smooth IRL, car gets light because unevenness on race track and especially at road, that makes braking interesting, especially with street cars, where you have to manage all weight transfer, bumps, racing line etc. I'm sure Ewanc can craft improvements, finding time can be problem but eventually anything can be improved, I'm sure. I did test with Sunburst hillclimb and that car just does not work on this surface, it is odd how SBR4 hillclimb is so much better, but Sunburst was not good at all, it is kind of sawtooth noise pattern that is trouble, which probably comes from limitations of terrain. Too smooth is bad, wrong kinds of bumps or roughness is also bad, but when pushing limits there are always some challenges to be found, very satisfactory when solution is found, that is why we love challenges Update: Added ETK800 clip too, just for entertainment
Exactly, thats what I was getting at a few posts up. As Torsion pointed out, there will be some potential complications with any sharp edges in the mesh causing tire popping.
I think that if you use road edges like RyvyLo's image shows, some 30-45 degree large edges, which could hide under terrain mesh etc. that would decrease chances of tire popping a lot.
Yep, my test mesh is just like Ryvylo's above image, with a 1 meter deep 45 degree barried face at the road edge. It had no effect on driving other than making the road edge visible, and had a nice bump when you got a tire off the pavement and got back on. No problems with it causing flats or spinning the car out. I'm away form my compute for the day, so I can't show you guys anything.
Nice ! I had the same idea and made a quick and dirty proof of concept on my side to see if it was possible : Seems like that will be the best alternative ! It might even be possible to model small bumps in the mesh For the curious, here's a map that uses the same system : https://www.beamng.com/threads/corkscrew-mountain.7120/ (warning : map is quite old and was packaged the old way, so in order to make it work you need to extract the content of the level folder in the .zip in your personal level folder)
Corkscrew mountain is known to perform poorly isn’t it? Does it use a mesh or a mesh road? Hopefully breaking the road up into multiple meshes with LoDs would get performance to be decent. Decal roads do work just fine on top of meshes. I know that this isn’t what’s being discussed at the moment, but just as an FYI: As I recall, you may only have one material per sub-mesh. This restricts your ability to apply different groundmodels if you try to convert an entire terrain to a mesh. Effectively the road surface must be it’s own sub mesh no matter what. EDIT: It's been a while, so I didn't remember. A quick look at the linked thread shows that it's a mesh. I added strikethrough to my earlier question to avoid any unnecessary confusion.
The scheme I've planned would split the mesh into 1 mile pieces for performance sake. The the mesh levels I've unpacked have all been meshdumps that give no thought to frame rates and everything is grouped into the same object. I also planed on modeling additional details while at it. The lattice I'm employing allows me to throw loads of detail in at little expense as long as it follows the shape of the road, like curbs or walls. Thats how a modelled rumble strips into all my levels. This area has many 6 inch curbs and rock walls close to the road that would be tedious to model otherwise. The uneven guardrails can be straightened out almost effortlessly. The LIDAR mesh would be nearly all dirt, accept for the occasional parking area or offshoot road, and it'll be invisible so materials will be easy to manage.
I did some testing on Corkscrew, according to numbers what I got, it runs better than Utah, both in CPU and GPU load was lower than what I get in Utah with same settings and vehicle. Then again it is relatively simple and small map, but on max details (dynamic reflections were on lower side) GPU load was mostly 35% and CPU load under 50% on thread that was running highest. Also this Pikes Peak runs better than Utah. Utah then again runs better than ECUSA or WCUSA. Runs better = less computing power needed, as all maps tend to run solid 60fps, except WCUSA as it gets 100% CPU load for highest running core quite often. Not sure if it is any value, but I was bored
I'd say it's good news, because now some more computing heavy stuff can be done without big performance issues. So many possibilities.
Those mesh roads you can build in level editor (F11) are still performance killers, it is different with 3d editor made mesh objects, very easy to confuse those two. That is 30fps with i7-6700 and gtx1080, it is gorgeous map with really nice road layout, but no computer will run it on high details because of mesh roads causing too high CPU usage, that is roads you get from the editor. Here is link to map https://www.beamng.com/resources/glass-view-mountains-autumn-map.1865/ I have been fancying of making personal version with decal roads of that, but somehow never get around of starting that. It would be interesting to see how much differently it would run. Also reason why I get goosebumps each time we hear mesh and roads in same sentence. Roads made in Blender or 3ds max should be somewhere between decal roads and those mesh roads from editor as they do add some collision sufraces that increases CPU usage. However idea of making road from several pieces, probably makes load bit less, at least on graphical side of things. Sorry, this is bit off-topic, but thought it might clear things a bit and maybe is useful for someone who stumbles upon this thread.
Those meshroads for Glass View could be edited in notepad and made paper thin(0.01m), then the terrain could be aligned to mesh up and down to conform to the meshroad. That's how I originally smoothed the rough LIDAR road surfaces of Pikes Peak. Depending on how thick they are, they may just need to be raised or lowered a slight amount all at once. Then the meshroads could be deleted and replaced with lightweight decalroads, or make a script to convert the meshroads to decalroads... I've been working on the loading bug the last day or so and its been driving me nuts. I finally got the summit spawn point to load. It turns out the spawn points had a bunch of old flags that were freezing the game. Of course, now its not working at all and none of the spawns will load, lol. I have a backup from just before, so it should be easy to redo the repair, without raving to run too many 5 minute test loads.
