Alright, cool! Thanks for the quick responses!
Also, sorry for the barrage of replies, but is there a way to invalidate a RigidBody without removing the GuiObject it affects? For example, say I had a frame which was affected by a RigidBody. Is there a way to stop it from being simulated like one without destroying the frame itself?
Thanks for all your help!
A hacky way of doing this would be to loop through the RigidBodies of the Engine and remove the one you want manually:
local id = "id of the rigidbody you want to remove"
for i, b in ipairs(Engine.bodies) do
if b:GetId() == id then
table.remove(Engine.bodies, i)
end
end
I am not exactly sure if this makes any errors pop up though!
No worries! I am thankful that you’re pointing out and suggesting some actually important features and design flaws that should’ve been kept in mind earlier. Thanks again! And I’ll be sure to add an easier way to do this in the next release. 
RigidBody:Destroy() now takes in an optional argument “keepFrame: boolean|nil”. If passed in as true, the RigidBody’s UIElement will not be destroyed. If passed as false or nil, the RigidBody’s UIElement will be destroyed along with it.The ability for Anchored RigidBodies to have different anchor points will be added soon. CanTouch property needs to be revised before being added since I wish to maintain less collision detection checks each frame!
Great! This adds a lot of great features. I appreciate your effort and response to feedback!
By the way, since the .Touched event no longer fires every frame, is there a way to detect when a touch ends (like Roblox’s BasePart .TouchEnded event)?
Not currently, will think about adding it. Thank you for the suggestions 
.TouchEnded event to RigidBodies. This event fires the moment two RigidBodies stop colliding with each other.SomeRigidBody.TouchEnded:Connect(function(otherID)
local OtherRigidBody = Engine:GetBodyById(otherID)
print("Touch ended")
end)
A quick demo for this:
Thank you so much!! I’ve never seen a resource creator that responds to feedback as much as you do. These events should make my game easier to make, so I appreciate your hard work!
I wish to hear your thoughts on a CanTouch property for RigidBodies that may be added in the future if a majority agrees. This feature is quite useful but has some drawbacks.
View the issue linked below for more information.
May I ask, how do we add plugins to that module?
If you’re creating a plugin for yourself/locally then follow whatever coding pattern you wish to use.
If you’re wanting to add a plugin to the original library, which is for something that would take a lot of effort to make from scratch, but is easier to do with the help of your plugin. Then, fork the github repository, create the new plugin file under src/Plugins and follow the given code structure:
return function (...)
-- plugin code
end
After you’ve completed coding the plugin module, go to src/Plugins/init.lua and add your plugin to the dictionary that is returned.
Something like:
Hexagon = require(script.Hexagon) -- src/Plugins/Hexagon.lua
After you’ve made the required changes, open a pull request in the main repository. It’ll be merged and added to the library. You can take a look at other plugin modules for reference as well.
That’s fantastic; what else are you working on?
At present I’ve been working on supporting methods like :Clone(), :SetSize(), :SetPosition(), :Rotate() etc for Custom RigidBodies. Looking into creating more types of constraints. And also some other fixes, improvements and features!
I’ll surely look it over when you’re finished. I’m looking forward to seeing what you come up with.
KeepInCanvas property not working for RigidBodies when using Engine:Create()
Engine:GetDebugInfo()
Engine:GetCurrentCanvas() - Deprecation Warning.Engine.Updated
Engine.Updated:Connect(function()
-- do something
end)
Dark theme is now the default theme for the site.
Added a new installation method to the Installation category.
Better content readability.
Improved and updated change log.
Listed out properties for constraint, point and RigidBody API.
Listed notes and warnings in the API
Changed code block tab spacing to 4.
Categorized types, functions, fetch methods, events and properties. Visible in the sidebar of pages under API.
Tutorials for almost every concept!
I am in love, despite not even testing it out yet, haha!
Just curious, and forgive me if it is already a thing, but do you plan to add shape initiation? So you can define 4 points, and have a shape drawn between them, not sure if it is possible but maybe even make it so that you can define anywhere from 3 to however much and it would auto-generate a shape.
Also, any plans for texturing, so we can easily add textures?
A recent update made this possible! Not only 3 or 4, but any amount of points at different positions can be specified to form RigidBodies!
You can turn ImageLabels, ImageButtons and even ViewportFrames to 2D Rigid Bodies to do this!
I’ve been working on some major optimizations in the library and hope to get it done soon! These would include optimizations to collision detection, updating and rendering points and constraints, querying of rigid bodies during collision detection, collision related events of the Engine and RigidBodies, object creation and more.
The reason these optimizations are necessary is because of how the collisions between rigid bodies are not “rigid” enough, or in simple words - the rigid bodies are not really “rigid”. They act more like soft bodies. And, the cause of this is because of the extremely low amount of iterations performed each for calculating and rendering physics. You may notice, rigid bodies start clipping into each other when their numbers are increased, since there is an exponential spike in the calculations that take place causing frame drops.
Why do more iterations matter? Currently, physics calculations and updates to physics objects are performed just once every RenderStepped. During low frame rates or even high frame rates, collisions tend to happen in between 2 rendered frames, commonly at low frame rates since the delta time is higher. This means, less collision checks and responses are performed and the physics objects are updated and rendered at low frequency causing them to clip into each other.
Doing the same task multiple times helps in this case. For example, performing the physics calculations and updating the physics objects 6 times each frame means that there are 6 iterations being made. This maintains the “rigidness” of these physics objects and keeps them stable even at low frame rates.
A comparison between just 1 iteration and multiple iterations of physics calculations. From a matter.js demo.
| 1 Iteration | Multiple Iterations |
|---|---|
| Rigid bodies clip into each other very often. | The rigid bodies don’t clip into each other very often. |
 |
 |
Hopefully these optimizations will help me add more iterations to the physics calculations to make the rigid bodies actually rigid. At present, this is not possible. More iterations equals more lag.
You can track the changes and progress here:
