Nothing about Lua would make it difficult to implement a physics engine in it compared to other languages.
Correct, but said implementation will be orders of magnitude slower than implementing at a lower level… meaning you cannot handle lots of objects, you can only handle a few, and only with a few players if this is all networked… otherwise you get massive physics calculation innacuracy, terrible performance spikes, crashes, and if networked, server hangs/stalls, huge desync, etc.
The hardest part would be integrating with Morrowind’s systems. If the engine doesn’t expose e.g. collision geometry to scripts in an efficient way, then you’ll run into some real challenges.
I mean… that is true, that having to emulate collision meshes/hulls would be less efficient than just actually having direct access to them… but that would be the case with any language, and Lua is still much slower at any real time collision mesh/hull emulation than doing the same in a lower level language.
Even without LuaJIT, there’s no reason to expect performance so bad you can’t implement realtime rigid body physics. Interpreted Lua is fast, but even if it wasn’t, a 60 fps performance target for physics is not tough to achieve at all.
You say that, but I’ve never seen it done well in a way that can scale for many tens or hundreds or thousands of 3D physics calls in a complex single player scenario, or a multiplayer scenario where you now also have to account for networked synchronization.
Not saying its impossible, just saying it… I’ve never seen anyone pull off an efficient and accurate 3D physics engine in Lua, untill now with this LuaJIT implementation.
If you can show me a high performance 3d physics engine written entirely in just straight up Lua, well please do show me, and share with the class.
My guess would be that it would be constrained to either specific physics scenarios, as in, wouldn’t have as full a realistic physics feature set… wouldn’t handle well a lot of simultaneous intersctions… but I’m open to being surprised.
…
Like uh, Godot’s Jolt physics are written in C++…
…and while this used to basically be an addon, that was better than Godot’s default physics engine…
…even Jolt isn’t nearly as efficient or accurate as say, Valve’s implementation of Havok in Source.
Godot has been catching up with Unity on this physics engine performance front, but Unity still has the performance edge by a bit, and neither are close to Source.
And these are all C++ physics implementations, to the best of my knowledge.
Correct, but said implementation will be orders of magnitude slower than implementing at a lower level…
“order of magnitude” typically means 10x. A reasonable Lua implementation of rigidbody physics isn’t going to be 10+ times slower than an equivalent C++ version. C++ provides a lot more tools for optimization than Lua, so you’re unlikely to find a truly apples-to-apples comparison showing the difference between a Lua and C++ that isn’t a benchmark of the particular algorithms in the implementations.
To be clear, I’m not saying Lua is faster or as fast as C++, just that you’re making it sound as if Lua is too slow for something like this. I know this isn’t a programming community, but we’re talking about programming languages, so I feel compelled to point stuff like this out.
meaning you cannot handle lots of objects, you can only handle a few, and only with a few players if this is all networked… otherwise you get massive physics calculation innacuracy, terrible performance spikes, crashes, and if networked, server hangs/stalls, huge desync, etc.
None of this is true.
… than just actually having direct access to them… but that would be the case with any language …
It is specifically a problem with embeddable languages like Lua because they’re limited by what is exposed to its VM and how. In the context of modding physics into Morrowind, it’s possible that not everything you’d need is cleanly exposed through Lua (which afaik is implemented with a third party plugin and not natively supported).
Not saying its impossible, just saying it… I’ve never seen anyone pull off an efficient and accurate 3D physics engine in Lua, untill now with this LuaJIT implementation.
At the risk of sounding like a dick, I think you’re bullshitting. I doubt you’ve ever seen any physics engine implemented in Lua before, much less benchmarked them or evaluated them for their “efficient” and “accurate” qualities (which are meaningless terms). Lua physics engines certainly exist, but they’re mostly gimmicks interesting to developers to study/learn as there aren’t many real world use cases for something like that. There are few reasons to choose that over a C++ physics library, not because Lua is slow, but simply because C++ is faster, and the libraries are typically much more mature and feature-rich.
A reasonable Lua implementation of rigidbody physics isn’t going to be 10+ times slower than an equivalent C++ version…
So, here’s where you make me go find some actual benchmarks, because you obviously have no clue what you are talking about, and have likely never written any serious code in your life.
Take a look at the nbody benchmark scores. nbody is a simulation of Newtonian physics for a 3d point cloud of n number of objects.
When n is 500,000, standard Lua takes about 1145 ms, LuaJIT takes about 75ms, C++ takes about 20ms. to 35ms.
So thats in your two orders of magnitude ballpark range.
When n is 5,000,000, standard Lua just crashes, C++ evaluates it in about 160ms to about 315ms, LuaJIT takes about 715 ms.
So thats uh… infinitely worse? Standard Lua can’t even do it.
…
Or take a look at the spectral-norm benchmarks, which show how performant a language is at manipulating matrices and vectors… the kind of calculation core to a 3d physics simulation.
Base Lua can’t even complete any of the inidcated benchmarks at all. Times out, crashes, for each given n benchmark.
LuaJIT ends up being about one order of magnitude slower than various C++ compilers.
So these show you Lua doesn’t scale well and crashes, because Lua is far less efficient with memory usage than C++ (or C, through LuaJIT)… when it comes to trying to perform the kind of calculations that would need to be performed in a 3d physics engine.
…
To be clear, I’m not saying Lua is faster or as fast as C++, just that you’re making it sound as if Lua is too slow for something like this.
I am saying that standard, non LuaJIT Lua is indeed too slow for this, because that is true.
meaning you cannot handle lots of objects, you can only handle a few, and only with a few players if this is all networked… otherwise you get massive physics calculation innacuracy, terrible performance spikes, crashes, and if networked, server hangs/stalls, huge desync, etc.
None of this is true.
All of that is infact true.
I know this, because I have tried it, I’ve done it.
Lua is too slow, and all of those things I mentioned are indeed what happen if you try to implement 3d physics entirely within it, instead of using a game’s actual, native, almost always C++ physics engine.
…
… than just actually having direct access to them… but that would be the case with any language …
It is specifically a problem with embeddable languages like Lua because they’re limited by what is exposed to its VM and how. In the context of modding physics into Morrowind, it’s possible that not everything you’d need is cleanly exposed through Lua (which afaik is implemented with a third party plugin and not natively supported).
You don’t seem to get what I am saying.
If it is the case that your scripting language, whatever scripting language there exists a plugin for, for whatever game… if that scripting language doesn’t have an API method of referencing or manipulating an actual collision mesh or hull… then that doesn’t have anything to do with that particular language itself, it means the API is insufficient, the method of communicating between the game’s core library and the added in language is insufficient.
What I am saying is, is that this isn’t specifically a problem with whatever language you are writing your modifications in.
It is a problem with the API, the injection and interaction system/method/layer.
Thus, the problem you are pointing out as specific to Lua in this instance… isn’t even a problem with Lua per se. It would be a problem with any language that is using that particular interaction method.
…
You could compile a .dll that overrides or injects into or otherwise manipulates or interacts with the core game code itself, and then also possibly provide a custom .exe that uses the custom .dlls and the base game .dlls and other files.
This is what many ENB Shader mods do (complex lighting is a different kind of physics calculation), its what Skyrim Script Extender, New Vegas Script Extender do.
Those kinds of mods represent basically a better, more thorough or more powerful API, roughly, as compared to your theoretical example… because they directly manipulate the core game code, have access to more of the core game’s function libraries.
NVSE can do things like manipulate the world’s gravity, manipulate friction values between different classes of physics objects, manipulate how ragdoll tensor and flexor limits operate, etc.
It can and does directly manipulate the core game physics code.
…
Also I am… fairly confident that embeddeding a scripting language into a game that doesn’t normally support said scripting language… I don’t see how or why a VM would be involved in that at any point… unless you’re talking about the entire modded game being run in a VM?
I don’t know why you would need an entire virtual machine, a virtualized entire operating system… to add Lua into a game. That makes no sense.
…
At the risk of sounding like a dick, I think you’re bullshitting. I doubt you’ve ever seen any physics engine implemented in Lua before…
Nope, I am not bullshitting.
I have never seen or even heard or a 3d, rigid body physics system that is performant enough to run in a 3d game, that just runs in standard Lua, that doesn’t pass it to C as LuaJIT does.
There are many games that have their physics engine done in another language… usually C++… which expose an API that parses Lua, such that custom scripts or mods can be written for that game… but that doesn’t mean the physics engine of the game itself is somehow now written in Lua, it just means you are using Lua to instantiate and perhaps provide basic initial position, rotation and velocity vectors to an ingame object… and then the physics calculations are handled by C++.
I asked you to provide an example of an actual 3d physics engine running in Lua, because I am calling bullshit on you.
I have never heard of one, I don’t know of one that exists, yet you just confidently claim ‘oh actually this is totally possible and would be comparably performant!’
You… seem to admit you are bullshitting with these statements:
Lua physics engines certainly exist, but they’re mostly gimmicks interesting to developers to study/learn as there aren’t many real world use cases for something like that.
Yes, 3d Lua physics examples do exist, but as you say, they are mostly gimmick, proof of concept things, where someone mocks up a 3d physics engine in Lua, and would then presumably later learn how to port that code over into a more performant language like C or C++ or Rust… so that they could actually be used in a releasable game… because Lua is too slow to be useful as a core language for a physics engine, unless its translated into a faster language and then compiled, as is done with LuaJIT.
There are few reasons to choose that over a C++ physics library, not because Lua is slow, but simply because C++ is faster, and the libraries are typically much more mature and feature-rich.
You do not seem to realize that that literally is the more technically worded version of the exact point I am making: Lua is slow, no one has figured out how to code a ‘more mature and feature-rich’ 3d physics implementation that is comparable to C++ physics implementations, which actually runs in Lua, and doesn’t pass it over to C and run the actual code in C, as LuaJIT does.
…
In summation, you yourself claim that a performant and fast Lua physics engine could exist, and when I ask you to provide an example, you stammer and waffle about with claims about theoretical ones that could exist, and then in the end of your post you admit that the only Lua physics engines/simulations you know of are basically little toy ones that are not efficient or fast enough to be used in a game.
… But thats after you say that I am bullshitting by saying the thing you just said at the end there.
Do you even realize you are contradicting yourself and being a hypocrite?
You remind me of the edgelord script kiddies I used to run into on Facepunch all the time.
All talk, no walk, and the talk is all nonsense.
Please either actually learn how to code, or go back to reddit with your baseless bullshitting.
Correct, but said implementation will be orders of magnitude slower than implementing at a lower level… meaning you cannot handle lots of objects, you can only handle a few, and only with a few players if this is all networked… otherwise you get massive physics calculation innacuracy, terrible performance spikes, crashes, and if networked, server hangs/stalls, huge desync, etc.
I mean… that is true, that having to emulate collision meshes/hulls would be less efficient than just actually having direct access to them… but that would be the case with any language, and Lua is still much slower at any real time collision mesh/hull emulation than doing the same in a lower level language.
You say that, but I’ve never seen it done well in a way that can scale for many tens or hundreds or thousands of 3D physics calls in a complex single player scenario, or a multiplayer scenario where you now also have to account for networked synchronization.
Not saying its impossible, just saying it… I’ve never seen anyone pull off an efficient and accurate 3D physics engine in Lua, untill now with this LuaJIT implementation.
If you can show me a high performance 3d physics engine written entirely in just straight up Lua, well please do show me, and share with the class.
My guess would be that it would be constrained to either specific physics scenarios, as in, wouldn’t have as full a realistic physics feature set… wouldn’t handle well a lot of simultaneous intersctions… but I’m open to being surprised.
…
Like uh, Godot’s Jolt physics are written in C++…
…and while this used to basically be an addon, that was better than Godot’s default physics engine…
…even Jolt isn’t nearly as efficient or accurate as say, Valve’s implementation of Havok in Source.
Godot has been catching up with Unity on this physics engine performance front, but Unity still has the performance edge by a bit, and neither are close to Source.
And these are all C++ physics implementations, to the best of my knowledge.
“order of magnitude” typically means 10x. A reasonable Lua implementation of rigidbody physics isn’t going to be 10+ times slower than an equivalent C++ version. C++ provides a lot more tools for optimization than Lua, so you’re unlikely to find a truly apples-to-apples comparison showing the difference between a Lua and C++ that isn’t a benchmark of the particular algorithms in the implementations.
To be clear, I’m not saying Lua is faster or as fast as C++, just that you’re making it sound as if Lua is too slow for something like this. I know this isn’t a programming community, but we’re talking about programming languages, so I feel compelled to point stuff like this out.
None of this is true.
It is specifically a problem with embeddable languages like Lua because they’re limited by what is exposed to its VM and how. In the context of modding physics into Morrowind, it’s possible that not everything you’d need is cleanly exposed through Lua (which afaik is implemented with a third party plugin and not natively supported).
At the risk of sounding like a dick, I think you’re bullshitting. I doubt you’ve ever seen any physics engine implemented in Lua before, much less benchmarked them or evaluated them for their “efficient” and “accurate” qualities (which are meaningless terms). Lua physics engines certainly exist, but they’re mostly gimmicks interesting to developers to study/learn as there aren’t many real world use cases for something like that. There are few reasons to choose that over a C++ physics library, not because Lua is slow, but simply because C++ is faster, and the libraries are typically much more mature and feature-rich.
Correct!
So, here’s where you make me go find some actual benchmarks, because you obviously have no clue what you are talking about, and have likely never written any serious code in your life.
https://programming-language-benchmarks.vercel.app/lua-vs-cpp
Take a look at the nbody benchmark scores. nbody is a simulation of Newtonian physics for a 3d point cloud of n number of objects.
When n is 500,000, standard Lua takes about 1145 ms, LuaJIT takes about 75ms, C++ takes about 20ms. to 35ms.
So thats in your two orders of magnitude ballpark range.
When n is 5,000,000, standard Lua just crashes, C++ evaluates it in about 160ms to about 315ms, LuaJIT takes about 715 ms.
So thats uh… infinitely worse? Standard Lua can’t even do it.
…
Or take a look at the spectral-norm benchmarks, which show how performant a language is at manipulating matrices and vectors… the kind of calculation core to a 3d physics simulation.
Base Lua can’t even complete any of the inidcated benchmarks at all. Times out, crashes, for each given n benchmark.
LuaJIT ends up being about one order of magnitude slower than various C++ compilers.
So these show you Lua doesn’t scale well and crashes, because Lua is far less efficient with memory usage than C++ (or C, through LuaJIT)… when it comes to trying to perform the kind of calculations that would need to be performed in a 3d physics engine.
…
I am saying that standard, non LuaJIT Lua is indeed too slow for this, because that is true.
All of that is infact true.
I know this, because I have tried it, I’ve done it.
Lua is too slow, and all of those things I mentioned are indeed what happen if you try to implement 3d physics entirely within it, instead of using a game’s actual, native, almost always C++ physics engine.
…
You don’t seem to get what I am saying.
If it is the case that your scripting language, whatever scripting language there exists a plugin for, for whatever game… if that scripting language doesn’t have an API method of referencing or manipulating an actual collision mesh or hull… then that doesn’t have anything to do with that particular language itself, it means the API is insufficient, the method of communicating between the game’s core library and the added in language is insufficient.
What I am saying is, is that this isn’t specifically a problem with whatever language you are writing your modifications in.
It is a problem with the API, the injection and interaction system/method/layer.
Thus, the problem you are pointing out as specific to Lua in this instance… isn’t even a problem with Lua per se. It would be a problem with any language that is using that particular interaction method.
…
You could compile a .dll that overrides or injects into or otherwise manipulates or interacts with the core game code itself, and then also possibly provide a custom .exe that uses the custom .dlls and the base game .dlls and other files.
This is what many ENB Shader mods do (complex lighting is a different kind of physics calculation), its what Skyrim Script Extender, New Vegas Script Extender do.
Those kinds of mods represent basically a better, more thorough or more powerful API, roughly, as compared to your theoretical example… because they directly manipulate the core game code, have access to more of the core game’s function libraries.
NVSE can do things like manipulate the world’s gravity, manipulate friction values between different classes of physics objects, manipulate how ragdoll tensor and flexor limits operate, etc.
It can and does directly manipulate the core game physics code.
…
Also I am… fairly confident that embeddeding a scripting language into a game that doesn’t normally support said scripting language… I don’t see how or why a VM would be involved in that at any point… unless you’re talking about the entire modded game being run in a VM?
I don’t know why you would need an entire virtual machine, a virtualized entire operating system… to add Lua into a game. That makes no sense.
…
Nope, I am not bullshitting.
I have never seen or even heard or a 3d, rigid body physics system that is performant enough to run in a 3d game, that just runs in standard Lua, that doesn’t pass it to C as LuaJIT does.
There are many games that have their physics engine done in another language… usually C++… which expose an API that parses Lua, such that custom scripts or mods can be written for that game… but that doesn’t mean the physics engine of the game itself is somehow now written in Lua, it just means you are using Lua to instantiate and perhaps provide basic initial position, rotation and velocity vectors to an ingame object… and then the physics calculations are handled by C++.
I asked you to provide an example of an actual 3d physics engine running in Lua, because I am calling bullshit on you.
I have never heard of one, I don’t know of one that exists, yet you just confidently claim ‘oh actually this is totally possible and would be comparably performant!’
You… seem to admit you are bullshitting with these statements:
Yes, 3d Lua physics examples do exist, but as you say, they are mostly gimmick, proof of concept things, where someone mocks up a 3d physics engine in Lua, and would then presumably later learn how to port that code over into a more performant language like C or C++ or Rust… so that they could actually be used in a releasable game… because Lua is too slow to be useful as a core language for a physics engine, unless its translated into a faster language and then compiled, as is done with LuaJIT.
You do not seem to realize that that literally is the more technically worded version of the exact point I am making: Lua is slow, no one has figured out how to code a ‘more mature and feature-rich’ 3d physics implementation that is comparable to C++ physics implementations, which actually runs in Lua, and doesn’t pass it over to C and run the actual code in C, as LuaJIT does.
…
In summation, you yourself claim that a performant and fast Lua physics engine could exist, and when I ask you to provide an example, you stammer and waffle about with claims about theoretical ones that could exist, and then in the end of your post you admit that the only Lua physics engines/simulations you know of are basically little toy ones that are not efficient or fast enough to be used in a game.
… But thats after you say that I am bullshitting by saying the thing you just said at the end there.
Do you even realize you are contradicting yourself and being a hypocrite?
You remind me of the edgelord script kiddies I used to run into on Facepunch all the time.
All talk, no walk, and the talk is all nonsense.
Please either actually learn how to code, or go back to reddit with your baseless bullshitting.