- RigidBody:Clone() now works for custom rigid bodies.
- Added structure parameter to RigidBody.new() to cache the rigid body’s structure for the future.
- Remove restrictions from RigidBody:Clone()
Wow, that’s incredible! With that upgrade, I’m sure you’ll get a lot of new users.
can you link the old collisionservice? I wanna take a look at the source code
Hi! Recently I’m working on a game engine using your module. However the current errors that the module shows are very hard to debug.
For example let’s use this error [Nature2D] Received an Invalid Object Property.
In this case it’s super hard to figure it out why did it error, what property caused it.
For most of the warnings, errors should also say what property/object caused it. In this case it could look something like this: [Nature2D] Received an Invalid Object Property; MyExample (string)!
This is a very important and needed change, so I’ll get this done in v0.6.1! Thank you for the feedback.
- “CanTouch” is not longer a valid property for rigid bodies.
- Fixed bug where Point:KeepInCanvas() won’t calculate collisions accurately.
- RigidBody.CanvasEdgeTouched event now fires only the moment a rigid body collides with the canvas’ edge and not every rendered frame.
- Improved exception handling code.
- Improved error messages for
- If an invalid property is specified, the error message will now contain the name of the invalid property you specified for debugging.
- If properties for completely different physics objects are specified, the error message will now contain the name of the invalid property you specified.
- If a must-have property is not specified, the error message will now contain the name of that must-have property.
- RigidBody.Touched event now returns the rigid body’s id as well as the collision information (Collision axis, depth, vertex and edge). This can be beneficial for creating visual effects. For example:
Iterations provide accurate calculations for more rigid and smoother physics. Constraint iterations are applied to
Constraint:Constrain() method. Constraint iterations are extremely useful of rod constraints and rope constraints. Constraint iterations do not work on spring constraints.
Collision iterations are used to provide accurate and rigid collision detection and resolution. By default both of these iterations are set to 1. Iterations can be in the range of 1-10 only. Collision iterations can be set only if quadtrees are being used in collision detection.
Keep in mind that the higher the number of iterations the more accurate results. But, having more iterations means you’ll have to sacrifice performance. The lesser the number of iterations, the better performance but we’ll have to sacrifice on accuracy. So be careful where you use them!
Recommended Iteration Amounts:
Constraint Iterations - 3
Collision Iterations - 4
- Added constraint and collision iterations and their functionality.
- Added new methods to Engine
- Updated RigidBody:Update() to use constraint iterations.
- Fixed RigidBody.Touched and RigidBody.TouchEnded after adding iterations.
- Fixed MouseConstraint plugin bug - Stop looping through the rigid bodies if we have already found one to attach to the mouse.
Examples of me using iterations for more accurate physics for rigid bodies and constraints.
Here, a simulation of a few boxes. They very rarely clip into each other and act more rigid than before. Running at 3 Collision Iterations and 3 Constraint Iterations.
Similarly, a box suspended from a rope. See how the rope doesn’t let the rigid body go farther than a set distance at all and immediately pulls it in place? Running at 5 Constraint Iterations.
Nice job, however will you ever consider making this recommended for (2d) games?
Not currently. The library is still under heavy work (been in beta for 3 months). Once I’ve got everything functional + new features, this library will be ready for dedicated 2D games. Right now, it’s just out for you to fiddle around with! If you’re are fine with the features it currently has, then you may consider using it for a larger project.
- Change default friction and airfriction to 0.1 and 0.02.
- Add CanRotate property as a valid property.
- Set CanRotate to true by default.
- Add new methods to RigidBodies
RigidBody:CanRotate(canRotate: boolean)- Determines if a rigid body can rotate after collisions or when forces are applied, extremely useful for creating platformer games, top-down games etc.
- Restrict RigidBody:CanRotate() for custom rigidbodies
- Update RigidBody:Update() and Engine:Create() to adhere to CanRotate
- Add UniversalMass as a valid physical property of the Engine. By default set to 1
Incase you’re wondering how rigid bodies act when their CanRotate property is set to false:
If you’re creating platformers, character controllers or top-down view games then this feature should be perfect for you!
Looks incredible! Nice work dude!
I’ve updated the documentation site w.r.t the last 4 versions/updates. Edited a few code examples. Edited a few tutorials as well. I also wrote a new and short tutorial which deals with Engine Iterations. You can check that out here: Engine Iterations | Nature2D
Working on rigid body manipulation support for custom rigid bodies i.e. resizable, repositionable, rotatable hexagons/triangles/other polygons! (For v0.6.5)
Here’s a re-sizable triangle!
- Removed restrictions for custom rigid bodies.
- Optimized rigid bodies with CanRotate set to false (Avoided 2 loops in
RigidBody:SetScale()method as an alternative to
RigidBody:SetSize()but only for custom rigid bodies.
RigidBody:SetScale(scale: number)- The scale of the default size is 1. Passing in 2 as the scale will double the size of the custom rigid body, etc. Similar to how UDim’s scale property works.
RigidBody:SetPosition()now works with custom rigid bodies.
RigidBody:Rotate()now works with custom rigid bodies.
- Fixed bug in
RigidBody:SetSize()changed only the size of the GuiObject and not the point-constraint structure.
RigidBody:Rotate() all in action at once on a custom rigid body (an irregular polygon)!
I’m delighted you made progress. They’re rather good.
Working on improving garbage collection in Nature2D. The library in its current state is highly prone to memory leaks due to how different Destroy() methods have been implemented and how GC’ing is dealt with. I’ll be using Janitor to solve these issues.
You can track the progress over at the github repository:
Linked Pull Request - #33
Implemented proper garbage collection in the library for the Engine and all its Physics Objects to reduce chances of memory leaks in key areas. All problems listed in #33 have been dealt with.
- Added Janitor to
- Implemented garbage collection in Engine.lua
- Handled how connections are disconnected.
Engine:Stop()no longer destroys connections of the Engine (Updated, Started, Stopped, ObjectAdded, ObjectRemoved). It simply pauses the engine by disconnecting the primary RenderStepped connection.
Engine:Destroy()- Disconnects all events, destroys all rigid bodies, points and constraints and also makes the engine unusable.
- Implemented garbage collection in Point.lua
Point:Destroy()- Destroys the point’s GuiObject, destroys the point’s parent constraint (if any), and is no longer part of the engine.
- Re-wrote garbage collection in Constraint.lua
Constraint:Destroy()- Destroys the constrain’t GuiObject, destroys the constraint’s parent rigid body (if any), destroys its points (point1 and point2), and is no longer part of the engine.
- Re-wrote garbage collection in RigidBody.lua
RigidBody:Destroy()- Destroys all events (Touched, TouchEnded, CanvasEdgeTouched), destroys its GuiObject, destroys its constraints (edges) which subsequently destroys all its points (vertices), and is no longer part of the engine.
- Destroying the GuiObject of the rigid body via
- Destroying an edge of the rigid body via
- Destroying a vertex of the rigid body via
keepFrame: booleanparameter no longer determines if the GuiObject of the rigid body is destroyed when the method is called. Passing it in as true will still end up destroying the GuiObject.
Plugins.MouseConstraint()will not function properly due to the introduction of Point:Destroy().
These bugs shall be fixed in v0.7.1 along with bug #37.