Nature2D - 2D Physics Engine for UI Elements

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)

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. :grin:

v0.5.3 - Improvements to .Touched Event.

  • Improvements to .Touched Event. The event does not fire every frame anymore if two bodies are colliding. It’ll only fire the moment the two bodies collide. Playing collision sounds etc is now possible.
  • 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.
  • Changes to Signal utility. Curtsy of @LucasMZ_RBX
    • Made Connection property .Connected public

Updated Roblox Asset & Github

Updated Documentation

Updated Wally Package - 0.5.2 → 0.5.3

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 :slight_smile:


v0.5.4 - TouchEnded Event

  • Added .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")
  • Fixed AnchorPoint bug with anchored RigidBodies. Anchored RigidBodies can now have any AnchorPoint, which does not affect how they are positioned on the screen. cc: @Inconcludable

Updated Roblox Asset & Github

Updated Documentation

Updated Wally Package - 0.5.3 → 0.5.4


A quick demo for this:


1 Like

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!

1 Like

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

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.

1 Like

v0.5.5 - A new look for Spring Constraints

  • Fixed bug where setting Visible to true when creating a custom constraint won’t render the constraint on screen.
  • Spring Constraints now use a Coil ImageLabel instead of a straight line when rendered for better visual distinction between springs, ropes and rods.


Updated Roblox Asset & Github

Updated Documentation

Updated Wally Package - 0.5.4 → 0.5.5


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.

1 Like

v0.5.6 - Engine:GetDebugInfo(), Engine.Updated and bug fixes

  • Bug Fixes
    • Rope constraints were completely broken and was unaware about it until I tested them yesterday. They have been fixed. Turns out there was a mistake in the force calculation.
    • Fixed KeepInCanvas property not working for RigidBodies when using Engine:Create()
  • Added Engine:GetDebugInfo()
  • Removed Engine:GetCurrentCanvas() - Deprecation Warning.
  • Added new event Engine.Updated
    • Engine.Updated fires each frame. It fires the moment all physics objects have been updated and rendered on screen.
        -- do something
  • Updated documentation and tutorials subsequently.

Updated Roblox Asset & Github

Updated Documentation

Updated Wally Package - 0.5.5 → 0.5.6

1 Like

Made several changes and improvements to the documentation site!

1 Like

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?

1 Like

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! :slight_smile:

You can turn ImageLabels, ImageButtons and even ViewportFrames to 2D Rigid Bodies to do this!

1 Like

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: