landmass

[sleek scarab]

The one line on the second floor is fairly slim because I set the border radius high 🙂

@fathom jetty you're still maintaining bevy_rapier, right?

If so, this might be relevant to you as well 🙂

I've added a tiny crate to convert avian colliders to navmeshes, and it should be easy to add another crate for rapier integration

(Also, here it's very noticeable that we don't have a serialized image type for the textures yet lol)

[near nexus]

Fantastic! Simply fantastic. 👏

[sleek scarab]

Thank you so much. I learned this from you!

[sleek scarab]

@gentle basin how important is determinism for navmesh gen? I have no idea how navmeshes are done in multiplayer games, but I would have assumed that only the server uses them.
Though I remember you doing something recently where only inputs were sent between players, so in that case they would need a navmesh each

[wicked shard]

Usually the server owns and uses the navmesh and clients just interpolate

IME

[sleek scarab]

makes sense, thanks 🙂

I'll delegate determinism to "when I feel like it" then haha

I think we may even already be deterministic, but I haven't checked

I don't think there are any transcendental function calls

Ah @sharp oxide you asked about layers before. Here you can see that a mesh with mutiple vertical floors is nicely supported out of the box 🙂

@wicked shard I believe you could use the crate in its current form already for baking your navmesh FYI

The things missing are mainly QOL and API, but the underlying functionality is mostly done. The only big thing missing is tiling, but since we don't have asset streaming, you probably don't need that if you don't update intend to update the navmesh at runtime IMO

Ah also @hollow quartz, you may be interested in this as well 🙂

[gentle basin]

If client movement is predicted or if only inputs are networked, then the navmesh needs to be deterministic

[sleek scarab]

Do you know examples where that would be the case?

[gentle basin]

RTS games for instance usually only replicate inputs

[sleek scarab]

Aaah I see

Those definitely need a navmesh, yeah

[sleek scarab]

Something like an FPS with bots wouldn't need that, right?

Since I assume the prediction code for the bots would just use the same code as for players

[sleek scarab]

@unreal rover I've never looked into how to make sure a library is deterministic. Do you have some advice here? I think you run some tests on all operating systems?

[sharp oxide]

Oh oh, I know ... My game!

[gentle basin]

Probably not since they usually use server-authoritative replication. And the bots would be replicated from the server.
But something like rocket league would need it. Basically any games that predict other clients instead of just their client

[sleek scarab]

Hehehe

[sharp oxide]

I don't replicate only inputs, but I definitely don't plan to replicate navmeshes 🤣

[gentle basin]

MOBAs/Arena games, etc.

[sleek scarab]

Ha, interesting. I would have expected the navmesh stuff to be done on the server and then clients predicting stuff based on velocities etc

[sharp oxide]

Ideally you'd do this where possible, but there are plenty of cases where the client might need to predict something that needs pathfinding, even if it's as simple as "You can only use a skill on a place you can walk to"

If such things end up non-deterministic, then it could start causing issues (especially if you use the path and not just a yes/no question)

[sleek scarab]

Totally forgot that in some genres players also have navmeshes 👀

[sharp oxide]

Yea and there's the plain "the player just moves using navigation too" yea

Lots of games still let you move by clicking on the groun after all

[sleek scarab]

Yeah true, MOBAs again come to mind

I was thinking about first person stuff mainly since that's what I do

[sharp oxide]

Or retro MMORPGs

[sleek scarab]

Oh right

[sleek scarab]

And in my use cases, only NPCs need navmeshes

[sharp oxide]

Hopefully in many cases you can have prebuilt navmeshes however

[sleek scarab]

But y'all are completely right

Alright, that bumps determinism up my priority 😄

Again, I think it's already deterministic

But I'd like to add tests ensuring that

Also @sharp oxide I think you said building a height field is easier for SDFs than building a trimesh?

Asking because I have builtin support for Mesh3d and Collider and API for adding support to other types to act as navmesh affectors

Currently, that API expects you to create a trimesh

which is very convenient, as it allows you to send it over the to the editor and preview it nicely

A heightfield can also be previewed, but is not visualized nearly as nicely as a trimesh

Note that this is just convenience API. You can always bypass bevy_rerecast and just do whatever you want with rerecast directly

[sharp oxide]

Not necessarily easier, but it should be possible to make it cheaper

And in my game, with servers needing to compute navmeshes as player change terrain, or when a dungeon is generated whenever a player starts a mission, I sure want it to be cheap

[sleek scarab]

yeah makes sense

Then I think it's best you use rerecast directly

The bevy layer is thin anyways

[sharp oxide]

It's not like bevy_rerecast would know what the heck SDF colliders are anyway 🤣

[sleek scarab]

Well, I have API for

app.add_rasterizer(some_system_that_turns_navmesh_affectors_into_trimeshes)

[sharp oxide]

Also, is there some sort of support for cheap rebuilding of modified sections of a navmesh?

[sleek scarab]

So it would be elegant if that was flexible enough to support SDF colliders

[sleek scarab]

yep 🙂 That's tiling

Not implemented yet, but that won't take long when I get to it

Basically, the map is split into multiple sub-navmeshes

And when you modify something, that tile is rebuilt

[sharp oxide]

Neat, cause I may or may not be planning for the terrain in my game's dungeons to change constantly 👀

[sleek scarab]

Also allows streaming of big navmeshes FYI

[sharp oxide]

Gotta use that smooth min/max you get for free with SDFs

[sleek scarab]

hmm? what's that?

[sharp oxide]

https://www.shadertoy.com/view/lt3BW2

[sleek scarab]

Aaah I see 😄

[unreal rover]

Yeah I have this one and also a local determinism test elsewhere

It runs a 2D simulation with some jointed together objects falling on the ground and colliding for 500 steps, and then it queries for all positions and rotations, and computes a djb2 hash value based on the bytes of all the isometries. The expected hash is manually written into the file, and if it doesn't match on some platform, CI will complain and you need to update it

[sleek scarab]

So the idea is:

• Do stuff with the library
• Write down the hash
• Verify that all platforms get the same hash
  ?

[unreal rover]

Yeah

[sleek scarab]

nice, thx

What do you do for local determinism?

[unreal rover]

It just creates a new App several times and tests that they all return the same result
https://github.com/Jondolf/avian/blob/c15549d6f752ca27c83ace3745e9eaa2b314d674/src/tests/mod.rs#L152-L184

[sleek scarab]

Ah, fair enough 🙂

[timid forge]

there are better ways, they're just more complex https://www.jdxdev.com/blog/2021/07/06/rts-pathfinding-2-dynamic-navmesh-with-constrained-delaunay-triangles/

https://youtu.be/SYDxb6pVUIg?t=24 is a really good visualization

[sleek scarab]

Oh hey I know that post 😄

[timid forge]

I may have posted it every time navmeshes come up here lol

[sleek scarab]

I think someone interested in it should be able to have a leg up compared to Unity, since a lot of these processes are implemented in rerecast. E.g., no need to write your own Delaunay triangulation.

Also, I wouldn't be opposed to adding it to rerecast as an alternative strategy

[timid forge]

does rerecast implement its own delaunay triangulation>

[sleek scarab]

Ye, it ports the one from the C++ impl

It was very important to me that the Rust port generates the exact same navmesh as the original for now

So I didn't use spade

I believe Godot uses an unmodified Recast, so we should have full parity with Godot

Unreal and Unity both use forks

[sleek scarab]

Since I don't have a need for it, I won't try to implement it. But PRs are welcome in case you ever want to get nerdsniped @timid forge 😄

[sleek scarab]

Oh wow I didn't know that video. Looks supremely cool 👀
@near nexus check this out

(though you probably already know it)

[sleek scarab]

@light comet as you can see, Bevy cannot currently send textures over BRP because they are not serializable. I've discussed that with the rendering folks and they're fine with me adding a SerializedImage analogous to SerializedMesh.
If I manage to make a PR soon, may I place it in the 0.17 milestone? Should not be controversial.

[light comet]

I can live with that

[sleek scarab]

thanks 🙂

[mellow mirage]

@sleek scarab looks like the triangles in the detail mesh don't have a consistent ordering... neither clockwise nor counter-clockwise?

Or I've parsed out this data incorrectly lol

It's currently complaining about the first two triangles. If I try to parse them CCW, the second triangle fails. If I try to parse them CW, the first triangle fails.

[sleek scarab]

possible

I'm not entirely sure

[mellow mirage]

WAIT NO I'M BEING STUPID

[sleek scarab]

Though if it was inconsistent, my mesh wouldn't show up here due to culling, right?

^

[sleek scarab]

Don't tell me you also used .windows() instead of .chunks() lol

[mellow mirage]

Let me investigate further before I yap more lol

Nope I don't see what's wrong...

[sleek scarab]

https://github.com/janhohenheim/rerecast/blob/main/crates/bevy_rerecast_editor/src/visualization.rs#L113-L177

maybe this can help?

[mellow mirage]

Looks fairly similar to my code...

Ok I was being stupid

I was adding the first_triangle_index to the vertex indices in a triangle 🙂

@sleek scarab

[sleek scarab]

ah, that explains it 😄

[sleek scarab]

OOOOOOOOO 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

[sleek scarab]

The blue gizmos are still the poly mesh, right?

[sleek scarab]

This is great 😄

No more stair problems

[sleek scarab]

@fast pawn ^

[mellow mirage]

yes

[mellow mirage]

I'm so hyped for this

[sleek scarab]

@mellow mirage lemme know if there's anything I should change on the API 🙂

There are a few things that annoy me

So far

• Use no Vec3A in API
• Split PolygonMesh::polygons into two vecs instead of one containing everything
• Make sure the user doesn't need to know about RC_MESH_NULL_IDX
• Make some flags bitflags

[mellow mirage]

Yes Vec3A in the API makes it a little cumbersome to convert

I'm noticing that the detail mesh weirdly can sometimes be both above and below the regular mesh?

Green here is there detail mesh, blue is the regular mesh

Not sure if that's intentional?

[sleek scarab]

It's the same in C++

poly mesh

[mellow mirage]

Oh? if that's the detail mesh, it'

's not as accurate as what you gave me

[sleek scarab]

detail mesh

[mellow mirage]

Ahhh got it

[sleek scarab]

hehe

[mellow mirage]

Hmmm ok I guess it's fine then

[sleek scarab]

Unfortunately I cannot display both at the same time in C++

Or at least not without looking into how ImGui works lol

[mellow mirage]

Haha, yeah rendering both here makes it really messy in Rust lol

[sleek scarab]

wait, let me do a video, that's easier

there we go

[sleek scarab]

I'm currently adding checkboxes for visualizations to the Rust editor so I can debug edge cases better

[mellow mirage]

In that vid it looks like the detail mesh is under the regular mesh though?

[sleek scarab]

ha, you're right

Maybe we are visualizing them wrong?

There's also this

Is that closer to what you're seeing?

[mellow mirage]

No mine is closer to the opposite. It's like there's an off by one error on the detail mesh

Like it looks shifted up a bit?

[sleek scarab]

hrmm weird

I'll investigate later, need to be AFK for some minutes

If you want to try your hand, here's the C++ code

sec

@mellow mirage

• Poly mesh: https://github.com/recastnavigation/recastnavigation/blob/main/DebugUtils/Source/RecastDebugDraw.cpp#L855-L962
• Detail mesh: https://github.com/recastnavigation/recastnavigation/blob/main/DebugUtils/Source/RecastDebugDraw.cpp#L964-L1063 (it's the function right after)

rcPolyMesh and rcPolyMeshDetail are exactly identical to our meshes.

[sleek scarab]

@mellow mirage I quickly checked the code on my phone and it looks like maybe the poly mesh is offset by 0.1 in Y direction when drawing for some reason

Does that match what you see?

In any case, I wouldn’t worry about that. It’s just an offset in the drawing, the underlying data is correct 🙂

[mellow mirage]

I think I'm seeing the opposite? the detail mesh looks offset 0.1 in Y direction up

So it looks like the detail mesh is higher than the poly mesh when on flat ground

[sleek scarab]

Maybe the cpp editor uses -Y up?

No clue

[mellow mirage]

Yeah I'm not sure...

[sleek scarab]

UI is not too pretty yet, but I've added different visualization options 🙂

You can see that I also have the detail mesh above the poly mesh

[sleek scarab]

Also added the ability to toggle the visual aids off and only show affectors as wireframes. Looks pretty cool 👀

[light comet]

Is this using bevy_editor_cam as the controller?

[sleek scarab]

It’s using the flycam from the bevy examples

Not sure what its official name is haha

[light comet]

ahaha

Very funny to see it getting used more widely; I have so many problems with that code

[sleek scarab]

Oh really? I didn’t inspect it at all and blindly copy-pasted it 😄

I would love to have bevy_editor_cam instead, but I don’t know how I would be able to set it into a flycam mode

#editor-dev was also in agreement that it should be configurable, but I haven’t seen anyone write code for it, and I didn’t want to spend too much time fiddling with it

[light comet]

Yeah, see https://github.com/bevyengine/bevy/pull/20215 for complaints

This is a good motivating use case for figuring out high-quality composable first-party camera controllers today

Rather than waiting on an Official Editor to need them

Well, maybe not today today :p

[sleek scarab]

Oh wow I completely missed that

[sleek scarab]

Yeah definitely, the navmesh editor should be in production use after the next few weeks

[sleek scarab]

This will be great to have 😄

@light comet while I happen to have you on the line so to speak, does this sound like a good upstreamening plan?

I'm happy that we already got the two biggest pathfinding authors Andriy and Fraçois on board for integration 🙂

[light comet]

Yeah, this seems like the right shape.

[sleek scarab]

Little ping @hollow quartz, do you think that rerecast is something that would be useful to integrate in your game? 🙂

Also @fathom jetty I haven't touched Rapier in years, so do you think you could spare a little bit of time to help me out?

Here's the avian integration: https://github.com/janhohenheim/rerecast/tree/main/crates/avian_rerecast

I heavily assume that most of this is just copy-pasteable to rapier

[fathom jetty]

I’d love to, my current priority is final touches on updating bevy_rapier to latest rapier then I may be able to look into that

[sleek scarab]

thanks a bunch!

[sleek scarab]

@mellow mirage

I believe landmass is borked on nightly

[mellow mirage]

Might be related to https://github.com/rust-lang/rust/issues/144621 ?

Sounds similar from a very short skim lol

Apparently fix is merged so try again tomorrow?

[sleek scarab]

I was also thinking of that

[sleek scarab]

will do!

[unreal rover]

Oh hey that's the same thing Avian's CI is failing on

(or was yesterday, need to rerun to see if it's fixed now)

[fast pawn]

nightly was broken on glam #rust message

[sleek scarab]

@mellow mirage I've generated a rerecast navmesh for Chainboom if you want to try it with landmass

[mellow mirage]

Sure I can plug it in at least haha

[mellow mirage]

Coolio, I'll check that out when I get home

[sleek scarab]

let me also give you an untextured glTF so you have something to look at

[sleek scarab]

@mellow mirage could you help me out? I'm trying to write an asset loader, but I always get empty bytes

It looks fairly standard: https://github.com/janhohenheim/rerecast/pull/15/files#diff-e6e646467b3b639061a9869790994ce3335227ec2840f1311b9f3b86eb1cbe7b

When I debug print the bytes at line 42/43, I get an empty vector tho

Context: I'm using this inside an automated test

And it's entirely possible that the issue is that I'm not adding some necessary plugin: https://github.com/janhohenheim/rerecast/pull/15/files#diff-a9973e2e055cca800e7ba2552558b9767a9241aed1af3a5c5442292ed5a34b38R109-R129

But everything looks correct to me?

If you want to check it out yourself, just run cargo test

(on that specific branch)

[mellow mirage]

read is not the correct call, I think it's called read_to_end or something

It's in an ext trait

[sleek scarab]

that was exactly it!

Thanks a bunch 😄

This is the user-facing API now btw

fn generate_navmesh(mut generator: NavmeshGenerator, mut commands: Commands) {
    // configure things like the agent height
    let config = NavmeshConfigBuilder::default();
    // this is a `Handle<Navmesh>`. It's reserved and will get "filled" asynchroniously
    let navmesh = generator.generate(config);

    // This spawns a debug gizmo for visualizing the detail mesh
    commands.spawn(DetailNavmeshGizmo::new(&navmesh));

    // This is just here to save the handle somewhere.
    // Maybe pass it to landmass? Or just save it in a resource like here.
    commands.insert_resource(NavmeshHandle(navmesh));
}

Or alternatively, you use Bevy's regular RemoteHttpPlugin and generate the navmesh on the editor

You can then load the navmesh from disk with the asset loader

And if you have hot reloading, you can tweak the navmesh in the editor and save it, and Bevy should do the rest automagically 🙂

[sleek scarab]

Update: newest nightly building landmass again, if I use this patch: https://github.com/Emerentius/ord_subset/pull/9

[mellow mirage]

Oh I goofed, this is fixed on landmass main, I just haven't published a new release of landmass

Sorry about that!

[sleek scarab]

No problem 😄

@mellow mirage I believe we are now at the stage where we can publish integration plugins FYI

I recently implemented:

• Code-first navmesh generation API (see above)
• Load Asset<Navmesh> from disk
• Save a navmesh from the editor to disk
• Polished the API some more

The only things I still want for the MVP are

• configurate params in the editor
• load configurations from navmeshes on disk (so you can adjust them)

Then it should be already usable by projects that don't need dynamic rebuilds 🙂

That also means that the non-editor workflow is pretty much done for the moment, until I go and add tiling

[near nexus]

Absolutely brilliant!

[nocturne copper]

I really love it ❤️

[sleek scarab]

@mellow mirage how come you're doing the CW checks on the XY plane instead of XZ?

Is landmass Z up internally?

oh hey there it is

does that mean I need to do .xzy() on my data, given that it assumes Y = up?

[native star]

And flip the Z axis after

[sleek scarab]

*before you mean, right?

[native star]

I don't thinks so?

coordinate space conversion make my brain hurty

[sleek scarab]

same ;-;

[sleek scarab]

Meh, I have to give up for the moment

@mellow mirage when you have time, could you take a look at what I've been tinkering with?
This is my rerecast -> landmass code: https://github.com/janhohenheim/foxtrot/pull/412/files#diff-9427b1919c7e7e7f172d76149fc0baacd522f29706e2a33b50f4d9cbabefe330R44
And this is my landmass fork: https://github.com/andriyDev/landmass/pull/130

The landmass fork is mostly just trivial renames and types, but I've commented on one line where I believe the old check was bugged

Seems like no matter what I do, I get Landmass navmesh failed validation: The triangle at index X in the height mesh is clockwise instead of counter-clockwise

[mellow mirage]

That line is absolutely wrong, thanks!

[mellow mirage]

Are your triangles actually both? Or is the check wrong?

[sleek scarab]

Honestly, I'm not sure at this point 👀
I'll double check

[sleek scarab]

@mellow mirage given that landmass seems to use a different coordinate system from bevy / rerecast, should I convert all verts like this?

trait LandmassVec3: Copy {
    fn landmass(self) -> Vec3;
}

impl LandmassVec3 for Vec3 {
    fn landmass(self) -> Vec3 {
        Vec3::new(self.x, -self.z, self.y)
    }
}

[mellow mirage]

You shouldn't have to? CoordinateSystem::to_landmass should handle that?

[sleek scarab]

Oh okay, so bevy_landmass::NavMesh gets everything in Bevy coordinates?

[mellow mirage]

Yup!

[sleek scarab]

Cool!

Then let me print the CCW-ness of my tris now

can confirm what Francois reported: all polygons and all tris are CW

landmass wants CCW, right?

If so, something weird is going on

When I omit the height field, it will only accept my poly mesh indices if they're not reversed

Which imo would be CW

Mind taking a peek? https://github.com/janhohenheim/foxtrot/pull/412/files#diff-9427b1919c7e7e7f172d76149fc0baacd522f29706e2a33b50f4d9cbabefe330

[mellow mirage]

Oh I can't remember, there might be a weirdness - the landmass coordinates need to be CCW, but the conversion from bevy coordinates to landmass coordinates might flip the sign and make it CW?

[sleek scarab]

Ooooh that would explain it!

@near nexus is oxi_nav CW?

[near nexus]

I believe so.

As a consequence of the contour winding order, which should mean outlines = CW, holes = CCW.

And these are used for triangulation iirc

[sleek scarab]

Great, then that matches what Andriy says 🙂

Note to self: rerecast is CW and uses bevy coords, landmass expects the navmesh to be built in Bevy coords and to be CW.
That means that no conversion should be necessary

Which leads me to believe that this is broken on the landmass side 😬

[mellow mirage]

@sleek scarab I think I could make the coordinate system decide CW or CCW. So even in Bevy it would be CCW. Since you're generating navmeshes CCW and need to flip them, it might be better if landmass does it automatically

Thoughts?

[sleek scarab]

Navmeshes are CW

So I don’t benefit from this haha

Just needs to be documented on landmasses side, but I can PR that

[sleek scarab]

I suspect the indexing into the actual vertices is bugged for landmass

That, or the coordinate conversion is applied at the wrong stage

[mellow mirage]

Then why does this https://github.com/janhohenheim/foxtrot/pull/412/files#diff-9427b1919c7e7e7f172d76149fc0baacd522f29706e2a33b50f4d9cbabefe330R77 do reverse stuff?

[sleek scarab]

Because I wrote that code before chatting with you 😄

[mellow mirage]

Ohhhh LMAO

fair fair

[sleek scarab]

Haha

Issue is that when removing the faulty reversing, I still get "random vertex at index 33 is CW and not CCW"

Come to think of it, that’s a very misleading error message given that bevy_landmass expects CW

[mellow mirage]

Yeah I was just thinking that haha

[sleek scarab]

When does the coordinate conversion for the height mesh happen?

[mellow mirage]

The top of HeightNavigationMesh::validate, I call CS::to_landmass

[sleek scarab]

Aah gotcha

Something fishy is going on beyond the CW-ness. If I remove the CW check, I get this:

And commenting out the validation outright nets me

[mellow mirage]

@sleek scarab Why did you change https://github.com/andriyDev/landmass/pull/130/files#diff-33bb3cc574b69a17cf73d31044e89629d4a9517e09f5f9be074686df986eb622R498 from u16 to usize? Could it be that the vertex indices aren't relative to the start of the submesh vertex range?

[sleek scarab]

They are relative in rerecast, see the docs

[sleek scarab]

Because you’re using usize for everything else that can be indexed, so I thought it would be more consistent 🙂

Note that rerecast now uses u8, if you want to use the exact same API

[mellow mirage]

Ah yes I think that's my preference, mainly so we limit the memory usage (I'd expect the detail mesh to be big compared to the polygon mesh)

[sleek scarab]

Then I can also go ahead and change some other indices to u16 later

[mellow mirage]

If there's a bug in landmass, I don't see it 🙁 This is failing when its trying to iterate through the vertices of a height polygon. So it really seems like something is wrong with the indices being passed in

https://github.com/janhohenheim/foxtrot/pull/412/files#diff-9427b1919c7e7e7f172d76149fc0baacd522f29706e2a33b50f4d9cbabefe330R103 Why are you changing the triangles here? Couldn't the triangle indices no longer match up? as in the triangle_index and the triangle_count may no longer correlate with where they end up after the collect

[sleek scarab]

Alright, let me really really make sure the input is right

Thanks for checking

[sleek scarab]

Updated my branches / PRs

Locally, when I create the detail navmesh debug mesh, I validate all triangles being CW and panic if not. And it indeed does not panic

I've changed the landmass types to align exactly with the rerecast height mesh types

and I've added a dedicated function called rerecast_to_landsmass

If you take a look at that, you can see that the only transform even left for me to do is convert the vertices from local coords (u16) to global coords

And I assume landmass wants the vertices to be in global coords? And not relative to some bounding box or another

[mellow mirage]

yes

[sleek scarab]

This makes me believe that there must be a bug in landmass, as there is no longer any place for my code to really have a bug in
Given that the detail mesh gizmos show that the mesh is well-behaved

I'll dig a bit into the relevant landmass code

Maybe it's a simple "oops we used this index offset instead of this"

[mellow mirage]

That's what I'm expecting, but I can't see it :/ I spent a while looking at the code because I figured mine was most likely to be broken lol

Wait

https://github.com/janhohenheim/foxtrot/pull/412/files#diff-9427b1919c7e7e7f172d76149fc0baacd522f29706e2a33b50f4d9cbabefe330R122

This line is using the polygon mesh?

[sleek scarab]

AAAAAA

hahaha

[mellow mirage]

hahahaha

[sleek scarab]

well would you look at that, the validation passes now

thanks!! I was a silly goose haha

[mellow mirage]

Haha no worries! You caught my own silly goose moment in your PR 😛

[sleek scarab]

Alright, my code now just inserts a NavMeshHandle into the archipelago and hopes everything connects magically

but it doesn't

Do I need to do anything else?

[mellow mirage]

oh yeah you need an island

[sleek scarab]

ooooh

[sleek scarab]

I assume simplest is to spawn just one?

Even technically the mesh is separated into distinct areas

[mellow mirage]

Yup! The mesh does not need to be connected

[sleek scarab]

But I'd have to split these out first, right?

[sleek scarab]

cool!

[sleek scarab]

Can the Island be the same entity as the Archipelago?

(Since I only have one)

[mellow mirage]

Oh uhhhh I'm honestly not sure. I don't think that would technically be a problem??

[sleek scarab]

Eh, I'll do two entities to be sure

And the navmesh handle is on the island, right?

my nightly is really not liking me constructing things from aliases haha

[mellow mirage]

Yup!

[sleek scarab]

oh wait no that is actually my bad

[mellow mirage]

Yeah that's just normal rust I think...

[sleek scarab]

yep

[mellow mirage]

Yeah it's a limitation. I've had to use NavMeshHandle itself to construct it :/

[sleek scarab]

AAAAAA

It works

The dual gizmos are because I also use the rerecast gizmos on top

Can I tell the landmass debug gizmos to only display the pathfinding stuff and not the navmesh?

Anyways, treat https://github.com/andriyDev/landmass/pull/130 as done

And for future readers, this is the entire secret sauce:

fn rerecast_to_landsmass(
    rerecast_navmesh: &bevy_rerecast::Navmesh,
) -> bevy_landmass::NavigationMesh3d {
    let orig = rerecast_navmesh.polygon.aabb.min;
    let cs = rerecast_navmesh.polygon.cell_size;
    let ch = rerecast_navmesh.polygon.cell_height;
    let to_local = Vec3::new(cs, ch, cs);
    let nvp = rerecast_navmesh.polygon.max_vertices_per_polygon as usize;

    NavigationMesh3d {
        vertices: rerecast_navmesh
            .polygon
            .vertices
            .iter()
            .map(|v| orig + v.as_vec3() * to_local)
            .collect(),
        polygons: (0..rerecast_navmesh.polygon.polygon_count()).fold(Vec::new(), |mut acc, i| {
            let poly = &rerecast_navmesh.polygon.polygons[i * nvp..];
            let verts = poly[..nvp]
                .iter()
                .filter(|i| **i != PolygonNavmesh::NO_INDEX)
                .map(|i| *i as usize)
                .collect::<Vec<_>>();
            acc.push(verts);
            acc
        }),
        polygon_type_indices: rerecast_navmesh
            .polygon
            .areas
            .iter()
            .map(|a| a.0 as usize)
            .collect(),
        height_mesh: HeightNavigationMesh3d {
            polygons: rerecast_navmesh
                .detail
                .meshes
                .iter()
                .map(|submesh| HeightPolygon {
                    base_vertex_index: submesh.base_vertex_index,
                    vertex_count: submesh.vertex_count,
                    base_triangle_index: submesh.base_triangle_index,
                    triangle_count: submesh.triangle_count,
                })
                .collect(),
            triangles: rerecast_navmesh.detail.triangles.clone(),
            vertices: rerecast_navmesh.detail.vertices.clone(),
        }
        .into(),
    }
}

Running when Asset<bevy_rerecast::Navmesh> was LoadedWithDependencies 🙂

[sleek scarab]

Also added comments about winding order

[mellow mirage]

The default debug stuff isn't very configurable. But you can honestly just fork it and not render the gizmos

It's not very complex code iirc

[sleek scarab]

Mind if I just add it to the same detail mesh PR?

(configuration, not deletion :D)

Oh, the code works perfectly when editing the mesh from the editor btw 🙂

landmass nicely uses the new navmesh when the editor saves it to disk because the code I wrote runs when the asset is loaded

[mellow mirage]

I'd prefer that as a separate PR

[sleek scarab]

Alright, I'll do that after the detail stuff is on main then 🙂

From my humble user-perspective, I think you can merge the detail stuff onto main

Your pathfinding is working great in Foxtrot 😄

No more stair problems

Thanks again for creating landmass, it's working soooo nicely together with rerecast

[mellow mirage]

I think I agree? I need to do one more pass to make sure I'm not forgetting something

[mellow mirage]

Haha thank you for actually integration testing everything AND making rerecast haha, I just hope I can implement everything you need to take advantage of rerecast 😄

[sleek scarab]

I wonder if splitting a navmesh into islands should be rerecast's or landmass' job

I'm tending towards rerecast

Assuming by "island" you mean "disconnected area" in landmass

[mellow mirage]

Not quite, island is closer to "chunk" or "tile"

[sleek scarab]

Oooh I see

Well then I'll need to implement tiling first 😄

I've been lazy with that because the tile-less approach is surprisingly fast for my use-cases

[mellow mirage]

Very understandable!

[sleek scarab]

Also, is there a way to easily do portals / off-mesh connections?

I think that would be the pathfinding library's job

Maybe by reading a component somewhere on the world that has a relationship with another entity?

[mellow mirage]

No there isn't yet. It's this issue https://github.com/andriyDev/landmass/issues/7

[mellow mirage]

Definitely pathfinding's job haha

[sleek scarab]

That way I could easily add them over the level editor

[sleek scarab]

got it 🙂

[sleek scarab]

I suppose I would need to wait for that for ladders too, right?

As in, a 3D ladder that goes straight up

Well, maybe a 10 degree tilt

[mellow mirage]

Yeah there's no way to do that today

Hahaha you could indeed have a super steep ladder LMAO

[sleek scarab]

just set the max angle to 90 degrees on that tile specifically

Francois is planning on adding further first-party support for rerecast navmeshes to vleue_navigator

Wonder what the implication on https://github.com/andriyDev/landmass/issues/121 is

Since in principle, the two plugins could just share the same bevy_rerecast::Navmesh

[mellow mirage]

I think the only reason this issue existed was because vleue_navigator was for its nav mesh generation

If vleue starts using rerecast, I don't see a reason to integrate that

[sleek scarab]

Yep. It was also about 2D support, which rerecast supports, you just need to write a backend that extends the Vec2s to Vec3s.
Which takes about 50 lines of code, backends are really simple to write 🙂

Pasted my code here so it doesn't get lost: https://github.com/andriyDev/landmass/issues/131

[sleek scarab]

I'm afraid that merge did not go as planned :p

[mellow mirage]

AHHHH

I COOKED YOUR BRANCH

HOLD ON

Uhhhh wtf now I don't have permissions

[mellow mirage]

I am so sorry D:

Oh because I accidentally killed all your commits, so that auto closes the PR

[sleek scarab]

phahaha

[mellow mirage]

@sleek scarab here's the commit hash for your branch 6f84711753376a881f4f56cb6b53dc5b665d0e1c

[sleek scarab]

You un-hohenheimed landmass

[sleek scarab]

Feels like you're handing out a receipt lol

[mellow mirage]

MY DUMBASS THOUGHT git push -u jan detail WOULD PUSH MY CURRENT BRANCH TO jan/detail 😠

[sleek scarab]

phahahaha

Do you need me to upload anything again?

I have it all local

[mellow mirage]

One sec

Let me revert the commit on my branch that caused the merge conflict

[mellow mirage]

Alright, can you send another PR?

So sorry about that

[sleek scarab]

haha no worries, been there

[mellow mirage]

Oh and just PR main eh?

[sleek scarab]

hold up

did you commit on my fork?

alright, let me force push

https://github.com/andriyDev/landmass/pull/133

there we go hahaha

I can fix the merge conflicts, sec

[mellow mirage]

Yes, I thought "oh I'll just go to your fork, remove the merge, and then I can merge it correctly". But then I replaced your detail branch with my detail branch instead of your fixed branch

[mellow mirage]

I think this just needs a rebase

[sleek scarab]

[sleek scarab]

Oh I'll leave it to you then

[mellow mirage]

AHHH I'M SCARED NOW

I'll give it a try lol

[sleek scarab]

phahahaha

It's still intact locally, I can always force push it again 😛

Or wait, I'll also push a detail-bk branch

there, now it's doubly safe 😄

[mellow mirage]

THERE WE GO

omg

Alright now I never touch your repo ever again

[sleek scarab]

hahahaha

wanna do a 0.4.1 release?

Oh wait your structs are probably not #[non_exhaustive], so this is breaking

[mellow mirage]

Yup this is breaking

[sleek scarab]

I can depend on the git repo, no problem

[mellow mirage]

I'm gonna grind out some changes first, starting with making you generate CCW nav meshes 😛 (so lock down your rev hash)

[sleek scarab]

Now I can finally go back to annoying you with non-navmesh-related bugs lol

[mellow mirage]

With rerecast, this is fixable on your end. Whenever a physics object gets frozen, rebake the nav mesh

I read through the hole cutting blog you sent a while ago, and it seems like their solution is mostly to let recast deal with it

[sleek scarab]

oh right, I remember

[mellow mirage]

I do wish I could fix this on my end, but alas

[sleek scarab]

but the API is in detour, isn't it

[mellow mirage]

I think Detour orchestrates the hole cutting? My understanding is they store the heightfields or something, and then just updated the polygonization. Something like that

[sleek scarab]

that's probably a good incentive to implement tiling haha

[sleek scarab]

aaaah alright

Yeah I could probably port that part too

[mellow mirage]

I mean if it really is fast enough, you might be able to get away with literally regenerating the whole map?

[sleek scarab]

Honestly, probably

[sleek scarab]

This is the speed we're talking about

[mellow mirage]

Lowkey that might be fine? I think it's fine if physics objects take a while to settle

[sleek scarab]

just need a good heuristic because there's always something moving and freezing on the map if we regenerate the whole thing

so I'd queue a new build every frame

which is fine, as a running navmesh regeneration will not be overwritten when kicked off again

So it will in effect just produce as many navmeshes as possible, no starvation there

But probably doing one every 200 ms is good enough

[mellow mirage]

https://github.com/andriyDev/landmass/pull/134 is merged. So flip all your stuff!

[sleek scarab]

on it

Got this for you in the meantime: https://github.com/andriyDev/landmass/pull/135

I would have preferred to do it like Avian and have navmesh: Option<Color>, but the current bevy-agnostic draw stuff you do makes that hard

Sec, let me also add an agent field

[sleek scarab]

Update your docs!

https://github.com/andriyDev/landmass/blob/da0684c4998ce2761cc904880b1e60e763c76e23/crates/bevy_landmass/src/lib.rs#L392

dunno what you mean by this

I'm fine with only changing the Bevy-facing API (since I only use Bevy), but I don't know what exactly you mean

ah wait

I think I got it

[mellow mirage]

Fixed haha

[sleek scarab]

Can I rename LandmassGizmoConfigGroup to LandmassGizmos while I'm on it?

Parity with how Avian styles it

[mellow mirage]

Yeah sure!

[sleek scarab]

nice

I'll add color configs to all current colors while I'm on it

/// A config group for landmass debug gizmos.
#[derive(Reflect, GizmoConfigGroup, Debug, Clone, Copy, PartialEq)]
pub struct LandmassGizmos {
  // points
  pub agent_position: Option<Color>,
  pub target_position: Option<Color>,
  pub waypoint: Option<Color>,

  // lines
  pub boundary_edge: Option<Color>,
  pub connectivity_edge: Option<Color>,
  pub height_edge: Option<Color>,
  pub boundary_link: Option<Color>,
  pub agent_corridor: Option<Color>,
  pub target: Option<Color>,
  pub waypoint_line: Option<Color>,
}

fine like this?

Not quite sure what to put in the docs other than repeating the name 👀

[mellow mirage]

/// The color with which to render agent positions. If [`None`], agent positions are not drawn.

Something like that please

A little verbose, but I don't want None to seem like "default"

[sleek scarab]

/// A config group for landmass debug gizmos.
#[derive(Reflect, GizmoConfigGroup, Debug, Clone, Copy, PartialEq)]
pub struct LandmassGizmos {
  // points
  /// The color to use when drawing an agent's current position. If [`None`], agent positions are not drawn.
  pub agent_position: Option<Color>,
  /// The color to use when drawing an agent's target position. If [`None`], target positions are not drawn.
  pub target_position: Option<Color>,
  /// The color to use when drawing waypoints along a path. If [`None`], waypoints are not drawn.
  pub waypoint: Option<Color>,

  // lines
  pub boundary_edge: Option<Color>,
  pub connectivity_edge: Option<Color>,
  pub height_edge: Option<Color>,
  pub boundary_link: Option<Color>,
  pub agent_corridor: Option<Color>,
  pub target: Option<Color>,
  pub waypoint_line: Option<Color>,
}

[mellow mirage]

Yup, looks good!

Uhhh

Wait can we add color suffix to each

Oh wait

Nah let's not

I was thinking if we wanted to add size or something

But if that were the case we'd house those options in a struct

LGTM

[sleek scarab]

great, let me wire this up real quick

[mellow mirage]

Just make sure those doc comments are <80 columns or else my format should complain lol

[sleek scarab]

It's in the rustfmt.toml, so it should autoformat for me 🙂

[mellow mirage]

You need nightly though for it to work though so it might not be automatic

(I have my vscode configured to always use nightly rustfmt lol)

[sleek scarab]

I'm always on nightly

[mellow mirage]

ahhh ok awesome haha

[sleek scarab]

(in fact, stutterless wasm audio requires nightly, so I don't really have a choice anymore lol)

@mellow mirage check the PR again

How do you like to document breaking changes?

[mellow mirage]

Currently I don't 😅 I don't know what a good mechanism for that is.

Maybe just a changelog md is good enough...

[sleek scarab]

yeah probably. Or add a PR template with a "added" and a "migration" section 🙂

[sleek scarab]

That way contributors don’t forget to list their changes

When you make a new release, you can then just go through the PRs of the release and copy-paste them into the changelog

[mellow mirage]

That part I feel ok about enforcing myself

I just need a pattern to stick myself to lol

[sleek scarab]

Hehe

Can confirm gizmos are working as intended

Also, do you maybe want to disable CodeCov?

I feel like it's failing on almost every PR haha

[sleek scarab]

Added a "Changelog" and "Migration" section to the PR so you can use that later

[mellow mirage]

noice

[mellow mirage]

No I want to keep it. Let me see if I can make it more reliable

I think I might have it configured wrong lol

[sleek scarab]

Implemented add_triangle for good measure 🙂

It's not as nice as having a filled-in triangle by creating a mesh, but eh

Not opening that can of worms haha

[mellow mirage]

Is it providing good visuals? It seems like it might just be a jumbled mess without the fill?

[mellow mirage]

Pretty sure I fixed codecov now, it's actually showing a redacted token now lol

[sleek scarab]

looks completely fine

Whether its useful or not is imo not a question of the drawer, but of the drawn feature

It's probably good to leave it at None by default

but IMO if there are debug drawing calls for it, it feels silly not to offer the gizmo

[sleek scarab]

hehehe

[mellow mirage]

Ok sure, if we're gonna default it to None, I'm down

[sleek scarab]

(note, the fill is from rerecast ofc)

Then my PR is done 🙂

[mellow mirage]

Debug now renders the paths the way they are computed - we navigate through the center of edges, not through the center of nodes

For context, here's what debug view looked like before

(that's also how it used to be computed, which gives an indication of why landmass use to give bad paths in some situations.

[sleek scarab]

Yeah this is much much better 😄

Oh btw, you may care about this regarding polyanya-landmass parity

Polyanya currently expects all polygons to be planar, but rerecast generates aplanar polys. It should be mathematically possible to deal with this, but until that is done, polyanya just uses the detail mesh for pathfinding when available. Meaning that for rerecast purposes, polyanya just uses triangles for everything.

So I believe landmass and polyanya probably generate fairly similar results? Not sure

[mellow mirage]

polyanya will generate better results overall. The way the A* in landmass works it always goes through the edge center. polyanya on the other hand keeps track of the "cone" that the edge is visible through.

Effectively they are doing the "string pulling" while doing the A*

[sleek scarab]

Aah got it

[mellow mirage]

So they are actually computing the straight-line path while navigating and optimizing that

[sleek scarab]

Makes sense 🙂

[fast pawn]

I'll soon remerge the planar triangles, it's fairly easy to do, just a pain to check that all the indexes are updated correctly. luckily it panics very fast if it's not right 😄

❤️ panics

I already have a function that merge polygons by checking each polygon with its neighbours if it's convex, I'll reuse something similar but driven by the already defined group of triangles from the poly mesh

[mellow mirage]

@sleek scarab https://github.com/andriyDev/landmass/pull/141 wdyt

Not the standard changelog format, but I like Bevy's split of "release notes" / "migration guide". Makes it a clear separation between "using the shiny new stuff" / "bare minimum to make it work"

[sleek scarab]

I like the same format as you describe 🙂

[sleek scarab]

Looks good, also add the blurb I had in the gizmo PR description 😉

Ah wait, you did

Just not the migration part

[mellow mirage]

OHHH I'm dumb I thought it was new, but it's actually renamed haha

I will fix that and mix in more of your description

Thank you!!

[mellow mirage]

@sleek scarab https://github.com/andriyDev/landmass/tree/rerecast Partially done. Still needs an asset loader, and an example to test it all out, but alas it is bed time

Oh and at least some testing.

[sleek scarab]

Oh wow, this is great news 😄

Curious what you want an asset loader for

Do you want to load .nav files directly as landmass navmeshes?

I didn’t consider that, but that’s actually pretty smart, and super nice for the user 👀

[sleek scarab]

Hmm looking at the code, wouldn’t it be perhaps easier to accept a user provided Handle<bevy_rerecast::Navmesh> on an island, that is then converted to a Handle<landmass::NavMesh> when the resource is (re)loaded

The current wrapping API makes it more time intensive to update landmass_rerecast, as every change in bevy_rerecast needs to be mirrored

[mellow mirage]

Yup exactly. The loader will just wrap your loader and then do the conversion in the loader instead of after

[sleek scarab]

Clever!

[mellow mirage]

Oh interesting. That's also an option! I'll have to think about this.

I'm a little worried it's gonna be harder to juggle the handles correctly, but I'll give it a try

Oh here's a concern, there's no place to put the type index map. I guess you could register the type index map for a specific handle, but that seems a little gross... You'd need to call generate, then register the type index map, then insert the handle on the island.

If we made the type index map a component, we'd have to dedupe them when converting rerecast to landmass

Maybe the answer there is to make the type index map a component in bevy_landmass too though. It's already difficult to set that correctly from a loader anyway...

[sleek scarab]

Sorry, what’s a type index map? 😄

A map from area IDs to costs?

If so, I'm open adding something like that, sure!

[mellow mirage]

Ehhh not quite haha, it's a map from area ID to node type. There's a separate map from node type to cost, that way agents can have different costs for the same node type

[sleek scarab]

Oooh gotcha

Wonder if the user flags could serve that purpose? Probably not

Anyways, if it helps adoption, I'm happy to make it an optional field on Navmesh 🙂

[mellow mirage]

Nooooo definitely not. I'm currently wondering why I should bother with a node type and why not just use the raw type indexes. Leave it to the user to manage correctly...

[sleek scarab]

Seems perfectly fine too

[sleek scarab]

Though about this some more and yeah, I think just using the indexes is good enough. The user has enough data to build their own abstractions on top.

[mellow mirage]

Yeah it's basically just some juggling the user has to do. The initial motivation was so that your type indices didn't have to be consistent globally when loading the nav mesh. So like, if you had a city mesh with roads, you could say 1=road, and is you have a cave mesh, you could say 1=rock. Then when you load up those meshes, you'd register those types and they will be mapped to be distinct

[sleek scarab]

Makes sense

[mellow mirage]

But like, this seems like way too difficult of a solution, when a user could just do that conversion themself.

[sleek scarab]

And since the user has access to the rerecast mesh, they can just change the areas how they want

[mellow mirage]

At load time, pick a random number to act as road, and another random number to act as rock

Anyway, this is already on main haha

I'll see how this change makes me feel about the rerecast integration

(once I rip out the node type stuff)

I think I'm most concerned about having to deal with the lifecycle of the navmesh handles

Like your island will now have two nav mesh handle components: one for the rerecast mesh and for the landmass mesh

And now I need to make sure to delete that landmass mesh handle component if you delete the rerecast mesh handle component

Maybe that's just one observer though so perhaps it's not a big issue lol

[sleek scarab]

Yeah that’s what I'd do

And then update the landmass asset when the rerecast asset is reloaded

I think that’s enough

The navmesh is twice in memory, but these meshes are fairly small, so I think that’s alright

If the user cares, they can just manually convert the rerecast mesh to a landmass mesh

[mellow mirage]

Oh I've been removing the rerecast mesh when converting it.

[sleek scarab]

I wouldn’t

If you keep it, you can have hot-reloading

[mellow mirage]

I'm pretty sure even if you remove the asset, you still get hot reloading

[sleek scarab]

Oh, really?

Well, you would know better than me 😄

[mellow mirage]

I may be wrong but I don't think the assets impl cares, it just sees "this path has been changed, and there's a handle for this path"

I'll verify that before committing haha

[sleek scarab]

That would be really really nice

Landmass can have a very clean API

and very easy migrations

Which is imo even more important, otherwise it will just rot

Also, I think we could sunset the oxi_nav integration @near nexus

Rerecast still has no impl for tiling until I have time to port it, but given the performance of regenerating the whole mesh, it’s not really essential imo.

[mellow mirage]

The thing I like about the wrapping API was that users never saw the rerecast handle, so they never had the chance to be confused by two types of nav meshes, and if I remove their rerecast mesh, they won't miss it because all they'll see is the landmass mesh

But you're right, the cost is the ease of migrations

[mellow mirage]

Seeing as how oxi nav hasn't published an 0.16 version, I think that's correct

[sleek scarab]

Yeah in a perfect world I would also wrap everything. It’s your migration pain, so your choice, but I wouldn’t recommend it.
Plus, I'd like to upstream bevy_rerecast_core eventually, which would make it alright to leak the rerecast types

[near nexus]

I agree. It's served it's purpose and Rerecast is quickly surpassing it 👍

Again, fantastic work

[sleek scarab]

Thanks! I cannot stress enough that I would not have been able to do this without building on your previous work

https://github.com/andriyDev/landmass/pull/145
wink wink nudge nudge

[mellow mirage]

Thanks haha, I just gotta test this every now and then

Hopefully it gets fixed soon

Hopefully we're not the only ones with issues 😥

[sleek scarab]

When I ran into it the other day a quick google told me that no one reported it yet

[sleek scarab]

Eh I'm not sure how valuable
I think there's zero value

It just annoyed me that the matrix was missing an entry for nightly hahaha

sec, doing a bug report

(on Bevy)

[mellow mirage]

Oh awesome thank you!!! This conversation was gonna make me do it tonight haha

Alas it is time for work and I'm sooooo late

[sleek scarab]

have fun 🙂

[sleek scarab]

Some notes on the branch:

• Mind switching rerecast_to_landmass out for an impl From<RerecastNavmesh> for bevy_landmass::NavigationMesh3d? If you do, I could already depend on it in Foxtrot to help test it.
• We could also have a 3D and 2D variant of the integration crate, given that there is interest in generating 2D navmeshes. bevy_rerecast doesn't have a 2d and 3d split because it has no reason to do so; just set one dimension to 0. But given that landmass uses a 2D / 3D split, we should imo be able to generate both from a rerecast mesh, again by just throwing away one dimension. The settings tell which axis is up, so it can be used to know which dimension to discard 🙂

[mellow mirage]

Oh

I just realized a height mesh makes no sense for 2d

But I don't have this skipped for 2d in any way...

I guess there's not much I can do there though.

[sleek scarab]

BTW the new debug visualization for the purple line is looking nice!

[mellow mirage]

I'm down to make the conversion function public, but I don't think I wanna make it a From impl. From is for when the conversation is lossless, but I throw out rerecast data like user flags

As for 2d, I'll keep it in mind when implementing the integration crate. I don't think we need separate crates for 2d vs 3d

That said, I really think rerecast is the wrong implementation for 2d? You can probably strip out so much from rerecast and simplify a lot of its internal DSs

Like you probably still want rasterization, but that math could be much simpler. You don't need any span business. You still could use partitioning, and turning that into polygons.

Maybe all that doesn't matter though, it's probably not a big performance concern in 2d

Just seems wasteful haha

[sleek scarab]

oooh fair point, yes

[sleek scarab]

Navmeshes are preauthored anyways, so it doesn't matter

I guess highly dynamic 2D games with a big map and lots of obstacles would want something custom

[mellow mirage]

I am definitely more focused on dynamic games haha, you're totally right that for preauthored nav meshes, just let the computer whir

[sleek scarab]

@mellow mirage could you help out @hybrid fog ?

https://github.com/andriyDev/landmass/issues/131#issuecomment-3191208243

[mellow mirage]

Just woke up haha, looking!

Thanks for responding to them!!

[mellow mirage]

@sleek scarab https://github.com/andriyDev/landmass/compare/main...rerecast2

I tried your API and I think it'll work well too

Island3dBundle, NavMeshHandle3d and NavMeshHandle should all be manually imported, and then they'll effectively shadow bevy_landmass

[sleek scarab]

Aaah Weak<StrongHandle>, our good friend

[sleek scarab]

oh that's a really good idea 😄

Didn't think of that!

[sleek scarab]

what is my API?

[mellow mirage]

I need a boatload of tests, an example and a README, but then I'll be ready

[sleek scarab]

The one about using rerecast handles on islands?

[mellow mirage]

The "don't wrap rerecast"

[sleek scarab]

ah gotcha

Yeah this seems way more maintainable!

[sleek scarab]

that's cool 😄

[mellow mirage]

There is a bit of sadness where we now can't load the landmass mesh directly from rerecast files - the disadvantage being that we'll be doing the conversion during a game frame

[sleek scarab]

@fast pawn you may be interested in this, since you're also thinking about having more rerecast integration options

[sleek scarab]

Hmm fair point

I think that should be fairly inexpensive

But I haven't benched anything

[mellow mirage]

Yeah almost definitely not a big deal, but it makes me wish it could be different haha

[mellow mirage]

@sleek scarab btw https://github.com/janhohenheim/rerecast/pull/25 is stuck

Looks like it's just the nightly stuff that's broken 🙁

[mellow mirage]

Ooof I also just realized the rerecast has an entirely different meaning of "area type" compared to landmass...

Areatype in rerecast is a bitmask, whereas its an index in landmass

[sleek scarab]

It’s an index in rerecast too

Did I make it a bitflag? Whoops

[mellow mirage]

It's a bitflag in original recast iirc

It's really just a choice of vision, I guess recast nerds view it as a bit flag of "I can walk over this, I can swim over this, I can skateboard over this, etc", I'm viewing it more like "this is grass, this is road, this is lava, etc"

As long as your area type stuff has a "set" operation as opposed to bitwise OR / bitwise AND, I don't think it's a significant issue.

[sleek scarab]

Oh lol I didn’t even realize

[sleek scarab]

Yeah the thing is, no one is doing area types anyways since we have no way to paint them yet 😄

[mellow mirage]

Oh LMAO then we're all set hahaha

[sleek scarab]

I mean there is in API, but no way to artistically control that visually

I wanted to add a simple version to the editor but didn’t bother yet because it involves mesh picking through a backface culled portion of the same mesh and that sounds scary

[mellow mirage]

Oh I would still consider that valid

[mellow mirage]

I actually didn't have a problem with that EXCEPT for "stray geometry"

But that's a texturing problem maybe

[sleek scarab]

Ha, good to know

The ultra simple API is not even texturing, it’s just you drawing a polygon where you want the region to be

[mellow mirage]

Oh all I meant was it was hard to see what I was clicking on because it was all white 😅😅

[sleek scarab]

Aaaah got it haha

[mellow mirage]

@sleek scarab you've heard of "which direction is forward", now get ready for "which order is clockwise" 😅

bevy_landmass on main currently treats a polygon as counter-clockwise if its vertex coordinates follow the right hand rule. rerecast on the other hand treats a polygon as counter-clockwise if the XZ of the coordinates follow the right hand rule. Turns out, this corresponds to clockwise oriented polygons by bevy_landmass's definition

The solution to this is reversing the coordinates during the conversion from rerecast to landmass, which I can do.

Just wanted to make you aware of this weirdness I guess

[mellow mirage]

Also example has been recreated. I decided to strip out moving the camera and just keep it fixed.

[mellow mirage]

https://github.com/andriyDev/landmass/pull/146 It's ready 🙂

[mellow mirage]

barring the ack of this

[sleek scarab]

[sleek scarab]

Why do you say that rerecast treats them as counter-clockwise? I changed the docs to say that the polygons and tris are always clockwise

[mellow mirage]

Oh? Is that version released?

(totally fine if not)

[sleek scarab]

Should be

0.1.1

If I didn’t accidentally write something wrong 😄

[mellow mirage]

bevy_rerecast_core is on 0.2.0

[sleek scarab]

Those docs are on rerecast

[mellow mirage]

https://docs.rs/bevy_rerecast/latest/bevy_rerecast/rerecast/struct.PolygonNavmesh.html#structfield.polygons

Maybe this doc was missed haha

Or I am misunderstanding this doc

[sleek scarab]

Oh wow yes this is exactly the doc 👀

Whoops

My bad haha

[sleek scarab]

Exactly the *wrong doc

[mellow mirage]

LMAO npnp

[sleek scarab]

Will fix later, thx

[sleek scarab]

Oh hey I know that scene 😉
Make the light a liiiittle bit orange to make it look less clininal

[mellow mirage]

Hahaha ok you got it

Hopefully slightly less awful

oh wait

I have night light on

Nah I think that's the right color lol

[sleek scarab]

Better 😄

[sleek scarab]

Initial review: mind replacing bevy_rerecast_core with bevy_rerecast in user-facing docs?

The split there is only so that upstreaming into bevy is easier

But users should not care about that detail

[mellow mirage]

bevy_rerecast is primarily for the editor, yeah?

[sleek scarab]

it just reexports core and the editor integration

If you don’t need the editor, you can just disable that feature

[mellow mirage]

Oh this is awkward, the docs won't link to bevy_rerecast because it's not a dependency...

[sleek scarab]

Heh

[mellow mirage]

I guess I can make all my Navmesh links manually link it to core?

[sleek scarab]

You can depend on bevy_rerecast with default features disabled

[mellow mirage]

hmmm

Bleh, ok

But alas I will do this tomorrow since it's 1 am

[sleek scarab]

Fair 😄

I'll patch foxtrot to your branch later to see if it works

Good night 🐑

[mellow mirage]

Awesome!! And thanks haha

[unreal rover]

Curious why it should be clockwise? Afaik counterclockwise is the standard for stuff like triangle meshes for determining which side is the front face

[sleek scarab]

Because that’s what recast does

Agreed that CCW would be better

But this is not a choice I have; rerecast (at least right now) produces exact matches of recast

Since Godot uses an unmodified Recast, I wonder if they convert it to CCW before showing it to the user

[unreal rover]

Fair, I guess it's good to match it at least for the core rerecast crate

[sleek scarab]

Unity and Unreal are both using Recast forks, so I imagine they may have changed the winding order

[unreal rover]

we can make rererecast that is a modified version of rerecast

[sleek scarab]

Hehehehhe

I have at least one place in the code where I am 90% certain the original has a bug

It compares a length to a squared length

(In other places, it’s always compared to lengths, not squared lengths)

I’ve just commented it for now

And added an issue to the original, but the author is not very active

Which is good, since it means we probably never need to touch rerecast to update it 😄

[sleek scarab]

@mellow mirage I'm using your branch and everything related to it works, but...
The API seems easiest to use in my case by scoping the archipelago and island to my level, since another level would presumably want a different archipelago + island.
Trouble is that when the level is reloaded, landmass kinda doesn't use the island? This is not new to your branch, this happened before. I just ignored it because I manually updated the island as necessary instead of scoping it to the state.

As you can see, the island and archipelago are present in the world when the level is reloaded

Here's the relevant code: https://github.com/janhohenheim/foxtrot/pull/426

If I hack the system with a Local<bool> to only spawn the archipelago / island once and don't state-scope them, it works, FYI

Is there something I have missed that is needed to "properly" despawn an archipelago / island?

Or am I supposed to never ever despawn the archipelago and just mutate when spawning a new level?

[mellow mirage]

Ooof this is definitely not intentional

You should totally be free to spawn a new archipelago and island

Oh dang, maybe it's because I've consumed the navmesh to create the landmass version, but then since we drop the landmass handle but NOT the rerecast handle, it never reloads

I think this is just an issue with landmass_rerecast

Oh I bet this also breaks if you use the rerecast mesh in two islands and then drop one lol

[sleek scarab]

I had something similar even when I was building the landmass navmesh manually on main, so I'm not sure

Could be unrelated though

[mellow mirage]

Landmass doesn't use any resources iirc so if you're deleting the entities, all that state should go with it. The only exception are the navmesh assets

[sleek scarab]

yeah I checked the source I don't know what it could be either

[sleek scarab]

Whoops I take it back

This bug doesn't happen when using just bevy_landmass

I had it happen with the old oxi_nav code (according to my comments)

maybe that helps 🙂

[mellow mirage]

Huh ok. Maybe my oxi nav integration was also broken? Lol

[sleek scarab]

Well most Bevy games are not on the scope of "multiple levels", so it makes sense no one noticed 😄

[mellow mirage]

Please pull and retry! Should be fixed now 🙂

I haven'

t gotten to your feedback on the PR yet and I need to leave for a bit but I will get that done tonight

[sleek scarab]

yeeeesssss it works 🎉🎉🎉

thanks for looking into it!

[mellow mirage]

Thanks for testing it! Nice to finally have a full navigation stack haha

[hybrid fog]

Greet job 🎉 🎉 🎉

[hybrid fog]

At the end of slope, agent not work, say AgentNotOnNavMesh. Do I need to upgrade bevy_landmass to github main branch?

[mellow mirage]

Your agent should be positioned at the feet, or alternatively change the PointSampleDistance3d to change the distance above and distance below

I might have those values set too strict

https://docs.rs/bevy_landmass/latest/bevy_landmass/struct.AgentOptions.html#structfield.point_sample_distance

[hybrid fog]

thanks, adjust PointSampleDistance3d make it works.
And another question, has some way to block left slope navigation one side on ground to top?

[mellow mirage]

Uhhh I'm sorry I am not understanding your question 😅

[mellow mirage]

Are you asking how to prevent the navigation mesh from being created on the left slope?

[hybrid fog]

Yes,
Question 1: How can I prevent the navigation mesh from being created on the left slope? Should I use an invisible mesh?
Question 2: Is it possible to create a navigation mesh that prevents an agent from going through the left slope when it is on the ground, but allows the agent to go through the same slope when it is on top of the platform?

[mellow mirage]

1. I think you can tinker with some of the nav mesh settings in rerecast. walkable_slope_angle and walkable_climb might help, and maybe cell_size and cell_height could be used so the voxelization can better represent your geometry (I would start with the first two though)
2. Unfortunately there's no way to do this right now. This is known as off-mesh links https://github.com/andriyDev/landmass/issues/7 . It is something I want to implement eventually

[mellow mirage]

I was hoping to crush this out this past weekend, but I've been working on animation links aka off mesh links.

I've got a bunch of the pieces ready (for raw landmass). I mainly just need to figure out how to assign the portal of an animation link to the nodes in the navigation mesh. The other thing I need to decide on is the API for when the user should take an animation link, when they're *taking" a link, and when they're done taking a link. But that's all stuff I can change easily later.

[sleek scarab]

Exciting!!!

[mellow mirage]

Ugh annoyed... I can't figure out how to assign the portal of the animation link. Projecting an edge onto a node is hard...

So I'm gonna cheat and only support animation links between points

I really wanted to have animation links for an entire edge so the agent could dynamically pick where along the edge they run the animation...

The really sad part is that means that agents could get "locked in" to using a link, resulting in a crowd fighting over taking a single animation link and not willing to repath

[sleek scarab]

Maybe Detour has something you could use as inspiration?

[mellow mirage]

It looks like Detour also only does point-to-point animation links https://recastnav.com/structdtOffMeshConnection.html

[sleek scarab]

Ah heck

[mellow mirage]

huhhh now I think I'm going crazy. Unity also only seems to have point-to-point...

I swear there was a navigation system with edge-to-edge...

I guess I'm gaslighting myself?

Welp that makes this much easier to reach parity with these engines...

[mellow mirage]

I'M NOT CRAZY https://docs.unity3d.com/560/Documentation/Manual/class-NavMeshLink.html

[mellow mirage]

Just to give an update, I've got the links all generated - both point and edge links! So the biggest question marks are handled.

Now I just need to figure out some API details with how to actually communicate that you need to take a link somewhere on a path, and we should be good to go!

The other API question I don't know how to handle is how to let users specify the allowed vertical distance between the animation link and the nav mesh, since obviously that option doesn't make sense for 2d.

I might just rename AgentOptions to ArchipelagoOptions there and then stick this in with PointSampleDistance... Kinda ugly but whatever

As an aside, in the future I want to separate all the coordinate system conversion stuff from the core landmass stuff. So there'd be a CoreArchipelago that would just be all the data in the standard landmass coordinate system, and then Archipelago<CS> would be a wrapper around the core archipelago. That would also help some weirdness happening in bevy_landmass, which could reimplement its own interface directly on top of CoreArchipelago which would store more stuff in the ECS I think.

And it would help compile times since very little would be generic!

And landmass internal tests would be easier to write lol

But that comes after animation links

[mellow mirage]

Alright, I'm finally at a state where landmass is pretty much done. There are some pieces I have skipped because I'm lazy, like that ArchipelagoOptions change, configuring which link types an agent is allowed to take, and maybe also bidirectional animation links. But before all that I'm gonna update bevy_landmass to expose them, and then make a (3d) example for them so I can see it for real.

If I'm intensely lucky, all my unit testing actually results in real expected behavior haha

[sleek scarab]

Oh wow that is huge 😄 congrats!

[pearl path]

woo congrats I've been following your project

[sleek scarab]

@mellow mirage any idea why my friend here is slowing down when close to the wall?

I use the same radius for the navmesh, the collider, and the agent settings

https://github.com/janhohenheim/thief_sense_demo

This is using landmass main FYI

Increasing the radius of the character for the navmesh and the agent settings seems to help a bit?

[mellow mirage]

Something looks kinda weird there, why do they give such a wide berth to the corners?

[sleek scarab]

You mean the navmesh?

That's just an artifact of the cell resolution

this is with a higher resolution

[mellow mirage]

No I'm talking about the corners of the navmesh

[sleek scarab]

That's also just a setting

[mellow mirage]

They're normally supposed to walk along the edges of the nav mesh

But your agent looks like it's offset from them or something

[sleek scarab]

Maybe the collider is colliding with the wall?

Let me increase the agent radius by a lot for the navmesh

[mellow mirage]

Could you also reduce their speed?

Just so I can see in finer detail lol

Though I guess this could be a high speed problem

[sleek scarab]

how he's wiggling 👀

This is the setup:

commands.spawn((
    Name::new("NPC Agent"),
    Transform::from_translation(Vec3::new(0.0, -NPC_FLOAT_HEIGHT, 0.0)),
    Agent3dBundle {
        agent: default(),
        settings: AgentSettings {
            radius: NPC_RADIUS,
            desired_speed: 5.0,
            max_speed: 7.0,
        },
        archipelago_ref: ArchipelagoRef3d::new(*archipelago),
    },
    ChildOf(npc),
    AgentOf(npc),
    AgentTarget3d::default(),
));

take a peek at https://github.com/janhohenheim/thief_sense_demo/tree/main/src/demo/npc

it's not much code

[mellow mirage]

Yeah been looking at that

[sleek scarab]

some more interaction in case it helps

want me to slow the NPC further down?

[mellow mirage]

Yes please, but with the nav mesh radius turned back down to the original

I am also building it locally so I have more control lol

[sleek scarab]

do a git pull now

made the navmesh the correct size again

here's a slower controller

[mellow mirage]

Hmmm hard to see this problem now. I guess it's only a high speed problem...

[sleek scarab]

it's more visible in a maze

[mellow mirage]

For some reason it's directional

Maybe that's just because of the angles though...

Definitely not a high speed problem though

[sleek scarab]

aah you mean because the navmesh doesn't have 90 deg angles there?

[mellow mirage]

As in the path from the bottom right to the top left has the "next edge" at a shaper angle than the path from the top left to the bottom right

[sleek scarab]

let me know if there's anything I can do to help debug this

[mellow mirage]

I think for foxtrot I told you to normalize the desired velocity

Which was a hacky fix to this

[sleek scarab]

Oh really? I completely forgot about that

You mean here?

fn set_controller_velocity(
    mut agent_query: Query<(&mut TnuaController, &Agent)>,
    desired_velocity_query: Query<&AgentDesiredVelocity3d>,
) {
    for (mut controller, agent) in &mut agent_query {
        let Ok(desired_velocity) = desired_velocity_query.get(**agent) else {
            continue;
        };
        let velocity = desired_velocity.velocity();
        let forward = Dir3::try_from(velocity).ok();
        controller.basis(TnuaBuiltinWalk {
            desired_velocity: velocity,
            desired_forward: forward,
            float_height: NPC_FLOAT_HEIGHT,
            ..default()
        });
    }
}

that would break the speedup to evade others, right?

[mellow mirage]

Yes and yes

Which is why I need a proper fix here

[sleek scarab]

thanks for the tip, that hack works

[mellow mirage]

Ok I think I have a solution. I think I've been overcomplicating it, and I can implement it quickly

Oh maybe not hmmm it would help, but it wouldnt' solve it I think. Let me keep thinking

[sleek scarab]

here's a running dude to help thinking

look at him go

Not a single worry on his mind

[mellow mirage]

I don't understand... I can't reproduce this behaviour in a test env. I've tried reproing it in dodgy, landmass, and bevy_landmass, and they all produce the expected result.

The only thing I can think of left is it has something to do with a non-constant time in Bevy, but that seems crazy...

One thing that's really strange is I need to negate the Z coordinates in thief_sense_demo but not in my bevy_landmass test...

[mellow mirage]

Ah turns out that was just a change in my test. Fixed that but still can't reproduce the weird behavior in the thief demo

[sleek scarab]

Hmm weird, considering it’s a pretty simple setup

Is it maybe connected to the fact that I do the movement in fixed update?

[mellow mirage]

Perhaps?

Let me see if I can extract that info

That really shouldn't matter though. I think the worst case is that a couple frames get the same velocity, which should just result in the same desired velocity

Oh hmmm I guess I don't know how to get that info...

[sleek scarab]

Get which info?

[mellow mirage]

Ah nvm, I changed your thief example to do movement (both avian and tnua) in PreUpdate and it's still broken

[mellow mirage]

WAIT

I think I know what's happening lol

sync_agent_velocity isn't running, since no entity has LandmassVelocity and AgentDesiredVelocity

@sleek scarab Crispppp

I gaslit myself into thinking this was an issue in landmass lol

[sleek scarab]

Oh hecccccc sorry for the user error

[sleek scarab]

Beautiful, thank you so much

[sleek scarab]

Maybe that could go into an FAQ?

[mellow mirage]

Hahaha npnp

[mellow mirage]

Yeah that's a good idea. Just having a bunch of debugging tips like "check the agent state" is very useful

[sleek scarab]

Or maybe there could be a validation that the velocity is updated every now and then

[mellow mirage]

Yeah I was just thinking about adding a debug check for when the position is moving but the velocity isn't lol. Might have too many false positives though? Unclear

[sleek scarab]

We could add it and remove it again it people complain

Also should probably be a setting in a resource that defaults to true, so people can deactivate it

[mellow mirage]

I'll think about it. I guess doing it for just bevy_landmass is reasonable, though a little weird

As an aside, just migrated bevy_landmass to 0.17. Took 5m lol. Not surprised!

I'll need to wait for rerecast to be migrated anyway, but the main bottleneck there is probably waiting on avian

TIL the rerecast editor doesn't use egui and actually uses bevy_ui 🤯

I really need to push to finish off mesh links. I really want them in the 0.17 release, and I'd rather have one big version rather than two smaller releases.

I want beeeg release notes >:)

[sleek scarab]

Not really, the avian integration is intentionally a separate crate 🙂 the only bottleneck is my time haha

I'll port it tomorrow

[sleek scarab]

Yeah that can upgraded right away, and can then finally use bevy_feathers!

[sleek scarab]

Hehehe

[mellow mirage]

TAKE YOUR TIME NO PRESSURE hurriedly gets back to working on off mesh links

[sleek scarab]

phahahaha alright

Also need to migrate Yarn Spinner

The rest is trivial in comparison

Oooh and bevy_new_2d also wants feathers integration

https://github.com/andriyDev/landmass/issues/149

so we don't forget

[unreal rover]

I started migrating Avian yesterday, hopefully will have a PR ready later today or tomorrow

(just got sick though so I'm feeling a bit run down, but it's getting better)

[mellow mirage]

Now agents can yeet themselves 🙂

THAT ONE HAD AUDIO, AWKWARD

[mellow mirage]

Shocking nobody, I've found a panic lol

[mellow mirage]

Thankfully it was a simple fix. Hopefully it fixed it permanently lol

[mellow mirage]

I think I'm down to one thing left for animation links - I just need to provide a way to set the vertical distance allowed for animation links to their polygons.

[mellow mirage]

And just like that, we're done

[mellow mirage]

https://github.com/andriyDev/landmass/pull/150

[mellow mirage]

Now that's a PR

[sleek scarab]

Weeeee!

[sleek scarab]

Oh wow haha

[mellow mirage]

Now go get your ladders 😉

[sleek scarab]

This opens up a question: how do I specify the mesh links as a designer?

The original recast editor allows just clicking somewhere to create them

But adding that to the rerecast editor would tie it to landmass

But I like the idea of other pathfinding crates also being able to use it

Maybe I could write some metadata somewhere?

There’s a user-data field in the navmesh

Put IIRC it’s per polygon

So eeeh

[mellow mirage]

I don't have strong opinions here. Rerecast could also write a whole new file for the off mesh links, and then define its own notion of an animation link, then parse that in landmass_rerecast

[sleek scarab]

I'm open to that

[fast pawn]

how does the original recast editor saves them?

[sleek scarab]

@fast pawn I was just about to ping you 😄

[sleek scarab]

Whew no clue

[fast pawn]

well then do the same 😄

[sleek scarab]

Yeah good idea

The original editor is tied to a pathfinding lib

Detour

But I can just treat that as "here’s data any pathfinding lib could use if they wanted"

[fast pawn]

yup, then the parser are easy enough to write for each lib

either follow the same format as recast for something already explored, or create your own

[sleek scarab]

I'll check out how they do it

Thanks 🙂

[mellow mirage]

Does vleue_navigator have off mesh links?

[fast pawn]

not yet, but mostly because I had no idea how to create them without a mess in code 😄
and that blocked me from writing the impl, but (I think) I have all the building blocks already

if rerecast gives me link definitions I'll add them 🙂

[mellow mirage]

A lot of my time implementing was spent trying to take the link definitions and actually find where they projected on the nav mesh lol, especially since hand placed links are more likely to be vertically offset from the nav mesh 😅

[sleek scarab]

@mellow mirage rerecast migration is done FYI

I'm currently replacing the editor UI with upstream feathers

But the functionality is ported 🙂

[mellow mirage]

Awesome, I'll update my 0.17 branch to use updated rerecast

[mellow mirage]

Upgraded landmass_rerecast to 0.17 too 🙂

[sleek scarab]

heck yeah! thanks!

I'll do an RC release once I get this editor wrangled

progress:

[mellow mirage]

Oooooh nice!

Do you have a before screenshot?

Ah that's just this

Looks cleaner!

We love 🪶🪶🪶

[sleek scarab]

[sleek scarab]

done!

Alright, I'll fix some lints now and then release the RCs

[mellow mirage]

I'm probably not gonna publish RC versions since I want to keep making changes until the release 😛

[sleek scarab]

works for me 🙂

[sleek scarab]

published the RCs

@mellow mirage mind pointing the rerecast dep to the RC instead of the git branch?

Reason: I just deleted that branch and now my build is failing because landmass is looking for it lol

[mellow mirage]

Pushed

[sleek scarab]

thanks!

[sleek scarab]

Can confirm the landmass RC is working

[mellow mirage]

@sleek scarab you might have opinions here https://github.com/andriyDev/landmass/issues/159

[sleek scarab]

Didn’t read it fully, but doesn't this mean that asset hot reloading doesn’t work?

Like, when I overwrite my navmesh on disk using the editor

Will landmass pick up on that?

I thought it did

[mellow mirage]

I'm pretty sure it will! The asset system doesn't care whether the asset exists, it just sees "this path changed and this handle refers to this path"

[sleek scarab]

Ah, neat!

[mellow mirage]

This would also be broken for render assets only on the GPU if it were broken

[sleek scarab]

Was really questioning my memory for a second

Like, I could have sworn it worked haha

[sleek scarab]

Well that wouldn’t surprise me, GPU assets are usually broken in general

I tried making as many of my assets GPU-only as possible

Result: nothing

Not a single one is safe to be made GPU-only in practice

[sleek scarab]

I think that’s fine then?

Need to think this through

[mellow mirage]

They all need to be used on the CPU? That's surprising...

[sleek scarab]

But I don’t see an immediate issue

[mellow mirage]

I guess my main question is how much you intend for people to use rerecast meshes directly

As opposed to other crates turning them into their own representations

(like landmass now)

[sleek scarab]

Yeah. Meshes are needed to generate colliders and fixed skinned AABBs, UI images need don’t render when GPU-only, textures run into weird race conditions when combining different render features

Render folks say yeah, GPU-only is not tested that well outside of very simple scenarios

[mellow mirage]

Dang that sucks

[sleek scarab]

Uuuuh good question. I only assume that I can keep the handle, so that APIs like regenerate work. I believe even C++ Detour wraps the C++ recast navmesh in a custom representation, so I would say that is probably the usual path?