You don't even know what kind of engine BeamNG uses and still claim to know better than developer that it is as easy to make mirrors happen as in other games. Don't you think that around there somewhere you should realize you have absolutely no idea if it is easy or not for this game? Mirrors are pretty much same as back when developer's reply was written, he explains in post how mirrors work, there is nothing complicated in this. When you learn how mirrors work in this game and how in this game rendering additional cameras is currently really expensive as even current single camera view is doing quite bit more rendering than many other game engines, then you start to understand why it is not same with this game. With time, hopefully they will get graphics engine to do less work than it is doing now so that more cameras can be added, but there is no fanboyism in this, just simply fact that you need to learn more about how engine works, which I think even you realize.
So it is their own engine, as I suspected. Again how mirrors currently work and how they're limited is not a very useful discussion, except as far as knowing what's CURRENTLY possible, but since it's their own engine, mirrors can definitely be improved, and that's all I wanted to confirm. You made it sound like since camera mirrors aren't currently feasible then just accept it and shut up about it. I know you didn't say that explicitly, but that's the vibe you were sending.
Developers know mirrors suck, what more can you achieve? Surely if they find way to improve them that is feasible, they will do it.
Do they? Even if they do know, suggestions like these are helpful to let the devs know what the community wants, and where their priorities should be. If no one mentions the mirrors for years, devs might think it's a low priority.
Priority certainly has a part of it, they have mentioned that in a future Vulkan will be the rendering engine, right now it is experimental and it is logical to think that mirror work happens when Vulkan rendering engine is more mature as then this game is no longer using modified Torque3D rendering, afaik. Another problem with this game that needs to be mentioned in regards of mirrors are missing LODs from vehicles. In ATS/ETS2 vehicles have LODs, in BeamNG vehicles have just the highest LOD. Generally in other games, lower LOD meshes are used in mirrors with more aggressive reduction to lower LOD level. This is not actual numbers, just shows one reason why BeamNG is so heavy for hardware. Without LODs, you get like 30 000 polygons x 6 vehicles, that is 180 000 polygons (real numbers probably lot higher) With LODs, you get perhaps 15 000 Polygons for car that is close to mirror, then reduces to 5000 when further from the mirror, so you might get something like 50 000 instead of 180 000. Reason why this game does not have LODs is how physics engine is used to modify visible mesh, if you have less polygons in mesh via LODs, there is less vertices and damage probably will be off, also knocked off damaged parts needs to look correct and physics are what drives visuals. In a way developers have chosen path that makes it much more difficult to implement simple things, they try to avoid making simple fake solutions, which then leads to why it is more difficult in this game, it can be though being a design principle, I guess. In ATS/ETS2 you can also drive 2000km without horribly shaking, but in Beam and many other games, when you move further away from 0,0,0, there is shaking, I would like that to vanish, like I would like to have mirrors like in some other games, but I guess not all will happen and even mirrors take probably years still. At frequency as mirrors issue comes up, they certainly are not forgetting about it though, also they have this .tech branch I read there is some driving school simulator like elements in it, but in there you need to have proper mirrors for simulator, I would guess at least, so maybe that bumps up priority too!
Would rendering in vulkan affect low end hardware? Coz right now vulkan doesn't even launch on my amd hd7610m (very old), probably because it doesn't support it. On the topic of shaking further from 0,0,0, hasn't an assetto corsa modder managed to figure out a way to reduce the shaking? I remember watching a youtube video where the guy mentions it.
Vulkan should at least in theory help weak CPUs to keep monster GPUs fed, for low end machines it might help CPU too, but if you are limited by your GPU already, then it probably does not do much for now at least. Thing is that with that new rendering engine developers might be able to create some new optimizations that might help low end systems more in a future, ways that has not been available with T3D based rendering engine, however that is speculation and not guaranteed to happen of course. I think that reduction of shaking has been based on idea of making 0,0,0 be in such position that it results shortest distances all over the map, instead of 0,0,0 being at corner or some other spot, but to be honest, I don't know if they have figured some more clever solution for that issue. I put Targaflorio on gridmap, that is over 70km long loop and I think that in AC I get more shaking than in BeamNG, but I put center of roadloop to 0,0,0 Anyway 35km x 35km is pretty much maximum amount of shaking I can cope with, using semi or bus might be horrible experience on that size of map already and want is to have 2000km drives without repeating same roads, just another want that is bit too much for realistic possibilities I guess.
Go play on the Gridmap Pure & keep on driving in one direction for like 50 kilometers. The shaking at that point should be obvious
I did this once, took a car and drove for around 100-110kms and oh damn did it get shaky. I did run out of fuel too.
So what causes that, and do devs know about it? I usually don't play very large maps, but I have seen some mild shaking or vibration on some maps. That large American Roads mod map that I no longer have had some shaking I think.
I guess it can be said to be floating point rounding inaccuracy. Float numbers are quick to compute, Decimal numbers could have better precision, but are slower to compute. There might be even more to it that that, but my understanding is that this is what generally is thought to be reason among most of the games experiencing the issue. https://softwareengineering.stackex...63/what-causes-floating-point-rounding-errors In this game position of hundreds of nodes is calculated 2000 times in a second, then visual mesh is calculated based on those nodes, so I would think that in BeamNG we can get bit more of the rounding issues limiting our map sizes than what happens in other games. What I'm not sure is if position of physics node location is averaged or sampled once each frame for the purpose of positioning visual mesh. Visual meshes appearance is rendered once in a frame though and while averaging physical node's position would perhaps do something to shaking, it probably would also do something to CPU load. For me about 35km x 35km is largest area (that is 17.5km from 0,0,0 when positioned center to origin) that I can place in game so that shaking is somewhat tolerable, but with T-series it still is pretty bad. MAB GTX truck mod shakes at Italy map quite badly if I don't remember wrong, so node stability plays part of it too I guess. Setting physically correct FOV is working really well to minimize seeing of shaking as shaky interior is not much on screen then, well unless I play with triple screen mode that is.
I doubt it's a floating point precision issue, but it could be variable overflow when the position coordinates get too large for the holding type. Devs should have a better idea, since we users can't go through their code.
