Foxtrot reference game

[trim lagoon]

Yes

[opaque sorrel]

That does seem a good way of doing it

[visual fiber]

hmm then it needs a ray cast, right? Since I can't really guarantee that the character is at the box's "feet" otherwise

I guess I could manually implement that my inserting NavMeshAffector once they stop moving and manually remove it once it starts again?

[opaque sorrel]

I could probably add this as well, as an optional component, I see the use

[visual fiber]

that'd be really cool 🙂

[trim lagoon]

IIRC as long as the character is within the agent's neighbourhood, it will avoid it

We only care about the feet stuff wrt path finding and waypoints - both of which don't apply to characters

[visual fiber]

While we are on it, NavMeshAffector currently needs to be on a collider, right? The thing is, while spawning things from a glTF, I need to set my components on the scene root, which is typically a rigid body

So I need to setup a system that copies a NavMeshAffector from a rigid body to its colliders once it's done loading

Do you think oxidized_navigation could maybe also respect NavMeshAffector on rigid bodies?

[visual fiber]

Oooh okay, let me try real quick then!

[opaque sorrel]

Theoretically but it becomes complicated with updating in hierarchies.

Unless you assume that child colliders don't move relative to the parent & iterate the hierarchy every time the parent moves.

Or assume that once you've added the component to a parent, you won't add new colliders to the children. 🤔 it may be difficult to create a generic system which fulfills all expectations

[visual fiber]

Yeah fair enough. @hearty swift I bet you also had to deal with something like this in the past, right?

[visual fiber]

(not as real quick as I thought since I'm setting things up in a hook which AFAIK cannot to queries directly until 0.16 (maybe))

[visual fiber]

@trim lagoon assigning a character to the box and chair works pretty well! (until at the end there's that dodgy_2d crash again, haha)

[trim lagoon]

I think I've fixed this bug, gotta write a test to check though

@visual fiber was this only happening when you were having dynamic objects be NavMeshAffectors?

Just to make sure my hypothesis matches reality 😛

[visual fiber]

Yep!

[trim lagoon]

Awesome!

[trim lagoon]

That's funny, my guess as to what was going wrong was incorrect, but the fix is identical 😛

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

Still working through the dodgy crash though

Also hopefully when Alice returns, I can get a landmass channel going so I don't end up spamming this chat haha

[visual fiber]

Oh please use the channel as much as you want with landmass stuff, it's an integral part of the template now 😄

[visual fiber]

Hehe, guess you got lucky!

[visual fiber]

btw @indigo atlas, during the rework I found a lot of bugs in avian_pickup that I fixed in 0.1.6. I think it's quite well-behaved now (mostly), so you may want to upgrade your version if you didn't do so already 🙂
Here's some footage covering the edge cases

(this uses the "ignore player collisions while holding" strategy we discussed a while ago)

[indigo atlas]

So do props also go flying if dropped while inside the player collider?

[visual fiber]

Yep. I rediscovered another strategy I forgot in the meantime: keep the player collision disabled until the player walks out of the dropped prop, then reactivate it. See e.g. The Dark Mod

(Unfortunately I had some issues implementing that one with Avian so far)

[indigo atlas]

Cool. I'll mess around with it after I finish my current project focus.

[indigo atlas]

I haven't played with it yet, but I just thought of something. How does it handle this series of actions:
jump, pick up/pull, drop, repeat?
Theoretically, if the distance is short enough, and performed fast enough, I can imagine the player being able to "fly".

Maybe I'll test it. || I like trying to break things.||

[visual fiber]

Good question, I'll check out what it does in TDM later today 🙂

[visual fiber]

Tested it, and TDM does not allow flight like that!
I think the trick is that in TDM, when holding up an object, the distance is kept constant. If you pick up an object that is 1.5 meters away from you, it stays 1.5 meters away until you drop it. This means that the mere act of picking something up does not generate any force!

this is how the picking behaves in TDM

notice also how TDM drops the object for you once it would be close enough to the camera to intersect with it

[indigo atlas]

Nice

[trim lagoon]

I gave up and cheated. dodgy_2d now no longer panics in this case. This was just some floating point error that I didn't know how to fix. The two constraints are parallel but are so close that it also thinks one line invalidates the other, but then upping that epsilon just caused panics in other test cases, so idk. The practical reality is that this is such a rare situation, I think it's safe to use whatever arbitrary velocity it comes up with.

[visual fiber]

hehe, fair enough

[trim lagoon]

So just update to dodgy_2d v0.5.5 and you should be good to go

[visual fiber]

I'll just report to you in case the fox starts zooming around 😄

BTW, the kind folks of the rendering dev channel helped me through some trouble with HDR. This resulted in three separate Bevy bug reports for multi-camera setups, haha. But now we have quite some nice visuals!

You can see that the bloom sometimes goes wild and starts glittering on the edges of objects

But other than that, I really like the lighting right now 🙂

[visual fiber]

Oh btw @cosmic raven, this sheep over here would like a channel 😉

[cosmic raven]

Ping me over in #community please 🙂

[visual fiber]

done

[visual fiber]

Is that better for you organization-wise?

[cosmic raven]

Better for teaching others how it works!

[visual fiber]

Oh okay! Will try to remember next time

[winter tinsel]

it's looking fantastic! I remember playing the early branch before it had the lighting and stuff

[agile cypress]

wow I just yoinked this and started for 0.16 and I just check

0.16 is there! with tnua! thx

[visual fiber]

Haha, great timing 😄

Still haven't bothered with writing the readme as a guide, but eh

[agile cypress]

any ideas?

[visual fiber]

The newest TrenchBroom release candidate just came out and includes my glTF rotation fix

So I suggest using that one to open the maps 🙂

[visual fiber]

Most important part is how to use the level editor

It's all setup so that you can cargo run the game once, and it will automatically populate your trenchbroom settings to make it ready

(there's a message in the console output)

Then you can simply open the .map file in TrenchBroom and everything should just work out of the box

[agile cypress]

Okay, ill navigate this for a bit. I've got some time early tomorrow. Might have some notes that could be useful/could help your guide

thanks

hehe still xpbd reference in dialogue

[visual fiber]

OOOOH right I didn't update that one

Knew I forgot something 😄

[agile cypress]

I'm kinda missing this part. Could you help me rq with understand what updates my settings?

[visual fiber]

Sure! In src/third_party/bevy_trenchbroom, there’s a system that writes some config on startup

You can see in there see that it will send out an info! if successful

You then open up the .map file in TrenchBroom

Does that make sense?

[agile cypress]

yes! all of it, thanks

[agile cypress]

https://github.com/janhohenheim/foxtrot/blob/5575bcc683dcc076418aec803952a4bc0b552f99/src/gameplay/player/mod.rs#L53 note what 😱

[visual fiber]

Excellent question

[agile cypress]

haha noted

[visual fiber]

I think that was
"Note that the total height of the character is length + 2 * radius"

[agile cypress]

ah, and then was moved to the other const. makes sense

[visual fiber]

exactly!

[visual fiber]

@opaque sorrel @trim lagoon got a new nav mesh weirdness

Don't know how visible it is, but I believe the nav mesh is being generated under the slope

Which means that the agent gets stuck on the slope, as it is no longer on a nav mesh

Is there any knob I can tweak?

[trim lagoon]

Seems like something is oversimplifying the navmesh

I can't remember, can you see the vertical height of the voxels with oxidized navigation? Might be worth decreasing the size of that if so

Ah yup https://docs.rs/oxidized_navigation/latest/oxidized_navigation/struct.NavMeshSettings.html cell height

I don't actually know if that'll help, but I think that should make the slope be modeled better?

[opaque sorrel]

This is the technical reason why the height correction exists 😭 I gotta find the time to fix it's quirks.

As Andriy says it's oversimplifying.

[visual fiber]

Pushing the cell_height down didn't have any effect unfortunately. Anything else I can do? Or do I just wait until the height correction is fixed?
Edit: on this new map, the height correction actually works fine so far 🙂

@trim lagoon btw, the Fox has some issues avoiding chairs

Increasing the character radius of the chair had no meaningful effect on this behavior

I believe that model does have its origin at the feet, so the navigation character should not need any vertical offset

[trim lagoon]

This is a fundamental problem of how local avoidance works and there's basically nothing I can do on landmass' side. The proper thing to do is wait for the object to stop moving and then convert it into a static obstacle - in the case of oxidized_navigation I think give it the NavMeshAffector component

This is basically just navmesh hole cutting

[visual fiber]

Oooh okay

that makes sense, thanks 🙂

I guess landmass_oxidized_navigation could have that feature however, right?

[trim lagoon]

I've thought about how to do this without leaving landmass, but I don't think it is practical. I think the long term is that landmass sadly needs to pick a nav mesh generation thingy

[trim lagoon]

Yeah it could do, I would need to decide how much I can put in landmass though

[visual fiber]

For the other 3D people out there, main now has a neat little asset baking script that is used in the release workflow.
It does the following:

• Compress all textures to ktx2 + bc7
• Generate mip maps for them all
• Modify glTFs to point to the new ktx2 textures
• Compile all TrenchBroom maps to .bsps and run light to generate light maps and light grids

All of that runs automatically on release, so you don't have to worry about it 🙂

In a nutshell, what the KTX2 stuff does is:

• Reduce file size
• Make textures faster to use for the GPU
• Eliminate aliasing when looking at textures from afar or an angle

[agile cypress]

hey :> idk how, but the gltf rotation fix might not work with bevy_skein...well, it definitely does rotate it, but the transform is still in the original location

that was a fun one to figure out hahaha i was losin my mind for a sec

[visual fiber]

Should it not be?

[visual fiber]

Oh no!

[agile cypress]

seems like something must be going on where the parent is always at the origin or some business

I couldn't decipher it tbh

[visual fiber]

I don't quite get the problem. What are you seeing, what are you expecting to see?

[agile cypress]

so this location right (positive x, positive y in blender world), so if I use the rotation fix...it's perfect! right where I expect it to be (ignore the one to the left, debugging but can't really remove yet lmao)...

however...if I log the distance from the player translation to its translation (global stuff), well, if I sit right where it is prior to the rotation, I'm on it.

[visual fiber]

Are you logging the distance to the entity that holds Mesh or the entity that holds SceneRoot?

[agile cypress]

might be a few reasons for this but not sure...may investigate after this jam im in

[agile cypress]

scene root I believe

[visual fiber]

Then the glTF fix should not affect you at all, as it only rotates the children of that entity

(as those are the purely visual components)

[agile cypress]

huh...well, whatever this becomes

ig I'll have to look deeper

[visual fiber]

Can you show me the hierarchy in Blender?

[agile cypress]

Is this what you mean? pickup is child of Object

[visual fiber]

And is that one single big glTF? including the Collection?

[agile cypress]

oh yeah, loaded up

that's how we roll hahaha

[visual fiber]

Hehe

Alright, try this

[agile cypress]

it's no problem honestly, once I undid the rotation, everything became safe n sound. I'll just draw everything backward

[visual fiber]

that's good to hear 🙂

could you still try this snippet? (sec)

This observer here instead of the plugin

fn fix_gltf_coordinates(
    trigger: Trigger<SceneInstanceReady>,
    q_scene_root: Query<&SceneRoot>,
    q_children: Query<&Children>,
    mut q_transform: Query<&mut Transform, With<Mesh3d>>,
) {
    let scene_entity = trigger.target();
    let Ok(scene_root) = q_scene_root.get(scene_entity) else {
        return;
    };

    let Some(asset_path) = scene_root.0.path() else {
        return;
    };

    let Some(extension) = asset_path
        .path()
        .extension()
        .and_then(std::ffi::OsStr::to_str)
    else {
        return;
    };

    const GLTF_EXTENSIONS: [&str; 2] = ["glb", "gltf"];
    if !GLTF_EXTENSIONS.contains(&extension) {
        return;
    }

    let mut iter = q_transform.iter_many_mut(q_children.iter_descendants(scene_entity));
    while let Some(mut transform) = iter.fetch_next() {
        transform.rotate_y(std::f32::consts::PI);
    }
}

remove the plugin, otherwise you will get two rotations 😄

I think this is not entirely correct

But I'm curious

[agile cypress]

working

that works

[visual fiber]

Oh wow, nice!

Let me publish a patch then real quick

[agile cypress]

so awesome, thanks lol

[visual fiber]

meh, this breaks on animations

won't do a patch in that case, sorry

but happy that it was of help 🙂

[agile cypress]

no that's totally fine, I'm cool with it! thanks

[visual fiber]

I guess I'll have to bite the bullet at some point and do that rotation fix PR in Bevy itself

[agile cypress]

Honestly it might not even be the rotation fix now that I think about it #general message
I think this was particularly unusual...culling happening like that? no way...anywho

[visual fiber]

yeah that looks cursed 👀

[agile cypress]

I think I’ve found a catch all solution to the gltf animation problem

That’s like really simple. Just didn’t know it existed, I’m gonna send up a crate soon

Literally the Gltf struct has everything we need to make animations work quickly without having to type out handles to animation clips

[visual fiber]

I'm interested in learning more about this 👀

[agile cypress]

Do you think it's be good to use a trigger? I'm not exactly sure how bevy_kira_audio's AudioSink::play works looking at it...seems like that would be much clearer, like an analogous interface for something like

//pretend there's a timer here and this is an Update system
fn play_next(
foxes: Query<&GltfAnimation, With<Fox>>,
mut index: Local<usize>
) {
  for fox in foxes {
    fox.play(*index);
    //fox.play("T-Pose") would work if the animation is named in the gltf
  }
  *index += 1;
}

but not that skilled. so instead something like

//pretend there's a timer here and this is an Update system
fn play_next(
mut commands: Commands
foxes: Query<Entity, With<Fox>>,
mut index: Local<usize>
) {
  for fox in foxes {
    commands.entity(fox).trigger(PlayAnimation::new(index));
    //if it's named, PlayAnimation::new("T-Pose") would also work
  }
  *index += 1;
}

would that make sense? This is kinda the last piece.

edit: maybe ill go even simpler. it'll just give you node indexes..

[agile cypress]

https://github.com/dsgallups/bevy_gltf_animation/blob/master/examples/human.rs take a look at them apples

the interface is not what I want, but it'll play

(you may notice some borrowed code 😆 )

if the animations are named, you can do that too...but really don't love the interface I've got, really should be an extension of a regular animation lpayer, or at least feel like it

[agile cypress]

I'm afraid this may no longer be a game template 😆 I just caught up with the changes to see how to structure trenchbroom in my app, and I think shader_compilation.rs is wild LOL

on a serious note, would there ever be a scenario where a QuakeClass would not point to a gltf/glb type?

I haven't yet seen that in the template but it's not something I have found to be easily discoverable

[visual fiber]

Yeah I should rebrand it to "reference project"

The shader compilation is sadly essential for 3D on web IME

[visual fiber]

IIRC the PointLight proxy struct to place point lights in TB is a QuakeClass that is just a regular pointlight

I believe brush entities are also QuakeClass, and those operate directly on the brushes inside its grouping

See the 'LightWindow` for such a brush entity

[agile cypress]

oh good, okay thanks!

[visual fiber]

Let me know if you need help with the TrenchBroom stuff 🙂

[agile cypress]

will do :)

[cosmic raven]

Foxtrot reference game

[agile cypress]

@visual fiber would there be any interest in meshlet processing at runtime? maybe during your loading state?

I think I've cracked the code on this

[visual fiber]

Yes, absolutely! Why not as a preprocessing step, though?

[visual fiber]

Like, run the processing in a little CLI that can be executed by the release workflow, save the meshlet meshes to disk, then load those in release mode instead of glTFs

[agile cypress]

I was thinking that if the preprocessed mesh doesn't exist in assets, that it would generate and potentially save to an assets directory

because it indeed is slow

I've got a bias though since I have a fast processor, but the fox..lemme see

It took no time

hmm

[visual fiber]

I think the biggest mesh is the arms

[visual fiber]

Does it work on Wasm?

[agile cypress]

something's off actually...

Let me see...

[visual fiber]

Though those don’t need LODs by definition

[agile cypress]

fails on Fox.glb actually, that's why it was so freaking fast

[visual fiber]

Hehe

I only use .gltf anyways, FYI

[visual fiber]

No indices? I doubt that 😄

[agile cypress]

There's also a few other issues...even if it does get processed

but I'll see what's going on with the fox

[visual fiber]

Consider pinging jasmine if it doesn’t work, I'm very positive she’s happy to help 🙂

[visual fiber]

FYI, the fox model is not the most well behaved in general. Its scale is huge, its normals used to be non-normalized (dunno if that was ever fixed), and its animations are scaled really weirdly

@agile cypress could you try the fox glTF in foxtrot?

[agile cypress]

works

LOL

[visual fiber]

Yeah I tried to completely clean up that model for my use-cases

Intentionally not upstreaming since the version in Bevy's assets is the same as in the official glTF test resources

[agile cypress]

Doesn't seem too impactful here either because of low poly count

I'm afraid what will happen when I play animations... 😬

[visual fiber]

Oh those should definitely not work IIRC

[agile cypress]

makes a lot of sense haha

[visual fiber]

Though that message is a year old

[agile cypress]

you'd probably have to "rerig" the meshlet

ah

[analog kernel]

In Foxtrot v0.4.0 (commit 274563b), we initially implemented camera smoothing using the bevy-dolly crate. Following the recent refactor, while the explicit camera smoothing configuration appears to have been removed, I've noticed the camera movement has become significantly smoother. Could you help me identify which part of the current implementation is responsible for this improved smoothness?

[visual fiber]

The smoothing happens on Avian's side. The physics collider for the player is being interpolated each frame (See TransformInterpolation or something like that), so we can just set the camera to that position 🙂

[analog kernel]

This means the first-person camera is positioned on the player, and the player's movement is interpolated using Avian. For implementing a third-person camera perspective, would using bevy_dolly still be necessary in this case?

[visual fiber]

For the position, it would be fine.
For orbiting around the player and changing the camera distance, you'll still need something like dolly or manual interpolation to not male certain situations jarring

Mainly what happens when you orbit the camera such that it would collide with terrain

If you simply put the camera in a non-colliding distance in one frame, it feels very disorienting

Same when you are no longer colliding and want the camera to return to its original distance

[analog kernel]

Thank you, I understand now. The first-person camera is positioned on the player and moves exactly with it. However, the third-person camera isn't part of the player entity - it needs independent smoothing for its movement.