Added Fixed Physics Steps feature and Renamed the 'Use Frame Rate' to… #1992
+3,687
−307
Conversation
This file contains hidden or 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
Collaborator
|
Hello, I quickly tested, it sounds ~ok overhaul but there are several things to fix. In my human vocabulary:
EDIT: I edited my review because timescale and external clock time were taken into account On my side, I will change UpdateSoftBody function name to UpdateSoftBodyRenderedShape |
… 'FPS Limit' because its the most common describtions in any game engine to understand what it do... and moved it to the Game Physics panel in Scene properties editor becuase it affects the physics fundamentaly when using Variable mode
…dded colons on the end of the label of the fixed timestep method so is same like others. fixed the stuttering when using fixed physics mode
changed files which caused the git clone problem
refactored for clarity and etc.
refactored all the code for fixed physics and variable physics modes so they would not have shared code and so would not interfere with each other...
1. fixed the logic rate , it was still tied together with frames and not physics, now is with physics steps (industry standart) 2. fixed the game would speed up if FPS > than physics steps
fixed UI and removed redundant/leftover code...
[Root cause] In camera view, rendering stayed entirely inside the game rasterizer so the interpolated transform from KX_Scene::ApplyPhysicsInterpolation() was displayed directly. In non-camera viewport mode, KX_Scene::ViewportRender() called Blender’s wm_draw_update(), which redraws the 3D View using the depsgraph’s evaluated matrices. Those matrices were still the raw physics poses because KX_GameObject::TagForTransformUpdateEvaluated() only copied the SG transform for dupli tagging and never injected the interpolated state. [Fix implemented] KX_GameObject::ApplyPhysicsInterpolation() now caches the interpolated MT_Transform, and KX_GameObject::TagForTransformUpdateEvaluated() chooses that cached transform when UseViewportRender() is active. It applies the matrix to both the original Object and its evaluated copy via BKE_object_apply_mat4(...) and tags ID_RECALC_TRANSFORM, ensuring wm_draw_update() draws the interpolated pose.
[Always clear on interpolation frames] KX_KetsjiEngine::NextFrameFixed() now runs scene->ClearPhysicsInterpolationState() every frame when interpolation is enabled, ensuring no stale render transforms even if physics didn’t advance (source/gameengine/Ketsji/KX_KetsjiEngine.cpp:800-807). [Store only when needed] StorePhysicsInterpolationState() remains conditional on physics advancement or initialization, keeping the heavier snapshot pass to a minimum while preserving correctness (KX_KetsjiEngine.cpp:808-813). [Per-scene tracking] KX_Scene now keeps m_interpolatedObjects plus RegisterInterpolatedObject() / UnregisterInterpolatedObject() so only objects that actually interpolated in the last frame need clearing (source/gameengine/Ketsji/KX_Scene.h:150-435, KX_Scene.cpp:552-574). [Automatic registration] KX_GameObject::ApplyPhysicsInterpolation() registers itself the first time it interpolates; StorePhysicsInterpolationState() and ClearPhysicsInterpolationState() unregister by clearing the cached flag, keeping the scene list accurate and preventing redundant work (source/gameengine/Ketsji/KX_GameObject.cpp:1842-1904). [Targeted clearing] KX_Scene::ClearPhysicsInterpolationState() now iterates m_interpolatedObjects and only falls back to the full object list when no tracked entries exist, then resets the vector to reclaim memory (KX_Scene.cpp:150-164). [Visibility gating] Optional skip for invisible objects avoids interpolation work when m_skipInvisibleInterpolation is true (default), while setters allow opting back in if a project needs interpolation even for culled items (KX_Scene.cpp:137-147, 585-593). [Documentation] Added inline comments explaining caching, restoration, visibility gating, and default behaviors to help new contributors follow the logic.
for fixed physics mode
refactored/addresses youles wishes
now users can use blenders rigid body constraints inside game, this allows fast and easy setting up rigid bodies with constraints because the rigid body joints object constraints are terrible hard and lack of springs for example.
this operator allows to create blender rigid body constraints between objects but without need the objects to be as rigid bodys in blender. this is because when having enables the objects as rigid body in properties>physics Ui , the performence is decreased in the game, so this operator allows to setup RB constraints without having to enable rigid body for the objects ( blender side )
puts the rigid bodies constraints in the selected collection in outliner.
… collection - now is possible to spawn collection ( instanced ) and have working blenders rigid body constraints on the object. - now is possible to remove the RB constraint binding by deleting the rigid body constraint empty obj in game. - when running the "connect Rigid Bodies" operator and having selected active collection in outliner, it will just move the rigid body constraint empty in that collection automatically.
this mode has 2 options, 1. "Disable RB constraints" and 2. "enable RB Constraints" which enables to have super performence for removing the constraints binding instead of deleting (if many objects)...
and can animate their values even
…nstraints Before this feature, if user had rigid bodies as childs(parented) and they had blender rigid body constraints and then started game and then unparented them during game, these rigid bodies would lose their RB constraint bindings... but not anymore, now the constraints bindings remain intact.
currently when user scales the rigid body or its rigid body constraint empty object, then it can cause glitches, the bigger they get... this fixes it so it behaves more like rigid body joints. = less worry for the user to remember to apply scales... 1. With the axis normalization fix: Scale of obj1 (Rigid Body): You can scale it however you want (uniform or non-uniform) before game start. The constraint axes will be normalized to length 1, preventing instability. 2. Scale of Constraint Empty: You can accidentally scale the Empty (e.g. while moving it). The fix will ignore that scale for the physics calculation. 3. Parented Empty: If the Empty is parented to a scaled object (inheriting scale), the fix will strip out that inherited scale from the axes. The Result: The physics constraint will be stable, its axes will point in the correct direction, and limits/springs/motors will behave predictably—regardless of how messy the scaling is in the Blender scene. The only remaining limitation would be runtime (in-game) scaling, which neither system handles automatically. But for scene setup, the fix solves all your headache scenarios.⚠️ ⚠️ ⚠️ to remember: "in future need build operator/possibility that would recompute constraints, for example when spawning things in different sizes that has rigid body constraints..."⚠️ ⚠️ ⚠️
1. Added auto-parenting for rigid body constraint empties to the first rigid body during scene conversion (BL_DataConversion.cpp) so the visual constraint follows its target immediately at game start. 2. Added the same auto-parenting during runtime replication (KX_GameObject::ReplicateRigidBodyConstraints) so constraints spawned via “Add Object”/instanced collections also follow their target.
Constraint empties created by the operator now force game physics type to “No Collision.” Added a “Place on 3D Cursor” toggle that, when enabled, places the constraint at the cursor and disables the Location and Connection Pattern controls. Operator can run without an active object; it promotes the first eligible selected object to active. Added “Custom Distance” connection pattern with a “Connect Distance” float; it disables the cursor option and connects pairs within the given range. Objects with game physics type “No Collision” are skipped entirely for constraint creation, and the operator warns if none are eligible.
now when using the custom distance option, then it will visualize the connection distance with circles.
it triggers if the rigid body constraint breaks
dont make sense to have it since all logic bricks sensors are self referencing and can use messege...
Fixed physics timestep now uses the user’s maxphystep even when fixed mode is enabled after creation, preventing physics slowdown when lowering Render FPS
added a button to duplicate logic brick on sensor,controller, actuator added seperator to increase the seperation visibility of each logic brick vertically. added a button on logic brick header window to copy logic brick to selected added a button to clear/delete all logic bricks from selected objects.
now is possible to spawn collection of objects without need to use the "edit object > add object" actuator with instanced collection = much easier and more fun building...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
… 'FPS Limit' because its the most common describtions in any game engine to understand what it do... and moved it to the Game Physics panel in Scene properties editor becuase it affects the physics fundamentaly when using Variable mode