Hello guys, I am building some experimental maps for myself at the moment, building a city map, when i notice the drawcalls are 6000-8000. Jungle Rock Island, meanwhile, only has drawcalls of 1000-2000 despite the immense detail of the foilage. If anyone can give me some tips, this would be welcome, as i would love to make a high-quality optimized map for the people of this community. Thanks And sorry if this is in the wrong thread, by the way
I think that @bob.blunderton is one that knows best what to optimize with your map. Reason that JRI has so small level of drawcalls is that there really is not that many materials/textures and trees are exact clones of each other, so they kinda are rendered on one go. Meshroad objects are really heavy for example.
Maybe you could ask modular road kit from Bob? That would be optimized set of pieces. Other way would be make sort pieces in Blender and copy lots of them.
Whatever you need, I likely have it already. Just let me know what you need, take some screenshots of what you're building (include car for scale when/where possible). I have over 800+ road and footpath objects not including any buildings etc. Most anything you need to build a city and they use WCA textures, so if you have those in already (specifically slabs_large texture, which is what the sidewalks use in WCA), and road_asphalt and the delineation texture (road_lines or something like that, you'll have to browse textures, it's got the yellow/white striping on it). Other road objects use my custom textures. They're all not 100% optimized but the ones that aren't will just merely require a drag&drop update when they do, with minimal to no updating inside the map editor required (except if textures change, but that can be done in notepad++ outside of the editor, changes would be noted). DRAW CALLS - derp - what? To keep draw calls low you first must understand them. Objects are made up of UV's. Each face has it's own UV, they're either connected or not, on the object. This is regardless the way the object 'appears' in the game. A face that's connected may look 100% alike a disconnected face, it doesn't make a difference with looks. When you stitch together UV's inside a modeling program, it allows the game engine to draw all connected faces in one shot provided they're the same texture. Each time the game engine goes to draw a set of faces for each object, that's a draw call. If all your faces use slabs_large for example, like my sidewalk pieces do, and the UV's are 'connected' it will render in one draw call. The game engine uses the CPU to process each draw call on each object one at a time, in super-rapid succession, thousands of times each frame. If it goes above 4000, the average gaming PC's frame rate will start to drop down close to 60fps, or lower, depending on just how good your CPU is. While not 100% accurate all the time, a 4ghz CPU can do roughly 4000 draw calls a frame, 60 times a second (more or less depending on what else is in the map, or if the CPU also has to process lots of cars too), and a vehicle can be 800 or more draw calls each (at full detail). So if you have a rectangular length of sidewalk, and they're made of UV's not connected, and it has 6 sides, it will be 6 draw calls. 1000 of these would be 6000 draw calls, if they're all connected UV's, it would be 1000 draw calls. Now, how much this effects the engine can sometimes be a grey area - as this is where things get more complex. In some game-engines like the Unity or Unreal engine, draw calls can be batched (in BeamNG to a limited extent too, but no promises, this is being worked on though). BATCHING... If you have a bunch of objects, rendering in the same LOD (see below), and it's the same object (like "sidewalk_long.dae" for example), game engines can sometimes batch the draw calls. This means instead of 1000 draw calls, it's going to hit all the same sidewalk pieces in at once, and the impact will be very minimal vs just a few objects. This game engine to my knowledge won't batch across different objects, though this may change in the future. So if you have multiple similar but differently-named pieces of road sections, and they share some UV's (regardless if they're connected or not), it's not going to batch. If it's the same DAE and displayed at the same level of detail (LOD), it should batch though if everything in the engine is done correctly. Different LOD's will require their own draw calls and rendering. So if you have LOD's in various phases, this can sometimes hurt performance, unless it drops lots of faces on a mid-range video card with a strong CPU, and doesn't need more draw calls than the piece does at full detail. LOD's... Levels of detail. This is the progression of an object getting simpler, reducing faces and hopefully draw-calls as it gets further away from the player. Use of low-res (512x512 or less) textures made into a mosaic (the piece being rendered has all it's UV's connected when and where possible, and the textures are all pulled from as few files as possible. Your roof, walls, sidewalk, windows, doors, all come from 1 or 2 textures), can actually help speed up the process of rendering. Mosaic Textures: This is like how they got the doors and windows in many of the in-game stock maps. This can reduce GPU's video memory usage and also speed up rendering / lower draw calls. If you play my Roane County map or you've donated to my Patreon, gaining access to my modular road/rail and city kit, you'll see many of my city's road object's LOD's are done with mosaics, to draw the sidewalk, roads, delineation, grass etc, all as one texture when it's far away. If this game engine can ever batch textures across different models, the speed-up will be immense. Hopefully the developers can figure out how to do that for LOD's at-least. So yes, entirely, there's ways to speed the game up. It's difficult to build a city map and have it run well on mid-range hardware. It's a big balancing act, too many draw calls will lag the game engine with high single-core rendering use pegging one CPU core at 100%. High amounts of polygons (less likely to hit this!), can cause high GPU usage and slow things down, but you're unlikely to saturate the GPU before the CPU in this game engine, it's 10~20x more likely you'll hit the draw call limits first. Keep things under 3000~4000 and you'll be fine. Hit CTRL+F twice in succession to see DRAW CALLS readout. Too many different textures and you'll be lagging even if there's only 2~3 million surfaces to render. This is an inherent limit in all DX11 and lower game-engines and is limited by the single-core max speeds of your CPU. Now that BeamNG spreads usage among all cores for vehicle physics, your CPU won't hit it's dual core or single core turbos as much. Newer CPU's like intel 8086K can process up to 5000 draw calls without going below 60fps, but a slower i7 2600k or even i7 6700 non-k processor will start to slow down past 3200~3500 draw calls due to lower IPC (for the 2600k) and lower ghz speeds for both processors (unless overclocked on K-series CPU). IPC is the performance-per-core at a given GHZ speed, because not all GHZ is equal across CPU's. For example, AMD FX CPU's had very low IPC, and awful FPU (beam physics uses this!) performance, but the new Ryzen is much better, though the clock speed is a touch lower than intel's. If you need more information let me know. If not I will try to get my sidewalk bits posted today on the forums somewhere. I have both sidewalks the size of a small stoop or porch, and sidewalks roughly 20 feet long (6~8 meters or something), and some sets of stairs. The stairs are made with slightly sloped collision so that they can be driven up, and the edges of the sidewalk collision are tapered a bit so it doesn't spaz the vehicle out if you slide sideways into it. It facilitates being able to drive directly up them like in GTA series games where stairs collision is ramps. Spread your city out or lower draw call distance if needed. Avoid using too many different types of objects for now, and make sure objects have connected UV's. Duplicate UV's within or of the same object SHOULD batch, how reliable that performs is not set in stone as this is pre-release, but it usually works. So if you have windows, doors, etc, make sure they are 100% duplicated faces. DO NOT USE SKETCHUP OBJECTS, THEY ARE RUBBISH AND PERFORM LIKE POO! Use Blender 2.9 alpha or above, or pay for a program to do this like Maya LT (if you're a masochist and into pain and self punishment, take it from me, I use this program and I hate it sometimes, but I am 100% inept at learning Blender). I never punched the tower and I've had it 4 years, until I used Maya, so do try to figure out Blender, it's easy to make objects. If you cannot do this, contact me. The modular road and sidewalk kit may or may not be right for you. Let me know what draw call situation you have at the moment, and maybe try spreading your city out a bit by placing some green space in the middle of it for parks, school fields, etc - like in Sim City when you have too much pollution. If the developers ever free us from the clutches of evil DX11 and go to DX12 or Vulkan, we'll be able to have multi-threaded rendering, but all you can do for now is wait and hope on that note, and beg/pester them about it. Maybe they'll do that sooner than later (or at all) if they get enough demand. Sure would take the immersive worlds to new heights, especially with the directions CPU's are headed. The only thing I can tell you, is even if you take draw calls down by deleting mesh roads, you might not help the situation much by adding in lots of city road bits. It's not going to magically make it faster if you have way too many different objects, even if you remove some objects to replace them with objects from my modular road kit. Reason being is because the road kit itself will require some draw calls and is usually to be placed first, not as an after-thought. Otherwise you really won't know how to build (your budget for remaining computing resources with which you can display the map). This is why the developers combined much of one object in WCA, to help cut down on repetitive draw calls, even though it's a bit much for mainstream CPU's and GPU's yet to render. That is all, let me know if you need me to write any more books on the topic. Thank Fufsgfen also for his work on researching draw calls over the past few months. --Cheers!
Also this post developer made today is important bit: https://www.beamng.com/threads/opti...fferences-has-lots-of-info.57689/#post-966666
