are the devs caring less about crash physics now?

Simply it's really hard to balance out. There's a bazillion kids out there that just wanted a modern supercar. But at the same time there's not as many who just want another 80s shitbox. Making an 80s box crash well is simply much easier due to it being square, and therefore easily to naturally triangulate in jbeam. A supercar on the other hand, with many curves and polys as a result of that is quite hard to get to deform properly without spiking or instabilities. So they devs are left with a choice: make cars that are easy to jbeam, or cars that attract more players.
I like both, but I agree with most of what you said.

Either way they're getting better at optimizing higher poly models, so who knows what the future holds.

 

Well... the spiking, as noted, seems to be down to an incompatibility with the node beam structure and the models itself.... BUT... but... I wonder if it might be worth taking a new look into the actual mechanics of the flexbody system.

I am no dev. I do not know how much the math has been reworked over the years for flexbodys, or if they are still running off the same basic idea/equations that was introduced into RoR over a decade ago. (Sometime like September or something of 2008?)

I wonder if it would be worth re-evaluating "how" the flex mesh transforms are calculated. At the moment it seems like it is a very sharp transformation around each individual node which can cause some real spiking issues especially if the mesh is on the far side of the angle change. Then it seems like spiking is a much more likely occurrence if the vertices don't quite line up with the nodes in the physics model... which honestly makes sense if you think about it.

Right now I "think" the way this is done is the game just sharply displaces the mesh around the nodes depending on their displacement. I wonder if it would be possible to make something more like a calculated "vector field" that would allow for a smooth transformation about the nodes rather than a more ridged one. Think of a smooth transform function rather than just drawing a line between points A and B. That might help smooth out the deformation and help with the spiking issue (might)

 

I think they may be stuck at a point like this. If they're gonna put so many hours into reworking the flexbody system, why not start over with a newer, better, more modern game engine in the first place?

 

Could they just copy the code not related to deformation/jbeam into a different physics engine? IDK
--- Post updated ---

And the models etc.?

 

its not just that simple you cant just copy paste code and expect everything to work together

 

Yea ik but couldn’t they copy as much as they can then fix what broke? Ig I sound dumber and dumber, so I’ll stop talking

 

IIRC, stoat muldoon mentioned (i think on a discord server) that it's still using the really old system where any given vertex will be bound to the single closest node, which often leads to one stray vertex drifiting off from the others around it.
If they could figure out something like proportionally placing them between the nearest 2 vertices, that would minimise the spiking a fair bit, and you could always go further or more complex than that.

 

One thing I haven't seen mentioned with the Scintilla is, it's a light vehicle.
Lighter vehicles are more prone to instability in the physics system, and therefore have to have a tradeoff of being less rigid, or having less nodes.
The scintilla has the latter, and that's one reason you see spikes on it.

 

light and stiff, which is even worse.

 

i wonder any dev accept this issues ?

 

Yes this seems like some good solutions In my book, why *Dumb* down the nice new models?
And about the dash spiking, I have added 8 nodes for the dashboards in my CrashHard dummy 2.0 mod, and make it not deform as easy, make it a bit more stiffer then connect all the dash nodes to the firewall, this way the whole dash move and twist with the firewall, and a lot less spiking.

 

Potentially... potentially. If it was incorporated like it was in RoR where the physics came first, and then the flexbody system was just kinda popped ontop afterword's you could probably switch it up and really not run into any issues.

That being said that is a really inefficient way to code... seeing as when Beam launched the whole flexbody system was well established in RoR for quite some time, I would imagine that they would have chosen to incorporate it much deeper into the "Beam" engine then it ever could have hoped to have been in RoR to make the code much more efficient.

That said... in "Theory" you could delete the flexbody system from Beam and the physics engine would still function as if nothing changed. Getting it to work is an entirely other issue, but you at least understand what I am getting at.

In some other post I described why the Beam team was holding back on developing some graphics features by comparing it to baking a pie. With a pie you start by making the crust, putting that in the pie plate, then making the filler and putting that in, and then making the upper crust and putting that in. Now since the flexbody system is literally one of the first features of the engine ever shown off it is probably fair to assume that it is as deep as that pie crust. If we decide we want to change the crust of that pie before we put it in the oven to something like a cookie crumb crust, then that either requires us to completely disassemble the pie back into its individual components only to swap the crust and hope to reassemble everything again... taking the risk that the pie filling with the new crust may not taste good anymore (incompatibility by changing core functionality of the code) or just straight up starting over from scratch like you mentioned so that all the components can be designed to work together right from the start...

So unfortunately you may be right... it may be too deep to be changed now anymore. Only a dev could really answer that question though.

Ok, so they are still running that. I wasn't sure if they changed it up for Beam.

I was just thinking that what if something like FFD could be implemented...

https://lgg.epfl.ch/publications/2006/botsch_2006_GMT_sg.pdf page 112 for the math.



Literally nothing would change in the JBeam AT ALL. The way its defined, what all it needs... nothing... everything would be defined exactly the same, its just the mesh deformation would function more like something you would see in blender. Us defining the deform groups of nodes would be us literally defining the latus structure for that mesh deformation. Only problem is this would probably be much more taxing on the CPU/GPU then the current method. That said I bet this would give much nicer deformations then the current solution.

 

I was just about to say, can't imagine the lag this would introduce.

 

Yeah... its hard to say by how much... Blender can run on a potato and do these transformations on fairly complex mesh's in literal real time, so maybe the math is more efficient then it looks... but Blender also isn't running an entire physics engine in the background, so who's to say.

 

Doubt they'd start over with a new engine after putting years of work into their current custom one. (It's basically custom at this point, the devs themselves say that)

 

im surprised how much this thread is actually being used, i thought there would be like 3 replies not 3 whole pages jesus

 

Well... I think we can all agree that unlike the fist post states, the devs definitely care. We know they care. The community knows they care. Doesn't mean though that their might be things that we notice that perhaps they did not. Doesn't hurt to point those out. Plus spitballing ideas is always a good thing too.

 

which is why i would change the name if i could lol, plus i would go into the first post in-depth to edit some stuff out but im just too lazy

 

I do feel as if in a rollover, cars really don’t deform and parts don’t break off many times like they should. It is a game, and it has its flaws, but it would be much better to see more deformation when rollovers occur.