Recast navplugin v2 #16564
Closed
Recast navplugin v2 #16564
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
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16564/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16564/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/16564/merge#BCU1XR#0 |
|
You have changed file(s) that made possible changes to the sandbox. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/SANDBOX/refs/pull/16564/merge/ |
|
You have made possible changes to the playground. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/16564/merge/ The snapshot playground with the CDN snapshot (only when available): Note that neither Babylon scenes nor textures are uploaded to the snapshot directory, so some playgrounds won't work correctly. |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
… now moves mesh to NEAR the collision point, instead of AT the collision point (BabylonJS#16587) Issue - "moveWithCollisions" with the parameter slideOnCollide == false used to move the mesh up to the point of collision. Due to floating point inaccuracy, this sometimes meant just outside, and sometimes just inside penetration with the collided mesh. When just inside, subsequent calls to "moveWithCollisions" would snag on the mesh previously collided with. Solution - "moveWithCollisions" with the parameter slideOnCollide == false now moves the mesh NOT up to the point of collision, but up to a point just a small distance short of that collision. The small distance is based on "AbstractEngine.CollisionsEpsilon", the same distance considered "close" by other aspects of the collision system.
Co-authored-by: David Catuhe <[email protected]>
I browsed history but could not get the reason for that particular bug. Why the fix was valid in the first place or the meaning of the 1.5 value. This PR removes it in the hope bug will re-surface and a proper fix will be done. https://forum.babylonjs.com/t/cameragizmo-changes-maxz-every-time-it-shows/57966/6
Also fix BabylonJS#16592 Co-authored-by: David Catuhe <[email protected]>
For prefiltered IBL, using the "dominant direction" approximation for diffuse roughness, slightly negative NdotV values weren't being handled, resulting in artifacts. <img width="85" alt="Screenshot 2025-05-07 at 1 54 25 PM" src="https://github.com/user-attachments/assets/cf10f92c-1199-4a8d-848e-fe011f8ca157" /> <img width="86" alt="Screenshot 2025-05-07 at 1 54 04 PM" src="https://github.com/user-attachments/assets/00e56376-05a0-4ad1-af31-4da6aae20137" />
When I started testing the code with multiple animations, I noticed it was completely broken. I also hard coded lots of values that seemed right with the alien.bvh animation but are not necessary. After this fix, all the [CMU animations](https://mocap.cs.cmu.edu/) work perfectly.
…onJS#16590) There were previously 2 possible render loops depending on if you loaded from a URL or drag & drop. The previous fix for camera pan speed only applied to one of them, so if you didn't use a URL and just dragged and dropped in, you wouldn't get the corrected behavior. This change consolidates down to one render loop for both scenarios, so the camera behavior only has to be defined in one place. Specifically, FilesInput is no longer responsible for creating a render loop - it's now always done by renderingZone.tsx in either case.
- Retrieve Normal vertex buffer - Retrieve correct UV set indices - Add clearcoat support for PBR materials - Allow export with an odd number of negative scales (aka flipped orientation). Not the ideal fix, but my rationale is - This is what Three does, and seems to work OK. - This piece of documentation (last paragraph of https://openusd.org/release/api/usd_geom_page_front.html#UsdGeom_WindingOrder) seems to suggest that handling the orientation flip can be a run/load-time operation? Or, at least, I can't find anyplace where it says that this must be done at export-time. Someone please correct me if I'm wrong :)
this commit BabylonJS@5366c30#diff-8893fe3229ee62f0f24bbfb95ef900191b5b9b7e0eda83bb929f51da05c94eae introduced new struct members. With D3D, uninitialized variables trigger an error with D3DCompile. ``` error X4000: variable 'result' used without having been completely initialized ``` Newer versions of spriv-cross have an option to fix that issue. But updating our fork will take time (like, a lot!). Adding a traverser to visit Declarations need an update as well. So, setting these new members to 0. BN Infrastructure update will catch these kind of issue.
…BabylonJS#16596) This change enables using any WebAudio node as a sound source in AudioEngineV2, and uses this new feature to implement microphone input sound sources.
…t was missing. (BabylonJS#16601) AssetContainer.addAllAssetsToContainer was missing handling InstancedMeshes, so when one of those meshes existed in the node hierarchy, it was getting added to the transformNodes list instead of the meshes list.
Co-authored-by: David Catuhe <[email protected]> Co-authored-by: Popov72 <[email protected]>
Co-authored-by: David Catuhe <[email protected]>
- Compensation and kernelSize can be set per GS material - set Compensation and kernelSize to 0.1 for AA trained SPZ ( https://niujinshuchong.github.io/mip-splatting/ ) - Fixed value overflow for quaternion.
…BabylonJS#16604) This PR primarily is to address this forum issue: https://forum.babylonjs.com/t/babylon-viewer-v2/54317/82 The main problem is that a wrapper options object is constructed, but does not correctly handle options that are just pass-throughs (e.g. the ViewerElement doesn't do anything special with them, like map them to attributes, which is the case for `useRightHandedSystem` for example), and also does not correctly handle callback options (the callbacks passed in are overwritten by the ViewerElement's own callbacks). To fix this, I'm introducing an Options Proxy at the ViewerElement layer similar to what was done in the ViewerFactory layer. While Proxy may be slower for evaluating properties, this is not in the hot path (e.g. options are not evaluated on a per-frame basis), so this should be a fine usage of Proxy. Once this change was in place, it exposed another issue, where the ViewerFactory layer was writing to one of the options, which calls the setter on the Proxy, which passes through to setting a property directly on the target object. This was not intentional, it was just leftover from how the options worked before the Proxy was introduced and got missed. To fix this, instead of overwriting the `onInitialized` options property in the ViewerFactory, it is handled in the options Proxy within the ViewerFactory. To make sure this kind of error doesn't happen again, I also made all the options readonly. Finally this PR has one other unrelated but small fix, where in the case of multiple models, when one is made "active," the camera is reset to the bounds of that single model, not all loaded models.
Rules added: "@typescript-eslint/promise-function-async" "@typescript-eslint/no-misused-promises" "@typescript-eslint/no-floating-promises" "@typescript-eslint/return-await" "no-await-in-loop" "@typescript-eslint/await-thenable" "@typescript-eslint/prefer-promise-reject-errors" "require-atomic-updates" (Warning only) "github/no-then"
Following up on PR BabylonJS#16513 that switched from forEach to for loops. Replace return statements with continue in various loops to ensure that the iteration continues instead of exiting the function.
Needed because these lines were added after the PR was created. From here on - async linting FTW.
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.
First working version, PG injection
#X5XCVT#872