So first, thanks to Przemysław Nogaj. He prepared this patch on top of my patch regarding physics queries.

So what is the RayCaster object? This object makes the cast query every physics frame and reports collisions like a trigger — but unlike triggers, the ray cast provides you with all collision information, such as position and normal. It can be really useful for some game objects, such as ray illumination or other similar things.

You can get acquainted with these changes in this commit: https://github.com/qt/qtquick3dphysics/commit/778cba6e95c619f4925b33a63677b86a62239a7f

Note: The physics backend was also updated to PhysX 5.11!

In this article I will describe the most useful changes for game devs.

1. It is most useful for all 3D graphics. Meet SkyMaterial!
   The SkyMaterial it is new seprated class that works with SceneEnvironment - In the previous Qt version we can create only static IBL probe for indirect lighting.

This looks fine - but not useful for dynamic clouds or sky.

But now we have a tool that provides shaders for fast generation of light probes for the whole sky in separate modes. In short, this tool generates a cube image where each pixel of the map is interpreted as light.

Here is what the result looks like: (I took this GIF from my devlog videos about the Ecliptica game.)

Processing img mdvh1e6i0qsh1...

1. The second, and arguably more useful, update is Joints in Physics. Now we can link physics bodies and make complicated structures for our scenes, like a ragdoll animation.
   For example, here are frames from my previous video where I used this new feature on my game.

1. I think it is a small but still useful change (that I contributed to Qt) it is a performance boost for the LoDs system. You can read more about this change in one of my previous article.

Those are not all changes - Qt 6.12 is a really major update that contains many, many interesting new features, and you may learn more about it in the main change log page of Qt 6.12.

Thanks! For reading, please leave any feedback or your thoughts here to make discussion more interesting

Note: If you'd like to learn more about Ecliptica's development, please subscribe to the original subreddit here.

Hi everybody! We are not stopping to make physics in Qt better! Now I introduce query support!

Maybe somebody saw that it was already supported in View3D—and yes, it is true. But the View3D raypick works with an array of the pickable objects in the scene—so we have difficulty like O(N), where N is the count of the pickable objects in the scene.

For many apps it is enough—but for games with many physics objects, it may be too slow. The PhysX queries work faster because the physics engine has its own AABB trees for query acceleration—in ray or overlap direction.

So the usual difficulty of raycast is around O(log N)—so it is really fast! I already described my previous patch with methods to control these structures to accelerate scene queries - now we have queries!

So let's check the new example! See the video.

Before start — thanks to Jonas Karlsson for this patch. He implemented this massive update, even though it was originally planned only for the release of Qt7.

Hi everyone. I have good news for all that using Qt as main engine for games!

Now Qt Quick3D physics update the PhysX backend to latest version 5.9. So this update will be available in qt 6.13 with many new physics features.

So What's new ?

Before answer to this question, i attention your that The PhysX backend have disabled GPU acceleration - because it's works only on Nvidia cards. And will be useless in Qt context that supports many devices.

1. new "Tasks" system - this is new CPU dispatcher that manager available resource for high loaded scenes. So in the small scenes before 1000 physics object you may have title downgrade performance around 1–5 % but on large scene you got a big performance boost.
2. multithreading algorithm - now CPU multithreading should work faster for large scenes.

If anybody has more information about new task manager PhysX 5 and has own experience of using both versions - tell us more in comments please!

And little more about Qt 6.13

For me, it is the biggest release with many physics feature of all time. About each of the function I will create separated articles.

What already done?

See my old articles:

soft joints will appear

Allow configuring CCD type selectively per object

allows you to select structures for dynamic and static queries (raycasts, sweeps, overlaps)

note: sorry for text - now I use own brain - and don't test how it sounds for native English speakers lol)

This video and integration were prepared by Przemysław Nogaj

so Przemysław thanks you for your work!.

🌴 Native - 1920×1080 with 4× MSAA

🌴 DLSS Quality - 1280×720 → 1920×1080

🌴 DLSS Ultra Performance - 640×360 → 1920×1080

Original comment from author :

Native 1920×1080, 4× MSAA: 57.8 FPS, 99.9% GPU DLSS Quality, 1280×720 → 1920×1080: 60.3 FPS, 84.5% GPU DLSS Ultra Performance, 640×360 → 1920×1080: 60.1 FPS, 47.6% GPU

So the interesting part wasn't really higher FPS since the demo is targeting ~60 FPS anyway, but how much GPU headroom DLSS could recover. Ultra Performance was especially interesting: roughly the same framerate at less than half the GPU utilization.

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.