-
Notifications
You must be signed in to change notification settings - Fork 3.6k
NavigationPluginV2 addon #17035
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
NavigationPluginV2 addon #17035
Conversation
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Hello!
At this point we support all the V1 plugin functions + offMeshConnections. These are some enhacements beyond V1:
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
/** | ||
* | ||
*/ | ||
export interface INavigationEnginePluginV2 extends INavigationEnginePlugin { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say lets just remove the v2 interface, and just have the new concrete class that also implements the v1 interface (as it already does).
@@ -89,3 +89,5 @@ export * from "../ShadersWGSL/rgbdEncode.fragment"; | |||
// CopyTextureToTexture | |||
export * from "../Shaders/copyTextureToTexture.fragment"; | |||
export * from "../ShadersWGSL/copyTextureToTexture.fragment"; | |||
|
|||
export * from "./tools.internals"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert? Doesn't seem necessary, especially since you are importing directly from the path anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's not exported it's not visible in the ADDONS package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of UMD? @deltakosh, @sebavan - it seems like we shouldn't export internal tools from the core package, any thoughts?
* The navmesh query created from the navmesh | ||
* @remarks This is used to query the navmesh for pathfinding and other navigation tasks | ||
*/ | ||
public navMeshQuery!: NavMeshQuery; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why isn't this nullable? It's not assigned until some functions get called, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The navMeshQuery gets created automatically when the navMesh is generated. If navMesh generation fails an error is thrown so basically you can't do anything with the plugin. navMeshQuery is used in a lot of functions (called in the render-loop) and checking for non-null value would be a performance bottleneck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is the idea that you construct the object and then you must call either buildFromNavmeshData
or createNavMesh
? If so, is the object in an invalid state after construction but before one of these functions are called? Once you call one of these functions, can you call either one of them subsequently on the same instance?
import { GenerateNavMesh } from "../generator"; | ||
import type { RecastNavigationJSPluginV2 } from "../plugin/RecastNavigationJSPlugin"; | ||
|
||
export let BjsRecast: RecastInjection; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this should be nullable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking about this one. I agree that it's not the best practice to leave variables unitialized but this one is maybe an exception. It must be initialized during the init process otherwise the nav engine will not be operational. If I make it nullable, there must be checks for non-null value before using the variable howvever if something fails upon init it makes no sense to access it. I'm not arguing here just loudly thinking. If you still want me to make it nullable, no problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about exporting an accessor function instead (like GetBjsRecast
or something) that is synchronous but throws if the value is not set. Then you'd just have a nullable local module scoped variable (which is correctly typed), and usages of it don't need to do any checks or asynchrony, it will just throw if it is null. It's effectively a runtime assertion to protect against programming errors.
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
Reviewer - this PR has made changes to one or more package.json files. |
@ryantrem since the |
navMeshQuery: NavMeshQuery; | ||
tileCache?: TileCache; | ||
}>((resolve, _reject) => { | ||
GenerateNavMeshWithWorker(meshes, parameters, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like GenerateNavMeshWithWorker
can synchronously throw, but there is no try/catch with a call to _reject. I think that should be added if I'm reading the code correctly.
// callback function to process the message from the worker | ||
workerOptions.worker.onmessage = (e) => { | ||
if ((e as any).data?.success === false) { | ||
throw new Error(`Unable to generate navMesh: ${e}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do these errors go? I assume they just show up as console errors, and the promise on the other side of this never resolves or rejects?
const positions = []; | ||
const indices = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are untyped.
const positions = []; | |
const indices = []; | |
const positions: number[] = []; | |
const indices: number[] = []; |
continue; | ||
} | ||
|
||
const worldMatrices = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const worldMatrices = []; | |
const worldMatrices: Matrix[] = []; |
/** | ||
* The error message if the path computation failed. | ||
*/ | ||
error?: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't error still only valid/present when sucess is false? Still seems like this could be a discriminated union to be more clear, unless it causes some problem.
Already working examples (I need to tide up the code a bit):
http://localhost:1338/#KVQP83#203 = navmesh generation stuff
http://localhost:1338/#KVQP83#209 = obstacles
http://localhost:1338/#KVQP83#213 = offmesh
http://localhost:1338/#KVQP83#245 = move along navmesh with WASD
http://localhost:1338/#KVQP83#244 = raycast