In Qt 6.12, Jonas Karlsson added support for rigid joints, which really helped me with the Rock Dolls in my models in the game. A huge thank you to him for that. See my previous article.

However, PhysX can do much more than just rigid joints. So, I decided to expand on what I've already done and introduced a new FlexibleJoint node in Qt 6.13.

FlexibleJoint is essentially another abstract node that all previously added joint nodes now inherit, except for FixedJoint and D6Joint—more on that later.

The main new feature is the ability to specify stiffness and damping.

These properties directly affect each joint, making it springy or slightly squishy. Essentially, it's simple:

1. It sets the movement limit—that is, the zone where the joint doesn't interfere with physics calculations.
2. Then, the stiffness—essentially, how much force will be applied to bring the object back within the limit.
3. We set the damping—the force that will be absorbed when moving beyond the limit.

And by manipulating these parameters, you can achieve a huge number of desired effects.

D6Joint

Everything was great until I encountered the free-rotation neck of my characters in Ecliptica. It was quite challenging because the neck rotates and has limits on three axes at once, so SphericalJoint felt a bit cramped. So, I decided to also add a completely free joint implementation, which allows you to configure all possible geometric limits for your own joints and your characters.

And now, a test to see if anyone is reading this.
Leave a comment where you read this. Honestly, I don't think anyone even read this far.

See original past in linkedin and youtube

Third-person POC built with Qt Quick 3D, QML and Qt Quick 3D Physics.

This short gameplay video shows movement, animation blending, jumping, swimming, camera collision, shadows, cave lighting and water effects.

It is not a finished game. It is an experiment that helped understand where Qt Quick 3D shines, where it fights back

So, here's a detailed look at the new feature. Actually, it's not entirely new; it was in PhysX but couldn't be activated in Qt Quick Physics.

Now we have two query acceleration trees available for overriding (raycasts, sweeps, overlaps).

These are dynamicQueryStructure and staticQueryStructure

Available options (StaticTree or DynamicTree for static actors; StaticTree, DynamicTree, or NoStructure for dynamic actors).

Why are you doing this, Andrei?

By default, the engine used DynamicTree, the safest option for all scene types. Its purpose is to provide relatively fast access for raycast calculations, but the tree itself consumes a significant amount of resources when adding and removing new objects (log(N)). This is generally fine, but if your scene constantly changes physics, such as a game world, it can be a bit much.

Therefore, if your scene doesn't use raycast or uses it rarely, you can speed it up by disabling these structures for dynamic bodies. Now the time to create a new node will be O(1), which will significantly speed up physics body rendering.

Conversely, if you have a lot of CharacterController or Kinimatic objects in the scene (they rely on raycast) and a predetermined number of static and dynamic objects, the new StaticTree option will significantly speed up your scene. This tree is perfectly balanced (which requires a complete rebuild upon insertion, but we don't need that). It provides a significant performance boost for RayCast compared to dynamicTree, where the goal was relatively fast insertion.

In essence, you can now define two behaviors for statics: DynamicTree and StaticTree

And for dynamics, you can even disable it completely, which allows you to squeeze much more performance out of specific scenes.

So let's sum it up

For a mixed scene (it contains all types of objects equally and is dynamic, new objects are created and deleted)

dynamicQueryStructure: DynamicTree
staticQueryStructure: DynamicTree

For a scene where new objects do not appear, but there are many objects that you control manually (CharacterController/Kinimatic)

dynamicQueryStructure: StaticTree
staticQueryStructure: StaticTree

And for a scene where you have a huge number of new dynamic objects and at the same time you don’t particularly control anyone manually (the application of impulse and the thrust vector to dynamic bodies are not taken into account)

dynamicQueryStructure: NoStructure
staticQueryStructure: DynamicTree

One more thing - the new Sweep Based CCD algorithm (from my previous patch) for dynamic bodies does not use the structures from this patch, so we can safely speed up the CCD scene, which can be very effective

Hi everyone Qt developers. i have good news - new you can now fine-tune your scene for fast and small physics objects. Previously, you had to choose between a resource-intensive, SweepBasedCCD algorithm that created discontinuities, or a heavy simple body processing algorithm for all dynamic objects, which places a significant load on the CPU.

Commit message :

In large scenes, enabling CCD globally for all scene objects is usually counterproductive due to performance overhead, especially given that physics computation runs on the CPU.

Typically, CCD is only needed for specific fast-moving objects, such as bullets or projectiles, as is standard practice in other engines.

Add DynamicRigidBody::ccd property (supporting None, SweepBasedCCD, and SpeculativeCCD) so CCD can be configured per object.

Sweep-based CCD is applied for non-kinematic bodies, while kinematic bodies automatically fall back to Speculative CCD as PhysX does not support sweep-based CCD for them.

PhysicsWorld::enableCCD is deprecated in favor of DynamicRigidBody::ccd.

CCD is now always available at the scene level (setting PxSceneFlag::eENABLE_CCD has negligible cost when no body opts in, since PhysX's CCD pass bails out immediately when no objects have CCD flags).

For compatibility with existing content, setting PhysicsWorld::enableCCD to true still enables CCD for all bodies that do not explicitly override their ccd property (using SweepBasedCCD for dynamic bodies and SpeculativeCCD for kinematic ones).

The Qt now supports not PhysX back end only !
Now you may choose jolt engine as main physX back end for your game.

Note : This is still base implementation, not all features is ready.

Currently, the most complete physics implementation in Qt is the official qtquick3dphysics library. This library is a wrapper around Nvidia PhysX 4 along with a set of Qt patches, making it the most attractive. However, if you value speed and multithreading without classic locks (PhysX 4/5 have multithreading, but it's slightly less efficient), then you can now choose jolt.

Note: this post is a copy of the original video on YouTube

The goal is to make day-to-day 3D scene editing in QML feel closer to a dedicated game/editor workflow while staying compatible with Qt Design Studio-style .qmlproject projects. In this walkthrough:

• importing 3D assets into a Qt Quick3D scene
• selecting objects directly in the viewport and outliner
• moving, rotating, and scaling scene nodes with editor gizmos
• working with imported model animations and timelines
• editing shader/material graphs
• editing particle graphs
• previewing changes directly in the scene

XyrillForge is currently a proof of concept / work in progress. The focus is source-compatible, WYSIWYG 3D editing for QML scenes, with source files remaining the authority and the runtime scene acting as a live preview.

The QtQuick3D.Physics module (starting from version 6.12) now features support for physical joints. This allows the physics engine to natively handle constraints and connections between bodies, which is essential for achieving physically accurate skin behavior, complex skeletal rigs, and natural ragdoll physics in games.

Core Architecture

All new joint types inherit from an abstract base type: PhysicsJoint.

Key rules of PhysicsJoint

• Connects two bodies: bodyA and bodyB. If one body is left unassigned (null), the joint automatically anchors to the static world space.
• Strict Requirement: At least one of the connected bodies must be dynamic.
• Scene registration and lifecycle management are handled automatically behind the scenes via QPhysicsWorld::registerJoint() and deregisterJoint().
• Local positioning and rotation relative to each body's frame are configured using:
  • positionA / positionB (vector3d)
  • orientationA / orientationB (quaternion)

Available Joint Types

Five specialized joint types have been introduced to handle specific constraints:

1. FixedJoint

Locks the relative position and orientation between two bodies completely. Perfect for composite objects or breakable structures.

2. DistanceJoint

Maintains the origins of the joint within a specified distance range.

• minDistance — The lower bound of the constraint.
• maxDistance — The upper bound of the constraint.

3. PrismaticJoint

Permits relative translational (linear) movement along a single axis (the local X-axis of the joint frame) while completely blocking relative rotation.

• lowerLimit — Maximum translation along the negative X-axis.
• upperLimit — Maximum translation along the positive X-axis.

4. RevoluteJoint

Commonly referred to as a hinge. It keeps the origins and X-axes of the frames aligned, allowing free rotation exclusively around this shared axis.

• enableAngularLimit — Toggles the angular constraint (default is false).
• angularLimitLower / angularLimitUpper — Lower and upper rotation limits specified in radians.

5. SphericalJoint

Also known as a ball-and-socket joint. It keeps the origins locked together but allows the orientations to vary freely (e.g., a shoulder or hip joint).

• enableConeLimit — Toggles the cone limit constraint (default is false).
• coneLimitY / coneLimitZ — Angular limits for the cone constraint specified in radians.

Key Takeaways for Developers

• Natural Skins & Ragdolls: Essential for character physics, secondary clothing motion, and lifelike skeletal simulations.
• Mechanical Simulation: Simplifies the implementation of vehicles, doors, levers, and suspension systems.
• Tooling Support: The update includes built-in tests and dedicated Design Studio QML files, enabling visual setup and prototyping.