Physics #81
Merged
Physics #81
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The fruits of my procrastination...
...just not physics :p
Rationale: - `PhysicsState` and `PhysicsSystem` trait can be viewed as the requirements for the provided Runge-Kutta method impl to work. So they are all contained in file `runge_kutta.rs`. Simple Physics systems can choose to utilize the impl, thus using the structs and implementing the traits, or not, completely forgetting about that file, during implementation of `tick()`. - `tick()` of `SimplePhysicsSystems` enum-dispatches to `tick()`s of variants, instead of dynamic dispatches, as for inox2d users are not supposed to bring their own physics systems (as of now). - Decoupling is done realizing that one step of physics simulation is a closure yielding a `Vec2` and changing some contained states, per step. Thus letting one step do the calc, return the `Vec2` and letting external code setting params based on the return value will solve the previous ownership problem. - TODO: The call to step the physics system is put naively inside `end_set_params()`, and without actual time elapsed passed in. Takeaway is, the physics step should be after param setting and before full puppet transform re-calc. But future refactor should provide the user with a better interface (physics still run if `end_set_params()` not called, and actual time elapsed passed in).
Rationale: - `PhysicsState` and `PhysicsSystem` trait can be viewed as the requirements for the provided Runge-Kutta method impl to work. So they are all contained in file `runge_kutta.rs`. Simple Physics systems can choose to utilize the impl, thus using the structs and implementing the traits, or not, completely forgetting about that file, during implementation of `tick()`. - `tick()` of `SimplePhysicsSystems` enum-dispatches to `tick()`s of variants, instead of dynamic dispatches, as for inox2d users are not supposed to bring their own physics systems (as of now). - Decoupling is done realizing that one step of physics simulation is a closure yielding a `Vec2` and changing some contained states, per step. Thus letting one step do the calc, return the `Vec2` and letting external code setting params based on the return value will solve the previous ownership problem. - TODO: The call to step the physics system is put naively inside `end_set_params()`, and without actual time elapsed passed in. Takeaway is, the physics step should be after param setting and before full puppet transform re-calc. But future refactor should provide the user with a better interface (physics still run if `end_set_params()` not called, and actual time elapsed passed in).
Unicode variables! :D
This basically fixes all weird physics behavior
This is a big merge
|
This code is very ugly but we can now finally focus on refactoring |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BEHOLD, IT'S PHYSIC-ING
waifu-physiiiiiiiiiiiiiiics.mp4