How Collision debug works?

So if I enable static collision debug, it shows me collision surfaces of static objects, like this:


However when I move around, sometimes I see simple collision sufrace of building, then as I move more, all the windows etc. appear.

Does all these detailed collisions run all the time? As I remember reading earlier that collisions are not possible to run slower or turn off which is why there are no trashcans that can fly, I would think all detailed collisions run all the time.

Way I understand this to work is that each collision triangle takes time from CPU, so if I would like to optimize CPU usage of my objects, going for less number of triangles would be way to reduce how taxing my objects are to CPU.

Another thing that puzzles my mind is why windows are so detailed in collision as for me it would appear as taking quite bit of resources for not much gains, unless breakable windows are planned?

It is kinda hard to crash those windows, but maybe it is more of time available thing, colmesh from visible mesh is faster to create than building full custom colmesh, or is it so that there is no real performance difference, game will swap to simpler colmesh?


Or is it so that what I see in static collision debug, is not actual collisions?

It is confusing in a way as if number of collision triangles is constant and if it would be possible to half them, hardware usage would drop quite a lot, but as such is not done, there must be good reason, would it be that it will not result performance gains?

So when I build my objects, making separate lower detailed collision mesh would not have gains or gains would be very limited?
--- Post updated ---
For example, this building looks like it has collision surfaces even on areas that are blocked by all directions, while outer layer is having detail that looks to be ok, collision debug shows collision surfaces inside the outer layer of collision triangles, I would think that building does not really have such inefficient collision setup of what debug tool shows?


This building appears so that there are collision triangles even on small vents, why anyone would put collision triangles on those, I would think it would be really wasteful, so somehow I think this debug tool is not showing real collision triangles or then there is something more to it?


However I then examined East Coast USA buildings and they look much more of how I would think collision should look, so that leads me to think that at WCUSA it shows real collision triangles.


Even so, ECA town still suffers from heavy CPU usage, so maybe those collisions are turned off after certain range and when I do objects it would be waste of time to make simplified colmeshes as it does not yield performance improvements?

 

You've got this backwards. Collision is not calculated starting from all these triangles thus more equaling more calculations.
The collision detection stems from the vehicles themselves, the only triangles involved in calculations/cpu cycles are the ones that the vehicle is calculated to actually hit.
More vehicles/nodes/beams equals more cpu time, not these excess collision triangles that are only ever used when necessary, when stuff is going to hit them.

Cars don't randomly change direction like some UFO needing to calculate from any and all collision triangles at all times. XD

 

So technically there should be hardly any difference of having vastly complex static collision meshes and it should only affect when getting near to their zone, so no any kind of background CPU usage would result from using very highly complex collision meshes? Of course only when hit is happening that might have effect, if going way overboard.

That would be good for those crazy level designs I have been thinking. However I still need to figure out more CPU optimizations, like so many others, I'm finding it quite challenging to manage CPU budget with any decent amount of constructions.

Then again that does sound kinda bad regarding to plans on my UFO
--- Post updated ---
Oh forgot also say thanks, now with your explanation it is easier to understand that tool also, it is kinda projecting collision direction and then lits surfaces on projected path or something roughly there

 

Yeah size and complexity does not effect performance nearly as much as density in the case of a game like this.
Part of the reason people get brief pauses with some hardware/game situations. All those collision calcs are happening to much/to fast for some pc's.

Biggest thing that will effect cpu budget will be the number of individual objects because of terrible directx draw call optimizations.
That is why west coast usa map is made of big chunks, problem with this however can be with LOD issues so it becomes a balancing act because more geometry means more cpu needed to push the polygons to the gpu.

Admittedly beamng's engine is not ideally set up for large or complex maps which makes things more difficult.
It could certainly do much better with some threaded graphics pipeline goodness, but that is not so easy to do.

You are welcome, and yes collision detection uses similar functions as other ray tracing type of stuff.
With cars this can be easier because they are much more predictable in their path, but beam adds much more complexity having to calc for each node/beam/collision triangle.

 

I did some testing and found out exactly that object number issue, it is really funny in a way, object complexity does not matter, there seems to be no direct relation to drawcalls displayed in ctrl-f thing, shadows affect it, but it is number of object and pretty much that.

Would think there is overhead per object on these calls or something like that?

Anyway here are some of my testing:
https://www.beamng.com/threads/deve...r-contributing-post.1575/page-931#post-912718

Can't say graphics engine would be bad, it is huge amount of polys it can do and with GPU power available, one can get to quite complex maps before number of objects becomes issue, but also one needs to consider trees etc. items in forest brush does cause also this higher CPU load, so getting creative with object bundling can still give some LODs while giving better CPU performance.

I still think that I will optimize my collision meshes too, as well as models, those WCUSA collisions are probably partly because it would be quite a task to build specific collision model for combined city objects, especially if there are possible changes still coming, it would be wasted effort.

It is always great when understanding grows and learning happens, knowing all these bits allows to plan projects much better!

 

Yes it is the directx level overhead on draw calls that is the bane of most games.

The main 2 reasons you are able to run so many poly's is for one, you have a stout cpu with a high end gpu in those tests.
The other big reason for this is Nvidia has very good multi threaded driver optimizations which allows directx 11 games to use the cpu way more efficiently for pushing the data to the gpu from the cpu. Which is why you see balanced cpu loads in those high poly situations.
Try this with an AMD card and you will notice a big difference with cpu load.

This is Nvidia's hard work on their directx 11 drivers, beamng's graphics engine is still some what old fashioned which is why things like shadows, reflections, ssao, etc. are very cpu heavy when this is not as much the case in a newer engine. Modern gpus, since at least unified shaders/compute shaders are set up to take a lot of the load off the cpu with effects like these but the graphics engine must be programmed to take advantage of it.

A gpu with its massive parallel processing power is much faster at dealing with lighting related effects than any cpu ever made. It is entirely what they were built for, doing movie level rendering in real time was always the goal. I know Nvidia always used to mention this very ideal.

 

My CPU gets pretty much same scores as 6700k in single core tests, I have seen worse Banana bench results from 6700k than my CPU, but still, it is 6th gen, 30% behind in single core performance of overclocked 8700k, not bad, but could be better, however BeamNG with it's old engine is indeed difficult for even overclocked 8700k, GPU help is needed as we indeed see with WCUSA, so much I have learned now about optimizations for this engine.

What I remember when playing with databases and such, was that overhead was real killer of performance and it was quite easy to get some tiny overhead in your code, which then practically killed the performance as going trough huge number of records.

Here we can optimize by reducing number of records, that is objects. Getting 20 objects worth of overhead vs 3000 makes huge difference, much bigger than in any normal situation can be observed, however if one can reduce amount of objects by 30% that is already big help, that means one can add more stuff on map and as we all know, more is better

I keep hearing these things about AMD cards, their drivers have issues so people need to go back to old ones, now I hear their driver is not on par with Nvidia for CPU load issues, it is a shame that they are having issues, I remember my last AMD car that had lot of issues, must be now more than 12 years ago, I think it was Ati then.

However R9 is about twice as fast as gtx1080 in 2D graphics, that is quite nice.

Thank you again, gaining more understanding about these helps a lot as now I know what to look for workflow. In practice placing objects in modeling software seems to be way to go as it is only practical way I see to get combined objects placed properly in relation to each other.

 

Ok, I put few objects in game, these are not combine objects, 1000 houses in cube each is one TSStatic object, thousands on background that are forest brush objects, more trees one cares to count for, Everything from JRI forest objects is on map, I was trying to introduce high single core CPU load which I see at many maps, even at official maps and it seems not to be possible to cause such high single core load, no matter how much stuff I put in, either editor crashes or I run out of GPU power before I get high single core load:
Brush size 150, density 10, click few times...

Then again I can't get drawcalls much past 2000, Automation track has over 3000 and WCUSA over 2000, however drawcalls don't correlate too well with how laggy map is from what I have seen, shadow drawcalls maybe little better, but neither that is explaining much.

TSStatic objects do have overhead, very clearly, but forest brush objects seem not to have much.

Making Amazonian Jungle should be perfectly possible as this many trees actually block some stuff from rendering, which helps lowering the load:


If more complex collisions are not responsible, then what it would be? Something in textures? For some maps for sure, but not for all. Maybe there can be something in meshes themselves which makes them hard to compute for GPU, some meshes just won't compute too well?


Certainly there is some things that trigger the issue which should be avoided like a plague, but where is a list of such?

 

I've tested many of the maps on my system and I am not getting any especially high load on a single thread besides the first time I tested East Coast.
But this thread was not significantly higher and it did not happen the second time I tested the same map nor on any other map.
None of the cpu threads go past 50-60% and they stay within 5-10% of each other.

There is an obvious issue with the way the game is rendering the vehicles however. It is quite bad.
With 1 d-series on screen I am getting say, 64 fps, but with 5 on screen it drops all the way down to 44 fps.
Without shadows and SSAO(reflections already were off) and it still drops 20+ fps.
And this is not even close to taxing my cpu or gpu with this level of geometry or number of vehicles.

Plus there are big issues with culling, or even a lack of it entirely as staring at a rock wall I get 86 fps, backing away a little from it I get 98 fps and moving the camera through the ground it jumps up to the limiter at 120 fps.

Torque3d makes me really sad with how terrible it is, but I am sure these things will improve once the devs get around to working on the graphics engine.

Another thing to note is the performance of very large mod maps that have terrible performance even when they are only terrain and have very few objects in them. Viewing a large part of said maps causes massive fps losses on most PCs.

Does not seem like static objects are the biggest issue for the engine as much as the maps terrain and the vehicles. Your test map seems to lack any sort of big or detailed terrain in it. Do you have any vehicles spawned in when testing?

 

Test map is 5x 2048 terrains, but I have tested with terrain from Bob's Southern California map, that is 4096 with 0.25m resolution unless I'm totally mixing things up here again, which is in that above screenshot actually. Hardly any difference over my 5x 2048 terrains and nothing like some mod maps that kill CPU totally with only few buildings. PNG textures do kill FPS quite heavily, those seem to cause CPU load from some reason and another thing is sketchup objects as those are like if all triangles would be separate elements/objects.
That kinda makes me think, maybe it is something in textures, uv mapping, etc that causes shadow calculation to go berserk which causes high CPU load, but so far I have not been able to introduce similar CPU load many mod maps are causing and number of objects seems to be completely irrelevant as long as those are not TSStatic objects, which seems to be heavy for CPU.

I'm not using much of complex textures though, however still TSStatic objects do cause considerable CPU load compared to forest objects of same kind and same quantity.
I don't have specular mapping at all, can't tell if it would be that causing CPU load, but then again I wonder why it would be so.

Vehicles are heavy on CPU from physics alone, but I have at least one on that map above post, under all those trees, poor thing was buried there, not much of CPU load from that though

At ECA I can get 57fps at certain settings and location / car, if I remove water plane and put it back in with default settings, but same height as original was, I get 65fps.
However CPU load drop huge amount, because I limit FPS to 60 with vsync and when FPS is limited by something else than CPU, CPU load drops really fast.

Of course those percentages on screen are not telling much as they jump around and are updated only 1000ms intervals, HWinfo was nice as it could log 250ms intervals to nvme drive, but update changed that and can't get better than 1000ms writing interval now. Taskmanager is next to useless seeing that.


With faster single core speed, something like overclocked i7 K series or 8th gen K series there is probably less of single core limits, depends form the GPU, with 1080 though GPU limits don't happen very easily @ 1080p.

If I compare JRI and ECA, JRI is putting out lots more polygons per drawcall, ECA is on that spot some 3400 drawcalls, JRI hardly ever goes above 2000 from what I have seen, Automation map goes to some 3300 and runs much better than ECA town, it has ton more polys too.

At ECA, it is water plane that causes high single thread load, with car and dynamic reflections on, I struggle to keep 60fps, here even with empty map and FPS limited to 60 one thread is already over 60%:


On WCUSA, it is kinda hard to pinpoint other reason than amount of collision surfaces for high CPU load usage.

JRI then, I can get over 220fps on JRI with one D15 on screen (like you I turned shadows, reflection and ssao off), it drops quite a bit with 5 of them on the screen as single thread is at 100%, even with one single thread is at 100% but it bounces on it less often, when I unpause physics of the 5 vehicles it appears as if none of cores would be at 100%, but GPU is not at 100% which means it is still that one core hitting 100%, but it is very rapid nature of spiking CPU load, which makes it appear as if it would not be 100%, I have my own tools to verify that:


However if I put vsync on, I can see much more balanced situation as there is now time for CPU to process information between frames, problem is that with shadows on at ECA or WCUSA computing power limit of that one core is met before 60fps which shows as high one core load:


There are some physics, UI and some graphics (shadows make considerable effect on that thread load) on that same thread, I'm guessing collisions of map are physics, but we can not of course know that.

While WCUSA is heavy on GPU, it is also heavy on CPU, compared to JRI.

I have tested these things with 1050Ti too, it is same story really, except on some maps it is easier to have GPU at max with 60fps, with 1080 it is not that easy.

Dynamic reflections does cause quite bit of CPU load, so of course turning those off, turning shadows off and I can run any map at 60fps with 5 cars in there.

Some maps however are real trouble to run at 60fps and reason why is not so simple to point out, but only thing where drawcall overhead might be reason are TSStatic objects, with 1000 of my houses as TSStatic object at test map, my CPU is really struggling, I put 1000 houses as forest items on same situation and there is no trouble at all.

ECA has much simpler collision than WCUSA, but those rocks at river area are having quite huge number of collision triangles, it would be easy to blame them, however if those can't be blamed, then it is kinda hard to find out what it is.

I don't really believe in terrain issue, you can delete terrain from map and see how much it affects, it is next to nothing really, it is something among objects most often, or water settings, or both. Just very difficult to pinpoint what it is in objects, ECA town is so small compared to polycount and number of objects I have been putting on map that it should have no effect really.

Also it is not any single thing, it is just piling up of many little things, not sure if some techniques of texturing and modeling are part of the reason or if only way to avoid the issue is to have objects go 2D billboards at distance as that seems to be working just fine, I should be able to make easily 1000 house city which should run at least 80fps according to test results, except there might be some bit in textures or someplace else which makes that completely impossible, which I don't know about yet.

Until I figure out what is causing this, I'm having quite hard time to start planning any bigger map project as it will be only at near the end when issue starts emerging and there is just no way I will cope with such, so I need to figure out reasons why some of the maps are so heavy on single CPU thread that CPU limits FPS to near 60 or even below if using dynamic reflections as dynamic reflections cause big CPU load increase on that same thread.

So far on my test map CPU load has been mostly being shared with all cores, unlike some official maps and mod maps, so I guess I just need to make really complex collision meshes to test that part out

 

Thanks, that explains some things, reasons of reality, visual mesh is used, that is very understandable as things are quite alive still and no point wasting time for things that might change etc

Way I see collision meshes is that too large are bad, too small are bad, way it is at ECA looks for me something that is what I should aim for, it is probably at more stable state.


Then again, I do like to think less is more, even though this engine can easily handle 12.5 million polys in right conditions, there is this something that makes things tricky at times, devilishly difficult to pinpoint that something though

Only way to find out is to build until it lags

It is like this, I have known strains on CPU, then uncertain and unknown, this unknown seems not to really be too much on some maps, on other maps it is huge, so while I think I know main aspects of level design in regards of performance, there is this unknown that can become quite big with unknown reasons.


East coast and west coast are pretty close same FPS at slowest points, while JRI is twice the FPS until CPU budget is full.

Challenge is that polycount, drawcalls, number of objects, all seem to have poor connection to this, but to maximize amount of vehicle to be run on level, which each tap on same graphical side of CPU budget, I need to figure out things to avoid.

Then again, I'm wondering that maybe those few maps perform so much better because of caching or something similar, JRI has huge number of objects, but they are all green / copies of only few different. Fog increases performance by causing null rendering with objects same color as fog is on some engines. Sorting different objects, lods etc. might be slower if copies of same object need only one of such processing.

So I have to build a test that has as much different objects of similar complexity as level I want to create, which kinda then would be perhaps quite pointless

Even knowing that shadows and dynamic reflections have high CPU footprint is not really helping, as that something can be completely unrelated to those and gains in performance are only because disabling shadows and dynamic reflections just makes more room for the unknown.

Lovely difficult to pinpoint in some cases, at some cases it is relatively easy to pinpoint.