So, with the slowest parts of the UI being things like the car menu, why cant the game pause the physics whilst the UI is open like that. 2/3 of the screen is covered anyway. And the UI is CPU based, so the freed up CPU cycles would help massively.
Lots of problems, especially with parts selector, tuning menu etc. While some operations are faster, some are impossible with physics paused.
Mmmhm Of course if you pause after opening menu, you can kinda select options, but do select for example race transmission and then go to tuning page to adjust them gear ratios, it is not working cause tuning page is not getting updated for choices you make in parts menu while game being paused. Simply put, it does not really work if you would get game paused when menus are open. Getting CPU with faster single core performance does help to this aspect as well as making sure you are not maxing out your CPU's single core performance so that there is some available for heavy UI, of course that is not a solution, but a workaround. They are working on UI though, let's just see what new stuff they come up with in regards of that.
The physics engine that ships with the game can run at least as slow as 1/1000. While pausing physics does break the parts menu, reducing the physics speed to 1/1000 does not break the parts menu. Unfortunately... the UI being slow has nothing to do with the physics. The UI is definitely slow, just not for that reason. That's at least true on my computer, I can't vouch for other people's.
Turning shadows off while menu is open would also give more UI speed, they kinda are powered by same motor and it is part of the weight off when climbing a hill.
That's interesting fufsgen. To me most of the annoying UI delays seem to come from reading files from disk, walking through tree structures, etc. A quick test didn't seem to show much difference for me, at least in my "pain areas", when I turned off shadows.
I have UI slowdown, where all my CPU cores are being used at around 70-80% (not avg cpu, rather i see all 4 cpu cores in task manager and see that none is being fully utilized). Completely baffles me, but only really happens on maps such as American Road and etc.
I haven't noticed loading delays, but then again I have Nvme ssd. Often, CPU is at limit when menus load slowly, so any means that free CPU resources will help, but I don't know if slower disk will introduce more delays, haven't tested that. I have heard some people saying Beam would be quite slow in regards of loading times if run on HDD. @Michaelflat Task manager is too slow for anything really, nature of CPU load in this is kinda really quick spikes, where as Task manager shows 80% you might get some 100% and some 60% which averages to 80% or so, but I think Task manager is bit random still. Anything like 80% can be very much at limit.
I have a SATA3 SSD (Samsung 840 Evo 1TB). It's definitely not as fast as an NVMe SSD but for most practical applications it should be close enough. I've recently played BeamNG from a secondary HDD (WD Green) on the same system. I did notice issues during gameplay (I assume it was paging sounds into memory), but I did not notice any significant effect on menus vs the SSD. From my perspective the issue w/ the menus is that they should cache a lot more stuff. For me the parts menu is probably the slowest thing, and I don't think that it is disk speed dependent. The parts menu should walk through a data structure that's already been loaded into memory. The parts menu is quite slow, taking around 2-4 seconds to load for a vehicle like the pickup.
That would indicate that it is not reading the disk that is causing the slowdown. Thing with disabling shadows is that if CPU is already working hard, like in WCUSA, it might be hitting 100% CPU single core load quite often and when asked bit more in terms of using menus, there will be longer delays. Normally when I'm able to make sure CPU's single core load is not maxed out, parts menu works like this, I'm not sure if there is speed difference to how it works on you: However at WCUSA I get significantly longer delays and disabling shadows helps with that as that poor CPU will have bit unused capacity. Number of mods then slows menus down as it takes more CPU cycles with more mods. With HWinfo it is quite easy to check if it is disk or CPU slowing things down, just set it logging and polling interval to 500ms or even 250ms to get some data, which can then be graphed in excel.
cmon dudes, this has been confirmed fact for ages the UI process has the same priority as the physics process the UI has a default slowness, to be sure, but it increases drastically as 100% cpu usage is approached it is easily remedied by going into task manager and changing the process priorities, as they use that simple standard method to control them the physics process, having a whole lot more to do than the UI process, is gonna bog it down at high levels sure, it means the physics will run more slowly if you have other high priority processes running, but in general, you won't
Most of the physics are running on other cores though, you can see that by pausing the physics, one that UI runs on has had very small to none decrease on previous versions, but in current version there is bit higher drop. Making GPU work 100% usually makes menus much faster then too, so that is also one way to deal with it, but it is possible only with slow GPU. With 8800GTS 512, menus were lighting fast. Also with iGPU they worked pretty fast, nothing like with 8800GTS though as with that game did run less than 10fps from 'some' reason, but still menus and choosing parts were hugely faster than with any other trick with other GPU options I have tested. So one possible thing would be limiting fps to while in menus, UI will run 20 at max anyways, so having temporary FPS limiter should help, as I tested 5fps limit, UI is perhaps bit faster, but it is still big delay when actually changing parts, not much effect on that (although parts list disappears immediately actual parts changing takes longer on background), however my menus are not usually very slow, just speed one can observe on video, but for those suffering more slowness, maybe that would help some, at least it would not add troubles pausing potentially would.
i don't know about gpu effects, never explored them, i'm cpu limited UI ain't great on average, add enough cars to match the number of cores, UI is bad, add 2-3x, UI is unusuable change process priority, UI becomes responsive 24/7, that's all i know, it's extremely simple, that's the problem most people complain are facing
My computer is mostly FPS limited, so menus work just fine, in their clunky slow manner Yeah, UI is not the greatest, their working on it though and that is one thing I'm looking forward to a lot, along with reducing CPU render if possible. On most maps around 35-50% GPU usage, around 50-60% single core usage at highest core, so neither is limiting and it is perfectly smooth 60fps without any stuttering etc.
Unfortunately many of the participants in this thread may be referring to separate issues! Certainly the UI does become unusable when I spawn 20+ vehicles on my 4-core CPU. The game may still be playable, but the UI is not usable and this should be fixed. Increasing the process priority for the UI does mitigate the issue but I feel that permanently adjusting the process priority of the UI process is a poor solution. This isn't a flagship issue for me, but I think that it should be addressed at some point. Personally I find the delay when opening the parts menu (as shown in fufsgen's video) unacceptable. The delays in opening the vehicle selector, config selector, the other vehicle config selector, etc are all unacceptable. Additionally the delay in opening the controls menu is unacceptable. These are all menu sections which obviously involve enumerating items in some way. There may be other issues that have not bothered me, such as those that fufsgen is referring to w/ the graphics process. EDIT: specifically I have two thoughts on these 'enumeration' delays: (1) they shouldn't happen while browsing the menu (2) if they ARE going to happen, they shouldn't happen more than once - caching should be employed to prevent subsequent problems w/ the same menu. For example, if I load the Pickup, access the parts menu and get the delay... and then close and re-open the parts menu I should not experience a delay the second time. Similarly things like enumerating lists of vehicle configs should happen for ALL vehicles in the background while I'm browsing vehicles... I shouldn't have a delay at every level/depth of a menu structure.
Yeah, it is like if all of jbeams would be processed each time you hit ctrl-w, maybe it is because when modding you can make change and game reflects it immediately, however there could be variable of dataHasChanged and only when it is 1 game would do all the processing of every jbeam and parameter. Even still, I think that processing could be optimized quite a bit, it is like if data would be processed with java. For anyone who has not done coding, java is not very good with parsing or any task where you need to process large amount of data quickly, each cycle of parser takes quite bit of time, especially non optimized. Even C# can be quite slow. QT despite being C++ based, is slow in updating GUI, it does too many do nothing loops. Simplest C++ can be really really fast though, if each cycle takes 10ms longer and each cycle is run for every paramater, that starts to make a difference real quick as it all adds up so fast. As UI is html and javascript, is the parsing and processing then done with LUA, JS or C++ side of things? Haven't bothered to look, but yes, something in parsing and processing department is certainly lacking the speed which you would normally except from the games like these. Anything more than 0.5 seconds would be unbearable if comparing to other games. I do remember something about things already being cached on parts menu, but if so is the case, then how slow it would be without, or is it so that opening itself is not cached yet? Anyway they probably already have much better working internal versions of the menus, so whatever current system is doing, is perhaps irrelevant, if new menus are based completely different system, we can't know until we are seeing of course
