You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: en/Advanced_glTF/Debugging_Visual_Auditing/02_debug_drawers.adoc
+9-4Lines changed: 9 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -274,7 +274,7 @@ void draw_bone_bodies(
274
274
? DYNAMIC_COLOR
275
275
: KINEMATIC_COLOR;
276
276
277
-
glm::mat4 body_transform = pose_to_matrix(pose);
277
+
glm::mat4 body_transform = pose.to_matrix();
278
278
279
279
const ColliderDef& def = bone_body.collider_def;
280
280
if (def.shape == ColliderDef::Shape::CAPSULE) {
@@ -293,20 +293,25 @@ void draw_bone_bodies(
293
293
}
294
294
----
295
295
296
-
For physics constraints, most physics engines provide a query API to retrieve the constraint's anchor points and axis direction. Drawing a constraint as a line between its two anchor points plus a small indicator for the constraint axis gives you enough information to visually verify that the constraint setup is correct:
296
+
For physics constraints, the `PhysicsWorld` interface does not expose a generic constraint query API, since constraint introspection is highly engine-specific in Jolt. The code below is **pseudocode** showing the pattern you would implement by casting your constraint handles to the concrete Jolt type (`JPH::Constraint*`) and reading `mPoint1`, `mHingeAxis1`, etc. directly:
297
297
298
298
[source,cpp]
299
299
----
300
+
// PSEUDOCODE — illustrates the pattern; get_constraint_debug_info() is not part
301
+
// of the PhysicsWorld interface. Implement by casting to JPH::SwingTwistConstraint*
302
+
// or JPH::HingeConstraint* and reading Jolt-specific members directly.
303
+
300
304
const glm::vec3 CONSTRAINT_COLOR = { 0.0f, 0.5f, 1.0f }; // Blue for constraints
@@ -273,7 +298,7 @@ The morph system integrates into the frame loop naturally:
273
298
4. **Dispatch.** Bind the descriptor set (which has all morph target buffers registered), push constants, and dispatch the compute shader. One thread per vertex.
274
299
5. **Barrier.** Issue a `VkBufferMemoryBarrier2` on the output buffer (same as Chapter 3) before the rasterizer or ray tracing pass reads from it.
275
300
276
-
The only part that requires care is the per-frame push constant size. If you have up to 64 active morph targets, the push constants become large—64 indices (256 bytes) plus 64 weights (256 bytes) plus metadata equals over 512 bytes. The Vulkan specification guarantees a minimum of 128 bytes of push constant space, but most desktop GPUs support 256 bytes, and high-end GPUs support 256 bytes or more. If you exceed the available push constant space, move the weight data into a small uniform buffer instead.
301
+
The only part that requires care is the per-frame push constant size. With up to 24 active morph targets, `PushConstants` contains 24 indices (96 bytes) plus `MorphWeightBlock` with 24 weights (96 bytes) plus metadata — roughly 200 bytes total. The Vulkan specification guarantees a minimum of 128 bytes of push constant space, but most desktop GPUs support 256 bytes or more. The 24-target cap was chosen to stay within that budget. If you need more simultaneous targets, move the weight data into a small uniform buffer instead.
0 commit comments