Less static world

I don't know really what is planned for future, but often I find world being bit too static

It probably is not ideal to make everything out from beams in performance wise, maybe some objects could have just possibly to move around, like invincible trash bins might have just very simple physics where they would be kicked over and tiny trees could fell down instead of destroying car like hitting 1000 year old red pine, not sure how that would be made possible without too much work so it would be feasible though.

Maybe fences that you could go trough breaking the fence in simple way, no need to have full beam deforming physics on those of course.

From this picture one might get idea, crashing to those racks is not tipping them over or making things fall from them, also you can't pick anything up from the shelves:


It might help to bring world bit more alive, not sure how much is possible already, but I'm not seeing very much of dynamic objects on maps, I guess other Torque3D games have such and maybe same methods could be implemented in BeamNG to have simple physics objects?

Now it comes to my mind that I could have a look from Torque3D documentation and try to make little boxes or something which taxes my skills to limit in Blender, so I could test what can be already done, but let this be food for thought or something

 

Problem beeing: If you do that your coputer will explode within micro seconds

 

Qurious mind always have to ask, why?

Is BeamNG built so that having objects using simpler physics can't share the space and time with BeamNG physics? What is ultimately limiting factor that cannot be go around and would it be so that some new feature by developers would be needed to be created for these poor simpler physic objects to share the wonderful world of BeamNG?

I'm thinking along lines of objects that don't have soft body physics, just simple ability to collide and move by physical laws, but without ability to deform.

Would it need simple collider to be created for vehicles too to work? I'm just curious about limits and what would be needed to pass those limits, as always.

 

Go into the game.
Load up the vehicle selector
Spawn as many random Objects (not cars) as you can. Like Signs and Cones or Barriers. You might see the problem for yourself after some time

 

But those are objects that are using beam physics, those are not using simple physics like games usually have for objects as such?

 

Ya know... I just had a really dumb thought... While loading up tons of physics objects would be rather inefficient if their physics can't be put to sleep, plus they would end up using a ton of cores on a computer... but what if... what if all the objects that needed to be in a world were all one vehicle or prop? (Hear me out here)

The current maps are already littered with objects so if you can run a particular map, then graphically you are already fine. However, now imagine that all of the determined interactable objects (not every building or anything that extreme, but a fair few) were all made out of nodes and beams, and they were all stored in the same JBeam. This would have the benefit of running all those props in only 1 core on your processor, and if the node beam count was kept low enough, then it wouldn't even be that detrimental to the performance. (in theory)

So let's imagine we have some objects, a sign perhaps, which would be made out of nodes and beams. 4 nodes for the sign, 3 for the post its on, and about 18 to 20 beams. That's not too intense. Ahh, but a map has tons of signs on it. Ok, lets use a rather excessive number of signs for a map that is typical in Beam. We will have 50 signs. That's 450 nodes and about 900 to 1000 beams. That sounds about the same as a normal BeamNG vehicle. Granted we just filled our map here with nothing but cool signs, so clearly there is a budget to be stuck to here, but, that being said, most computers are capable of handling at least 2 vehicles at one time with no lag. My Core2Duo MacBook Pro had no trouble with 2 D-Series at the same time and only started to show signs of slowing at 3 (and that was because of the graphics card in it, but the CPU wasn't far behind). My new computer on the other hand... well... that thing has Dual HexaCore Processors with Hyperthreading for a total of 24 Virtual cores. Graphically I can run about 8 to 10 vehicles without slowing down... and my processors are only at about 20% load.

I think it could be done, but there would definitely have to be an option to be able to turn it off for slower machines and just revert back to the original models without JBeams in them.

 

My experiment of spawning cones get to 40 cones without slowing down, then BeamNG decided to crash, so far have not had success in exploding computer, despite good amount of attempts.

More of why's:
Why physics object cannot be put to sleep? I would think that some radius around active/selected vehicle would be reasonable, there is no need to update objects that are on other side of the island, but maybe that is current limitation that might not be limitation in a future.

I think some clever and able person should experiment with this single jbeam idea that @atv_123 describes, certainly it does not have to be everything that is possible to interact with, but just few carefully placed items does already a lot in creating atmosphere, same with placing trees, you can fill island with millions of trees, or use texture walls in few carefully chosen place to cut needed amount of trees to more reasonable level.

Now think about cinder block wall item that is in game, there is quite many blocks of those 'bricks', it is single object, it works, so I think there is certainly potential in this @atv_123's idea, have dynamic items object jbeam and put all map's dynamic objects to that, those objects are never destroyed or anything else, so can't see why it would not work, but then again I know very little and there might be some hurdles in this approach, it will take weeks for me to learn how to do this, but I'm going to try it, I'm sure younger ones manage to test it before I can, though

 

Thanks from explanation, I can see fairly easily how it is also more feasible to focus those elements when other bits are more or less placed, so there are less likelihood to do it over again and again and...

Also I'm quite delighted to hear how this element has been thought already, I wish you get breakthrough with your research one day, it would be much bigger thing than just few flying cardboard boxes

 

What about slowing simulation speed on individual objects, like activating slow-motion per object? I'd imagine that the physics core is locked into one single simulation speed, and likely for good reason. But such a thing may serve as a viable alternative to sleeping, if there's any functional difference between the two.

 

Objects with dynamic behavior like signs that are otherwise just sitting there chilling out don't need to process if they can sleep. Radius to player should bring the model online, but not process until your vehicle or an AI vehicle is within distance and in the path of impact. It would have to be judged (weight in processing, complexity of coding reliably, absolute usability), whether it is worth it, to try judging which objects to bring to full process, reliably doing so, to bring this game up to true modern standards with the environment. Rarely is the environment of a car accident filled with static, non-moving objects. Everything has some sort of give to it, if you hit it with a hard enough force. Even a concrete and steel building can come down (and it has), if there is enough energy working against it.
This just is a conundrum. Processors have a lot of work to do already in Beamng.drive. However, this is offset with the fact that processors with up to 32-cores are on the horizon (mostly for servers), however, they will eventually filter-down to the home environment, along with more efficiency for the per-core processes (that's called IPC, Integer performance per-core).
So, you will have some spare cores on future chips, and even many of today's higher-shelf options, to devote a core, or three, to various world processes. One core could run the environment, deciding which things to process, e.g. what to bring online or take offline, whilst another core or two could process the impacts of objects, layering things in multiples on a single core just like when you add more cars than you have cores. While it's not too incredibly hard to determine how many cores you have, by querying the system a bit, you could also set the amount of cores to use in the user interface, say if the person is doing streaming, this also helps things quite a bit.
As a mapper, I'd much welcome the ability to put destructable objects in mass in an environment, you wouldn't really even need to remember these things (as it would be a memory hog, remember what is broken, smashed, etc), because when a user gets far enough away, it doesn't matter anyways. So there'd only be a mass amount of stuff to index at the beginning, this can be compiled when the map is saved, not when loaded, to incur only wait times for the mapper, and a bit on loading vs a whole bunch. I've been mapping for games since MS-DOS, 486's, and DOOM.
So, you only need to process what's NEAR the player. Clones of the player make this more complicated. Handle this at first in development just working with 'the player' or the one that has the camera attatched to it. It's not the much code to run, and if you're not looking at the vehicle or watching it, you won't be there to see the difference anyways. Eventually it could be supported on clones (but only selectable via the user interface via a warning about performance impact, as it would be exponentially harder to process on big maps, not near as bad due to radius overlap on small maps like ECA).
It's a game about CAR CRASHES, well what happens when car's crash and leave the road; property damage, that's what.
First where going to keep the coordinates of our massive amount of dynamic objects, per object, in memory. Storing coordinates of each object won't take THAT much memory footprint, and should be do-able within the game's minimum requirements, even on medium-sized maps like UTAH.
Now, our core #1 (where #0 is the car's physics), we're going to run a process to look for how far things will be from our car at all times. Even in a city, it shouldn't saturate that hard as long as you don't over-do things (which I do).
There should be a settable slider for watchful radius of this, in the UI. This way folks with lower IPC (above explained), don't have to process such a big radius which would count our folks with FX or APU AMD cpu's / intel core2's out for the count. This is how it's done in other games with dynamic objects and environment. After-all, if you can't see it, it doesn't need to be there. This is how draw distance works also, so look for the code in that part of the game engine for hints.
THE CODE IS THERE, use what you have, no sense doing what is already done again! We are not reinventing the wheel, we're just making it fit more cars, right?
Now, if these objects are nearby, they're at rest and relatively simple to process, they won't be affected by wind, etc, unless that's something you can consider, however that would make incredible challenge in coding, so lets skip wind affects.
Here comes that pesky player who can drive, he's about to crash into a fence, sign, bushes, etc. Things only process when they need to, so plowing out 3~5 meters of fence, and a few bushes, and flattening that doggie house, shouldn't even require nearly as much processing as that car deforming will require. When these objects are done processing, they will 'die', eventually fading away after whatever time, say, 30 seconds, unless they're still sliding down a hill, getting dragged or hit by the car, etc.
OK, so now the player has restored his vehicle, as he leaves, and the LOD's on the objects get triggered, or the radius of object distance nearby is reached (mentioned above), the object will leave process entirely and reset to sleep as if it had never been hit. So when the player comes back again, he or she can once again smash down that fence, hit the bushes, and crash through the dog house.
This is entirely able to be done. Use your rendering code, to help do distances, just on a much smaller scale. When they object comes to rest, it won't need as much processing, when the player leaves radius, it will be forgotten and return to it's untouched state.

This is a great tool for recreating car accidents, and simulating them. Surely, it's possible. These are simple objects, with a dozen beams or a few dozen. A sign in itself is very very simple. A picket or chain-link fence is also relatively simple, and would only need to be processed when the player is near it. This would surely settle one of the last remaining drawbacks of your simulator, and surely would add to the fun. The mobile home prop, couch, and other things are good examples of destructable objects, as is the cement block wall, though the last one of these is rather tough to process tons of them at once, it surely is fun playing with physics. After-all, physics sandboxes popularized by things like Garry's mod, etc, are quite fun. The future is upon us, and we wouldn't want to feel surpassed before we're out the door and done with this game, would we? It's just one more feature that could make your game engine viable to be licensed by other companies in the future when more powerful processors are the norm, if that's in perspective.

Edit: checkbox next to disable collision would be 'disable dynamic props' which would be useful for debugging while working on setting up this feature should things go astray, or not all testers have high-end machines.
--Just my 2¢

 

If you wrote this much, you deserve a like.

At this point, i'd rather have much more optimized things than adding another cause of lag.

 

Bricks rigs has fences that disappear after getting hit, falling down, and stopping movement. After you go out of a specific distance, they reset. This might be helpful, but idk. I haven't done much programming.

 

Yep and the buildings have simple deformation and collapsing.