#bevy_trenchbroom

1 messages · Page 2 of 1

urban zealot
#

I'm running Brave with --enable-unsafe-webgpu and can use it without issue, though i didn't get low FPS without that flag, i just couldn't use WebGPU at all

#

If nothing else, you could just do some simple CPU-side particles

dim warren
#

Oh, I can't do that anyways, since then the avian collider constructors on those props fail. Nvm, I'll have to set the render asset usage manually at OnRemove, ColliderConstructorHierarchy

#

(and at SceneCollidersReady, thanks for that trigger!)

urban zealot
#

@dim warren I think i got the new rotation fix working, feel free to try the correct-coordinate-conversion branch at your earliest convenience

dim warren
#

I'll probably also make a little crate like bevy_fix_gltf_coordinate_system that does this for all glTFs

dim warren
#

The branch:

urban zealot
#

Dang, can you send me the chair model, so i can test it in mine?

dim warren
#

Though the actual thing spawned in-engine is this

dim warren
#

Update: checked the world rotation, and your branch has it correct

#

(based on how my camera spawns)

dim warren
# dim warren

Since this is rotated by 180 deg, this should be correct when using a global glTF coordinate fixer

urban zealot
dim warren
urban zealot
dim warren
#

cool, sec

dim warren
#

the level has it

image.png
urban zealot
dim warren
#

And here is the transform of the chair

image.png
#

That looks to me like TAU / 12

#

so uuuhm

#

360 / 12 = ??

#

30

#

about a 30 degree rotation

#

In the editor, it has a yaw of 150 degrees

urban zealot
#

I think think we need to be looking at rotation since my code doesn't touch it, only scale

#

Which is indeed not negative

dim warren
#

yep

dim warren
#

oh wait

#

no, I got it

urban zealot
# 
fn fix_gltf_scenes(
        mut events: EventReader<DeferredGltfRotationFix>,
        mut commands: Commands,
        mut scene_root_query: Query<(&mut Transform, &SceneRoot)>,
        ancestor_query: Query<&ChildOf>,
        rotation_fix_query: Query<(), With<FixGltfRotationsUnderMe>>,
        do_not_fix_query: Query<(), With<DoNotFixGltfRotationsUnderMe>>,
    ) {
        for DeferredGltfRotationFix(entity) in events.read() {
            let entity = *entity;
            let Ok((mut transform, scene_root)) = scene_root_query.get_mut(entity) else { return };
            let Some(path) = scene_root.0.path() else { return };
            let Some(ext) = path.path().extension().and_then(std::ffi::OsStr::to_str) else { return };

            match ext {
                "map" | "bsp" => {
                    if !do_not_fix_query.contains(entity) {
                        commands.entity(entity).insert(FixGltfRotationsUnderMe);
                    }
                }
                "glb" | "gltf" => {
                    for entity in ancestor_query.iter_ancestors(entity) {
                        if rotation_fix_query.contains(entity) {
                            if transform.scale.x.is_sign_positive() {
                                transform.scale.x = -transform.scale.x;
                            }
                            if transform.scale.z.is_sign_positive() {
                                transform.scale.z = -transform.scale.z;
                            }

                            break;
                        }
                    }
                }
                _ => {}
            }
        }
    }

Here's the full system for convenience

dim warren
#

Neither the chair scene root nor the mesh itself has a negative scale on my end

#

btw, I would avoid that

#

Some third party crates really really don't like negative scales

#

IME rotation is much safer

urban zealot
#

Well that sucks

urban zealot
dim warren
#

I mean we can use scale until any problems come up and still switch, no biggie

dim warren
urban zealot
dim warren
#

Dunno if that affects it

urban zealot
#

It looks for Trigger<OnAdd, SceneRoot> so i doubt it

#

Actually, i can probably just clone the repo and debug this myself, right?

#

Can you send a link and branch?

dim warren
dim warren
urban zealot
#

@dim warren I fixed it, may have worked a little too well, the fox is now following me backwards

#

Also the lantern is not able to be picked up, not sure if that is caused by this though

dim warren
dim warren
dim warren
#

@urban zealot this error is due to the CI cache being suboptimal. I can fix it for you later 🙂

image.png
urban zealot
dim warren
#

Just updated to BTB main and the backwards walking fox is quite funny 😄

dim warren
#

just delete the CI caches before merging

#

just click on the trash icon for all caches

#

no, GitHub does not have a button to select all at once sadcowboy

urban zealot
#

Thanks a bunch!

dim warren
#

heheheehe

image.png
urban zealot
dim warren
#

HECK yeah

#

that indeed looks sick as hell

#

Great job on the athmosphere!

urban zealot
#

Aww, thank you!

dim warren
#

btw, I'm now trying to cram all of the weird texture hacks I had to do into one python file that you may be also interested in. It should do the following:

  • move all textures so that qbsp (the tool, not the crate) can deal with them
    • change the .map file accordingly
  • generate mipmaped ktx2 files for all map textures
    • change the material files to point to the new textures
  • generate mipmaped ktx2 files for all glTF textures
    • change the glTFs to point to the new textures
  • run qbsb and light
    • delete the .map file and intermediate compilation products
#

The idea is to do that in the CI release step so that a user doesn't need to care about it

#

But they could still run it locally if they want

#

And that would produce an assets_new directory that contains the baked assets

#

That way, users don't need to deal with the weird Quake 1 restrictions for bsp generation

urban zealot
dim warren
#

It should be able to do all of those

#

But every time I ever asked anyone to explain to me how asset pre-processing works, I got shrugged shoulders

#

I have no clue how any of that works, so I tried the basic built-in KTX2 converter

#

And that one cannot read any PNGs for some reason

#

Looked around and apparently that's just broken since an unknown amount of time

urban zealot
dim warren
#

Feel free to just take my python code that I'm writing right now for the logic of that

#

Especially the part about moving the textures around

#

and truncating the names

#

that's not something any user should ever have to deal with haha

urban zealot
dim warren
dim warren
urban zealot
dim warren
#

It's really small 😄

#

You may want to copy the logic to your fix thingy

#

OR

#

I could also add an opt-in mode

#

hmm nevermind, that wouldn't be nice for people consuming the crate

#

I also learned that in current Bevy, Assets<Gltf> is almost guaranteed to always be empty

#

that was unexpected

urban zealot
gloomy fable
#

hell yes

#

nice

#

thank you!!

dim warren
#

You're welcome 😄

#

once the tests pass, I'll publish

#

@urban zealot could you ping me once BTB doesn't affect non-level glTFs anymore?

#

Then I can opt-out and just use my new crate globally

urban zealot
dim warren
urban zealot
dim warren
urban zealot
#

I would like to probably switch to your crate at some point though

#

Have it be included in the PluginGroup by default

dim warren
#

Just realized I had two from_rotation_y(PI) in my code that I completely forgot about

#

I think I just added them without much thoughts when I noticed things were flipped in-game

#

Well, now I know why 😄

#

Was able to remove them now cooltofu

urban zealot
#

@dim warren In the CI, why did you put --locked in the cargo test command?
Just wondering because

error: the lock file /home/runner/work/bevy_trenchbroom/bevy_trenchbroom/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
dim warren
dim warren
#

It's also way nicer when you are pointing to git dependencies on main, e.g. when updating to a new Bevy version and some stuff still needs manual patching

#

That way, you and I and the CI will all use the same commits of that git dependency

urban zealot
dim warren
#

@urban zealot I've encountered a weird phenomenon

#

This is my base.toml:

type = "StandardMaterial"
[material]
base_color_texture = "${name}/${name}.ktx2"
normal_map_texture = "${name}/${name}_normal.ktx2"
perceptual_roughness = 0.7
#

This is my blocks_uneven_b.toml:

inherits = "/textures/base.toml"

[material]
perceptual_roughness = 0.9
#

(sec, I accidentally yeeted my example)

#

here's the relevant file structure

image.png
#

looks fine in-game

image.png
#

Notice that I never reference the .png in my material files. So let's delete it and run the game again

#

oh no!

image.png
#

Let's walk veeeery close up to the wall:

image.png
#

aha, the texture is there, it's just incredibly small

#

Now, this could very well be an issue with how I generaty my .ktx2 files

#

But what I am wondering is why this is behaving differently whether or not I have a png?

#

Is it possible that bevy_materialize is somehow still loading that png? Note that I get no warnings whatsoever.

#

Update: welp, I upgraded to main and the spooky PNG having an effect is fixed

#

Also, the tiny tiny KTX textures are fixed when using the BSP instead of the .map

#

I don't know why any of this is the case, but I found my solution and I'm happy, as the .map build in my script uses PNGs instead of KTX anyways

urban zealot
urban zealot
dim warren
#

You may get some use out of it too

#

it changes all textures to KTX2 with enabled mips, and then modifies the .map and all .gltf files to point to the new textures, makes all textures correctly follow the quake 1 map limitations, then compiles the BSPs

#

The idea is to then run this script in the release workflow automatically 🙂

urban zealot
dim warren
#

The only thing that's missing right now is that I need to convert PBR textures a bit differently

#

The resulting assets directory is 25% smaller than the original, that's pretty neat

#

But also more performant at the same time 🔥

#

@urban zealot I assume you don't have an idea of how we could hack our way around the Bevy unwrap we're hitting, right? :/

urban zealot
dim warren
urban zealot
#

Not a clue

dim warren
#

same

dim warren
#

@urban zealot do we not support BSP on WebGL2 at all?

#

I know that I cannot use the light maps etc., but should I be able to load the geometry etc. from the BSP?

#

I'm asking because I'm getting

 Failed to load asset 'maps/foxtrot/foxtrot.bsp' with asset loader 'bevy_trenchbroom::bsp::loader::BspLoader': Encountered HTTP status 403 when loading asset

on itch

urban zealot
dim warren
#

huh, would you look at that, it works on my machine ™️

dim warren
#

I double checked, and the file definitely is there

gloomy fable
dim warren
#

Oooooh I see

#

I think there's also a second resource that is tried

#

palette.lmp

gloomy fable
#

it seems that both of those return this xml in the response

#

I thought for half a second that I was missing some request header, but the response body from these are the same in the console

dim warren
#

I added some placeholder data that I found laying around my Quake files, let's see 😄

dim warren
urban zealot
dim warren
# urban zealot Try it now

Took a while to remember how to manually upload stuff to itch, but yes, it works! Thank you so much! 😄

#

Now I can finally put my big big asset processing side-quest to rest, I'm quite happy with this 🙂
Back to level design!

urban zealot
dim warren
#

On regular old Wasm (bevy run web), it's a recoverable 404

urban zealot
dim warren
#

But itch turns all 404s into 403s

dim warren
covert heron
#

Any reason the hashbrown feature is enabled for quake-util? That was intended for non-std (I had been using the data types when experimenting with non-WASI WASM modules; it's useless otherwise b/c the io::Read/Write traits aren't in non-std 😢 ). I don't think it does much harm to use hashbrown w/ std, just curious.

And as a side-note, I was toying with the idea of replacing the hashmaps with Vec<pair>s. Pros: you can do "non-standard" things like duplicate keys, and the order of key/values is preserved; Cons: less ergonomic, needless breaking change if the pros aren't desired. Thoughts?

#

oh, and no progress on the Quake 2 surface flags, I'm in the throes of a Blue Prince addiction 😄

covert heron
dim warren
urban zealot
urban zealot
urban zealot
dim warren
#

@urban zealot how are we scaling the textures in BTB?

#

I'm having some troubles with normals, and either I completely messed up while importing my normals or BTB / bevy_materialize is doing something wonky

#

When I scale a texture in TB, I would expect BTB to use a uv_transform for the textures, but it doesn't

urban zealot
dim warren
#

Sorry, I meant texture_transform

#

oh wait, that's glTF only anyways, nvm

#

(I should have known better, I implemented it 😄)

#

Anyways, how do we scale them?

dim warren
#

There, that one should affect all textures of that material

#

hmm, but that doesn't make sense, as the scale is per face, not per material

urban zealot
dim warren
#

Do you know a good way to check the normals I'm actually using in Bevy?

urban zealot
dim warren
#

The normal map

urban zealot
dim warren
#

reference (TheDarkMod)

image.png
urban zealot
#

You could just make the base_color_texture the normal map

dim warren
#

Mine (Bevy)

image.png
#

see how flat everything is?

urban zealot
#

Indeed

dim warren
urban zealot
#

It should also be visible in bevy-inspector-egui

dim warren
#

looks right to me when flipping them

urban zealot
# dim warren

Looks like +Y is down, but i don't know too much about normal map formats, that's probably normal

dim warren
#

This is it with a flipped Y:

image.png
urban zealot
#

The only thing i can think of that would silently cause normal maps to not work is if the mesh doesn't have any tangents, though i'm pretty sure BTB generates those

#

If you check bevy-inspector-egui it should tell you

dim warren
#

So I have these

urban zealot
dim warren
urban zealot
#

Looking at the code though, i don't see where tangents are generated, i might have removed it accidentally in the .map loader rewrite

urban zealot
# dim warren nope

Dang, i'm 99% sure you used to be able to do that, maybe before they removed the Component impl from handles

#

Just to confirm, try generating tangents for all of those meshes and see if it fixes it

urban zealot
dim warren
#

clicking on "Generate Tangents" for all looks the same to me

image.png
#

But idk what the effects of that are when done at runtime

urban zealot
#

I'm currently neck-deep in implementing #89, so i'll re-add tangent generation in a bit

dim warren
#

It's on Foxtrot's main if you want to reproduce it

dim warren
#

Is it possible BTB or bevy_materialize are loading normal maps as rgba instead of linear?

dim warren
urban zealot
#

Oh wait i thought you were talking about the image, the material itself is put together in GenericMaterialLoader

#

Assets are inserted via AssetLoadingProcessor, which uses ReflectGenericMaterialSubAsset to load them, so that might be what you're looking for actually

dim warren
#

I'm afraid I need a bit more guidance

#

I'm just trying to figure out where the normal map is loaded

#

because it needs to have is_srgb = false in its settings

urban zealot
dim warren
urban zealot
#

Also i thought color spaces were determined from the image file itself

dim warren
urban zealot
#

Oh i did a cargo update and it just appeared

dim warren
dim warren
urban zealot
#

Which is weird actually, since that didn't update Bevy

#

oh well

dim warren
#

IIRC every texture except the base color texture is expected to be linear

urban zealot
dim warren
urban zealot
dim warren
#

I'm just over here in the 30% camp wanting my normal maps though 😆

#

I wonder if there's some place where I can easily hack in the image loader settings to see whether this actually fixes my problem or not

#

Like, will those settings be propagated to the normal map loading?

urban zealot
urban zealot
#

You'll probably have to copy the function entirely though (or edit a local checkout actually)

dim warren
#

good news: it works!

image.png
#

But I'm not sure what fixed it

#

Since in this change I also realized I was not generating the correct tangents at runtime

#

so let me check again without the SRGB stuff

#

(for context, I had set my meshes to RENDER_WORLD, so they didn't even show up in the inspector)

#

this is with just the tangets

image.png
#

Looks good!

#

That means that the linearity is indeed being inferred from the image 🙂

#

Although....

#

This is using TGA, which has metadata. Let's see if this works with PNG still

#

looks file as well

image.png
#

which brings me to the question of how this even works hmm

#

Though it could just be luck that it works. Issues with loading normals with the wrong settings tend to only crop up with light from certain directions.

dim warren
urban zealot
#

It doesn't look fine to me, the top left is wrongly in shadow

#

I was having this problem before

dim warren
#

Hmm you're right

dim warren
#

but it's a bit hard to tell because I'm loading the base color with the wrong settings (linear instead of srgb)

#

BTW, I love asset_server.exists

#

It's a bit too bad that it needs to read the asset to work

#

But it's such a good feature 😄

#

Good job on that one

dim warren
#

Alright, this is it with only setting the normal map to linear and generating tangents:

image.png
#

Same with flipped Y for normals:

image.png
urban zealot
# dim warren BTW, I love `asset_server.exists`

Thanks! I really think that should be a built-in Bevy feature, perhaps a new part of the asset source interface so it doesn't need to start reading the asset (i don't think it actually reads any data, even on web)

urban zealot
dim warren
urban zealot
#

Yea

dim warren
#

Yes, the first image uses linear for everything, the last only for normals

urban zealot
dim warren
#

Hacked my way around the issues, looks pretty neat now 🙂

dim warren
urban zealot
urban zealot
dim warren
dim warren
#

Added some GH issues for the things we discussed

dim warren
#

Could you check whether you get the same issue in your test scenes?

#

This is testing my release workflow, so it may be something else

urban zealot
dim warren
#

Oh wow, you already implemented the type registry stuff? great!

urban zealot
#

Bevy's reflection system is pretty sick

dim warren
#

Looking at the diff right now

#

Looks pretty neat indeed 👀

#

Just updated my app to move all things relating to a specific TB entity into their own little file. Much better now! Thanks for the feature 🙂

urban zealot
#

Just learned that not all images use ImageLoaderSettings, complicating things further
I also probably need to restructure bevy_materialize in general, while i think the design of things is sound, both of us had a hard time navigating it earlier

dim warren
urban zealot
urban zealot
#

I ended up converting it anyway since it was using an unsupported compression method

dim warren
urban zealot
dim warren
urban zealot
#

I probably should've tried turning is_srgb off before starting a bunch of refactoring in bevy_materialize :P

dim warren
dim warren
# urban zealot Yes

that's good (for me), as that means I don't have to fix my asset baking pipeline 😄

urban zealot
dim warren
urban zealot
#

I can reproduce that turning is_srgb off across the board seemingly fixes it, i am too tired for API design but tomorrow i will make a hopefully much better asset settings system
I do remember thinking "this is ridiculous and dumb" while writing the current API, especially this

/// Same as [`register_generic_material_sub_asset`](Self::register_generic_material_sub_asset), but passes image settings through.
/// This will cause an error if the asset loader doesn't use image settings.
fn register_generic_material_sub_asset_image_settings_passthrough<A: Asset>(&mut self) -> &mut Self;
dim warren
urban zealot
dim warren
#

(that one would be the default use-case)

#

If you manage to get it running with is_srgb = false on normals and is_srgb = true on base colors, that must mean that I hecked up in my hack and am not actually turning it off correctly

#

(or indeed my asset preprocessing is to blame)

dim warren
#

My issue is indeed that my KTX files are being read as srgb hmm

dim warren
# dim warren Thanks! This is now with [this ugly ugly hack](https://github.com/Noxmore/bevy_m...

Okay, after some digging, that hack is not enough. Not quite sure why, but I really need to set is_srgb = false in BTB itself to have all my KTX2 files loaded as non SRGB.
The line in question is being executed though. This means that the KTX2 files are being loaded with the default settings before these settings are applied. I'd be happy if you could double-check this however. I really really don't understand bevy_materialize, my bad 😅

#

(Note that I think this is also the case when using .map and when using .pngs, but not sure)

dim warren
dim warren
dim warren
#

Got a workaround for now: preload all base color textures as srgb (which is simple as their paths are right in the .map) and then let BTB load all the rest as linear

dim warren
#

Alright, now that I've got that workaround I'm back to mapping some more. I'm currently trying to make a brush that has a window texture emit light.
I tried doing so by using a SolidClass on the window brush and inserting a point light. That resulted in two things:

  • The window lost its texture
  • The light spawned at the world origin
    Looking at the inspector, I see that I have created two new entities through this action
#

This first is this:

LightWindow is my solid class, and it is at the world origin.

image.png
#

Next to it in the hierarchy, I see this:

image.png
#

That big name is the name of my texture. This entity has the right transform and is holding the collider, so it seems like the one I'm actually interested in. However, the LightWindow marker is on the other entity.

#

Am I doing something wrong here?

urban zealot
#

As for the light spawning at the world origin (assuming you spawned it at the brush entity's transform), that's expected behavior if you don't have an origin brush in the brush entity

#

Not sure about the window losing its texture though

#

BTW @dim warren, did you figure out that non-base-color textures have to be linear by reading it from somewhere, or was it just through testing?

dim warren
dim warren
dim warren
urban zealot
urban zealot
dim warren
urban zealot
#

This is loading the .map, right?

dim warren
dim warren
dim warren
urban zealot
dim warren
#

I'm still a bit new to TB, haha

urban zealot
#

You'll just need a texture named "origin", then you apply it to all of a brush's faces, and make sure that brush is part of the brush entity you want to set the origin of

dim warren
#

(TIL multiple brushes can be part of a brush entity)

urban zealot
dim warren
#

Good news: that worked! Bad news: even the white texture of the brush is gone now, it's completely transparent

urban zealot
#

If you were using a pure-bsp workflow, the compiler can actually automatically insert light entities at certain textures you specify

urban zealot
dim warren
#

Maybe for context, this is TB

image.png
#

This is the window without a brush entity

image.png
#

(sorry for the blinding light, haha)

#

Huh, weird, I wanted to repeat the screenshot without a light and now the textures are gone again

image.png
#

🤷‍♂️

urban zealot
#

The sides of the the window look like that with the light

dim warren
#

The texture is visible in light???

urban zealot
#

Spooky

dim warren
#

Okay, not sure what kind of sorcery this is

#

But now the same with the brush entity + origin:

image.png
#

also no collider, btw

urban zealot
dim warren
#

both there

image.png
#

there even is a collider, in theory

image.png
#

found it!

image.png
#

It went to the world origin as well now

#

For reference, I put the origin brush there in TB

image.png
#

don't know if that was correct?

urban zealot
#

I would guess that's because the mesh entity isn't a child of the light_window entity

dim warren
#

Ooooh right

urban zealot
#

Oh wait i see it now

dim warren
#

the other entity that ends in brightlit is supposed to be its child I believe (that one has the collider and mesh)

urban zealot
#

Currently staring at the line of code that adds the mesh as a child

world.entity_mut(entity_id).add_child(mesh_entity);

Looks right...

dim warren
urban zealot
#

Though should be inserting a ChildOf component because of 0.16 changes

urban zealot
#

I might have to put a pause on this to focus on materials and settings and stuff

dim warren
dim warren
#

Appreciate it!

urban zealot
dim warren
#

update: for some reason, the hierarchy is correct for func_group of brushes:

image.png
dim warren
#

But when creating a func_group of a single brush entity, it creates 3 siblings:

image.png
dim warren
dim warren
# dim warren But when creating a `func_group` of a single brush entity, it creates 3 siblings...

Okay, I have found the condition on which this arises:


pub(super) fn plugin(app: &mut App) {
    app.register_type::<LightWindow>();
    app.add_observer(setup_light_window);
}

#[derive(SolidClass, Component, Debug, Reflect)]
#[reflect(QuakeClass, Component)]
#[base(Transform, Visibility)]
#[geometry(GeometryProvider::new().trimesh_collider().smooth_by_default_angle().with_lightmaps())]
pub(crate) struct LightWindow;

fn setup_light_window(trigger: Trigger<OnAdd, LightWindow>, mut commands: Commands) {
    let entity = trigger.target();
    commands
        .entity(entity)
        // Remove this line to make the problem go away
        .insert(children![Name::new("Child")]);
}
#

The brush entity is not allowed to have children on its own, otherwise we run into the bug!

#

On that note, is there some kind of trigger I can observe that tells me "this brush entity is done, its hierarchy has been constructed, you can use it"? Like SceneCollidersReady but just for an entity brush

#

I need to manipulate the entity that is holding the brush entity's mesh, but to do that, I would have to wait with my observer until that child is actually there

#

I tried Trigger<OnAdd, Children>, but that is not triggered on EntityCommands

dim warren
#

Just noticed that I don't need children on the entity brush marker object anyways, I need the child on the child that holds the mesh

#

So this bug is not as bad as it seems for my case 😄

dim warren
#

Got a good hack in the meantime:

#[derive(Component, Reflect)]
#[reflect(Component)]
pub(crate) struct NotifyBrushEntitySpawned;

#[derive(Event)]
pub(crate) struct BrushEntitySpawned;

fn trigger_entity_brush_spawned(
    brush_entities: Query<(Entity, &Children), With<NotifyBrushEntitySpawned>>,
    mut commands: Commands,
) {
    for (entity, children) in brush_entities.iter() {
        if children.is_empty() {
            continue;
        }
        commands
            .entity(entity)
            .trigger(BrushEntitySpawned)
            .remove::<NotifyBrushEntitySpawned>();
    }
}

used like this:

fn setup_light_window_entity(trigger: Trigger<OnAdd, LightWindow>, mut commands: Commands) {
    let entity = trigger.target();
    commands
        .entity(entity)
        .insert(NotifyBrushEntitySpawned)
        .observe(setup_light_window_brushes);
}

fn setup_light_window_brushes(
    trigger: Trigger<BrushEntitySpawned>,
    children: Query<&Children>,
    mut commands: Commands,
) {
    let entity = trigger.target();
    let Ok(brushes) = children.get(entity) else {
        return;
    };
    for brush_entity in brushes.iter() {
      // do things with the actual brushes
    }
}
dim warren
dim warren
#

Are angles supposed to work for brush entities?

#

I can't get them to have a rotation other than IDENTITY

dim warren
#

Well, I can just add a field called angles to my brush entity and use that for my transform, so that works. But it seems weird that the origin brush worked for setting the translation, but not the rotation.

urban zealot
urban zealot
dim warren
#

sec

dim warren
dim warren
# dim warren

that little arrow is the direction the light will shine towards in my setup

urban zealot
#

Oh, i thought you wanted to just rotate the brush

dim warren
urban zealot
#

Yeah, i don't think i thought that one completely through

dim warren
dim warren
urban zealot
#

Oh yeah, the color space thing should be fixed by default now

dim warren
urban zealot
#

Ended up scrapping basically the entirety of yesterdays work :)

dim warren
dim warren
#

So congrats 😄

urban zealot
dim warren
urban zealot
#

I'm still a little confused

urban zealot
#

Or do you mean the entity that contains Mesh3d?

urban zealot
dim warren
#

I was about to say "the brush entity has no children yet when I use Trigger<OnAdd, BrushEntity>", but that is not true hmm

dim warren
#

Except if I need to enable something

urban zealot
#

Dang

dim warren
#

(let me run a cargo update just in case)

dim warren
#

I'll double check what my issue was

#

The heck

#

So, when entering Trigger<OnAdd, BrushEntity>, we have a child. So far, so good.
When I insert a second child, the first child becomes a sibling hmm

urban zealot
dim warren
#

Yeah, I did not expect this behavior, which is why I assumed that there were no children to begin with then entering the observer

#

That's why I wrote my earlier messages that way

#

Good news for me: I can remove my hack and iterate over the children of the brush entity directly, yay!

#

Adding a grandchild to the brush entity is no problem

#

Just adding a new child is problematic

dim warren
urban zealot
#

We'll see though, trying to reproduce this heriarchy bug first

dim warren
dim warren
#

Because it sounds pretty spooky

#

Thank you again for dealing with all my bug reports heart_lime

urban zealot
#

@dim warren Aha!

commands.spawn((PointLight { intensity: 10_000., ..default() }, ChildOf(trigger.target()))); // Works fine!
commands.entity(trigger.target()).insert(children![PointLight { intensity: 10_000., ..default() }]); // Messes everything up!
#

Children::spawn() is broken

dim warren
#

Whaa

#

Aren't those the exact same?

urban zealot
dim warren
#

Have I misunderstood relationships???

#

Can you post this to #ecs-dev ?

urban zealot
dim warren
#

I guess children! is for spawning only?

#

That's weird

urban zealot
dim warren
urban zealot
#

When it wasn't working in PreUpdate, that seemingly made the images update to the new settings for me

dim warren
#

this is the ground material

image.png
#

hold on, I just remembered I set all imaged to RENDER_WORLD

#

let me disable that

#

ah sad, that didn't fix it

urban zealot
#

I also tried turning that on, didn't break it either

#

Is your thing in a state i can checkout and step through to see what's not firing?

dim warren
#

Just need to update the patch in the Cargo.toml to point back at your repo

#

The RENDER_WORLD move is in the system move_textures_to_render_world if you want to disable it

urban zealot
#

Wait, have you been just updating to the latest version of BTB? Not materialize?

dim warren
#

Sorry, I didn't catch that 😄

#

Alright alright, let me patch that one, haha

urban zealot
#

Understandable mistake, i probably should've clarified

dim warren
#

well, it makes sense to patch that one instead of BTB 😄

urban zealot
#

Things probably aren't setup for both versions of materialize, let me commit BTB real quick

dim warren
#

ping me when

#

Isn't this comment the exact opposite of what it does?

urban zealot
dim warren
#

Checked it right now, and good news: it seems to work!

#

Bad news:

image.png
urban zealot
dim warren
#

Yay, I'm really excited that this works now 😄

#

thx!

urban zealot
#

No problem!

dim warren
#

Even works when using RENDER_WORLD as you said!

urban zealot
dim warren
urban zealot
#

@dim warren Alright, give that a try

dim warren
dim warren
urban zealot
dim warren
#

Unrelated: I was wondering how TDM implemented those round storm drains, seeing as its editor is also brush based and those have no good presets for circles

#

So I took a closer look and

image.png
#

hehe, they just cut it out more or less circularly

urban zealot
urban zealot
dim warren
dim warren
urban zealot
dim warren
#

But oh boy is it wonky when looked at up-close

dim warren
urban zealot
dim warren
urban zealot
#

Oh it's FOSS, neat!

dim warren
#

It's editor is a customized radiant called DarkRadiant

dim warren
#

Hence why I'm yoinking all textures. Most models and textures are CC sharealike non-commercial by-attribution

#

Which is really generous given the quality

tidal galleon
#

Any plans to support the Quake 3 format eventually?

#

I dont even know what editor Q3 people use, NetRadiant maybe?

#

from what I recall the main difference are the patches/curves

dim warren
tidal galleon
#

Yeah, and the more I think of it the less appealing it might be for people. IMO Trenchbroom is miles ahead in stability than the other radiant editors out there. And so as long as it sticks to Valve1/Quake1 there may not be a demand for Q3 with this plugin.

Also its not like curves aren't achievable with TB

dim warren
tidal galleon
#

I'd assume the bsp is different because of the different hull sizes for various enemies.

#

but not sure about the .map format

dim warren
#

surface flag data is the big one. Those can vary per surface for the same brush.

#

The bsps can also read 32 character texture names instead of only 15

tidal galleon
#

Ahhh yes the surface flag data is huge

#

I was actually just thinking about surface data the other day. I know this is getting a bit off topic but where would you actually store that on the Bevy side of things? And how would you retrieve it?

#

say I want to do different footstep sounds based on what im walking on

dim warren
#

@urban zealot I'm again facing the problem that a PNG has to be in the textures folder for the map to scale textures properly

#

It works fine when using .bsp, but when I have a .map, I need to have a PNG laying around even though the material file only references KTX2, otherwise I get this:

#

I've verified that no actual .PNGs are ever loaded as assets

#

It works when I convert the png to an extremely compressed (~ 500 Byte) JPG, so I assume only the texture dimensions are read from it?

urban zealot
urban zealot
dim warren
dim warren
#

@urban zealot since we were recently talking about issues with negative scales

urban zealot
urban zealot
#

@dim warren Speaking of, what was your rotation fix crate called again? I would like to add it.

dim warren
#

Note that that crate is intentionally global, though

#

And you'll probably want to do the if not plugin added song and dance

urban zealot
#

Hmm. I wonder if making it the default to have this fixed will overall make the transition to the Bevy fix easier.

dim warren
dim warren
#

Btw, how well is the hot reloading supposed to work?

dim warren
#

@urban zealot oh-oh

image.png
#

this is happening about one in four times when loading a .map

dim warren
#

Newest main

#

This happens during the preloading

urban zealot
dim warren
#

But every now and then it doesn't update something, or gives it no texture, or doesn't scale the texture, etc

#

So I end up reloading the level

#

Not a big deal though 🙂

dim warren
#

Requires me to restart the whole app

#

Any ideas what might be the issue?

urban zealot
#

Hmm

#

This would happen if the map somehow preloads before classes are registered

#

When does the preloading kick off?

dim warren
#

here's what I mean

#

Also, the new brushes have no colliders

dim warren
dim warren
# 
impl LoadResource for App {
    fn load_resource<T: Resource + Asset + Clone + FromWorld>(&mut self) -> &mut Self {
        self.init_asset::<T>();
        let world = self.world_mut();
        let value = T::from_world(world);
        let assets = world.resource::<AssetServer>();
        let handle = assets.add(value);
        let mut handles = world.resource_mut::<ResourceHandles>();
        handles
            .waiting
            .push_back((handle.untyped(), |world, handle| {
                let assets = world.resource::<Assets<T>>();
                if let Some(value) = assets.get(handle.id().typed::<T>()) {
                    world.insert_resource(value.clone());
                }
            }));
        self
    }
}
#

This is the extension on App that actually inits the handle

#

So it technically starts at plugin creation time

#

Does that count as StartUp?

#

It used to work before, in any case

#

Oh wait, I could try just executing that later in the plugin setup

#

Yep, that seems to work

#

Before:

app.add_plugins((
    asset_processing::plugin,
    asset_tracking::plugin,
    shader_compilation::plugin,
    #[cfg(feature = "dev")]
    dev_tools::plugin,
    gameplay::plugin,
    props::plugin,
    screens::plugin,
    theme::plugin,
    ui_camera::plugin,
    hdr::plugin,
));
#

After:

app.add_plugins((
    asset_processing::plugin,
    asset_tracking::plugin,
    #[cfg(feature = "dev")]
    dev_tools::plugin,
    props::plugin,
    screens::plugin,
    theme::plugin,
    ui_camera::plugin,
    hdr::plugin,
    // Moved these two to the end, because they start preloading the levels
    gameplay::plugin,
    shader_compilation::plugin,
));
urban zealot
dim warren
#

Thanks for the help 😄

dim warren
# dim warren

weirdly enough, some brushes I didn't even touch lose their textures

covert heron
#

I did a little research and reached out to a trusted source on the Quake 2 front. Seems the required augmentation to the grammar is three additional tokens to each plane/half-space. I'm told the three tokens are parsed as signed integers by Carmack's original tools, though the third can be written as a floating-point by TrenchBroom

#

from the TB ui those are the "content flags", "surface flags", and "value" respectively

dim warren
#

Thanks for looking into it 🙂

covert heron
#

yeah, thought I'd put some updates here. Helps keep me motivated to keep a line of communication open with consumers. Plus, I think these particular tidbits (float vs. integer) may impact how Q2 map support gets integrated with BTB

covert heron
covert heron
#

@dim warren @urban zealot Just published an update to quake-util. Version 0.4.0 adds support for Quake II maps. There's API-breaking changes, so some refactoring is required

urban zealot
dim warren
#

Good job 😄

tidal galleon
#

Ayee awesome, thanks for that

dry portal
#

So i just made a PR (could use some help with CI) to update BTB to avian 0.3. and now I wanted to migrate my project to the current BTB, i am coming from 40c124d from 25th of april and nothing works anymore 😄 - Do we have a migration guide work-in-progress for someone coming from 0.7 ?

#

Trying to find the diffs to how I did stuff before using the examples:

  • do we have to #[reflect(QuakeClass, Component)] now on everything that used to do #[reflect(Component)] only before?
  • ok seems #[require(Transform, Target)] now needs to be #[base(Transform, Target)]
  • somehow the .material files have no effect anymore
  • combined brushes with an origin get their colliders now misplaced
  • the content of the fgd file is not deterministically sorted anymore
  • wait is auto registration gone?
dim warren
#

No clue what’s up with your materials and origin brushes, those work for me

dim warren
# dry portal Trying to find the diffs to how I did stuff before using the examples: * do we h...
  • Every class that needs to interact with TB (i.e. PointClasses and SolidClasses) needs to #[reflect(QuakeClass)], yes
  • Yep, use base for things that should show up in the TB editor
  • I think they're just some_cool_wood.toml now, no .material. Maybe .material.toml works, too.
  • Make sure you're not running into the issue I sent.
  • I'm curious, why do you need that to be sorted?
  • Yeah, use app.register_type::<Foo>() just like you would with other things that need to be reflected until https://github.com/bevyengine/bevy/pull/15030 lands 🤞
#

Some more stuff I can think of:

  • Dunno if material inheritance was a thing in 0.7, but you can now do inherits = "/textures/base.toml" in your materials to inherit definitions from a base.toml that looks like this, for example
type = "StandardMaterial"

[material]
base_color_texture = "${name}.png"
normal_map_texture = "${name}/${name}_normal.png"
perceptual_roughness = 0.7
#
  • Normal maps, roughness/metallic maps and such are now supported out of the box (they used to be important in the completely wrong color space)
#
  • TrenchBroomConfig now takes plurals for many things, like texture_extensions instead of texture_extension
#
  • Don't remember whether this was the case in 0.7, but your setup should call both write_game_config_to_default_directory and add_game_to_preferences_in_default_directory to get full TB config out of the box
#
  • write_game_config_to_default_directory takes a type registry now
#

Here's some maybe useful boilerplate:

#

Setup config:

/// Set up TrenchBroom so that it can create maps for our game.
/// This is intentionally not gated to dev builds so that players can edit the levels themselves if they want.
#[cfg(feature = "native")]
fn write_trenchbroom_config(server: Res<TrenchBroomServer>, type_registry: Res<AppTypeRegistry>) {
    info!("Writing TrenchBroom config");
    // Errors at this point usually mean that the player has not installed TrenchBroom.
    // The error messages give more details about the exact issue.
    if let Err(err) = server
        .config
        .write_game_config_to_default_directory(&type_registry.read())
    {
        warn!("Could not write TrenchBroom game config: {err}");
    }
    if let Err(err) = server.config.add_game_to_preferences_in_default_directory() {
        warn!("Could not add game to TrenchBroom preferences: {err}");
    }
}
#

world spawn:

app.register_type::<Worldspawn>();

#[derive(SolidClass, Component, Reflect, Default)]
#[reflect(Component, QuakeClass)]
#[geometry(GeometryProvider::new().convex_collider().smooth_by_default_angle())]
pub(crate) struct Worldspawn;
#

func_group:

app.register_type::<FuncGroup>();

#[derive(SolidClass, Component, Debug, Clone, Copy, Default, Reflect)]
#[base(Transform, Visibility)]
#[reflect(QuakeClass, Component, Default, Debug)]
#[geometry(GeometryProvider::new().convex_collider().smooth_by_default_angle())]
struct FuncGroup;
#

Some generic entity:

app.register_type::<Foo>();
app.add_observer(setup_foo);

#[derive(PointClass, Component, Debug, Reflect)]
#[reflect(QuakeClass, Component)]
#[base(Transform, Visibility)]
#[model("models/foo.gltf")]
#[spawn_hook(preload_model::<Self>)]
pub(crate) struct Foo;
#

Where the model path "models/foo.gltf" can be fetched in the rest of your code with Foo::CLASS_INFO.model_path().unwrap()

#

And setup_foo is just an OnAdd observer. There are also spawn hooks, but the only one I personally use is preload_model which starts loading the glTF when the app starts.

#

Pretty sure much of what I just wrote won't be new to you, but I thought it's better to write too much than too little 🙂

#

Oh, here's something else you might want:

pub(crate) trait GetTrenchbroomModelPath: QuakeClass {
    fn model_path() -> String {
        Self::CLASS_INFO.model_path().unwrap().to_string()
    }
    fn scene_path() -> String {
        format!("{file_path}#Scene0", file_path = Self::model_path())
    }
    fn animation_path(index: u32) -> String {
        format!(
            "{file_path}#Animation{index}",
            file_path = Self::model_path()
        )
    }
}

impl<T: QuakeClass> GetTrenchbroomModelPath for T {}

pub(crate) trait LoadTrenchbroomModel {
    fn load_trenchbroom_model<T: QuakeClass>(&self) -> Handle<Scene>;
}

impl LoadTrenchbroomModel for DeferredWorld<'_> {
    fn load_trenchbroom_model<T: QuakeClass>(&self) -> Handle<Scene> {
        self.resource::<AssetServer>().load_trenchbroom_model::<T>()
    }
}

impl LoadTrenchbroomModel for AssetServer {
    fn load_trenchbroom_model<T: QuakeClass>(&self) -> Handle<Scene> {
        self.load(T::scene_path())
    }
}

Allows you to do
let model = asset_server.load_trenchbroom_model::<Robot>();

urban zealot
# dry portal Trying to find the diffs to how I did stuff before using the examples: * do we h...

The project has gotten large enough that we probably should start writing a migration guide between versions.
Jan did a great job at explaining, to claify, the material files have had their default extension set to toml because the default material deserializer is TomlMaterialDeserializer, you can easily change it back if you want
Not sure what's happening with CI, the preloading test is failing on Github's side, but not on my machine, which will make troubleshooting rather annoying
I'll have a look into the misplaced colliders
I was sad to see builtin auto-registration go, but there are some annoying problems with platform compatibility we were facing with wasm, and we wanted to move it into the type registry anyway. There are existing and (as Jan says) up-coming solutions for auto-registration for the type registry. I'd look into those.

#

BTW Thanks @dim warren for summarizing the changes, how does Bevy handle migration guides? Is it just stuck in a big file somewhere?

dim warren
#

I personally try to never commit straight onto main, but try to do as much work in dedicated PRs as possible. Then I can just write the migration directly into the PR description. When it comes time to publish stuff, I just take a look at the autogenerated PR list GitHub gives me for the release and copy-paste the migrations

dim warren
urban zealot
urban zealot
dim warren
digital heath
# dim warren I *personally* try to never commit straight onto `main`, but try to do as much w...

I'm currently doing the same, i.e. copy migration guides from PRs when I do a GitHub release, and then do a manual clean-up pass to fix any outdated info and make things more cohesive. I'm considering switching to having migration guides in markdown files in-repo though, since some people have asked if there's an up-to-date migration guide or changelog before the release is out, such as in the release candidate stage when people often switch to using the main branch

#

We probably wouldn't need a file per "thing" like with Bevy, but rather e.g. a 0.3-to-0.4.md or 0.3-to-main.md file that is updated whenever breaking changes are made

dry portal
dry portal
dim warren
urban zealot
urban zealot
dry portal
urban zealot
dry portal
#

Awesome!! Will check in a few minutes!

#

Thanks so much 💙

dry portal
dry portal
#

So we could release 0.8? 🫣

urban zealot
dim warren
urban zealot
#

There's also bevy_flycam, but that's just for debugging and we can always just write our own

dry portal
lucid mantle
urban zealot
#

@dim warren If you have the time, could you try rolling the remove-geometry-provider branch for Foxtrot? (See the migration guide diff)
I just want to make sure it doesn't mess anything up in it before i merge the PR, and I'm sure you'll be much faster at migrating Foxtrot than I

dim warren
#

I'd advise you to only add that plugin if it was not already added

image.png
urban zealot
dim warren
#

oh whaat

#

TIL

#

Geometry looks correct 🙂

#

Here, in case you see something weird

#

But I think it's good 🎉

urban zealot
# dim warren

Oooh, haven't seen the level in a bit, looks cool!

dim warren
urban zealot
dim warren
#

Her main criticism of the process was that she needed to recompile the game to get new entities in her inspector, which took quite a while on her machine. I think next time, I'll do what @dry portal did and set up a symlink to a checked out file that one can just git pull

dim warren
#

Let's leave it as-is, I don't think this will annoy anyone and if it does, the fix is trivial (just don't add the plugin yourself or disable it in the group)

urban zealot
#

0.8.0 has been released!

gloomy fable
#

yay!

dry portal
dim warren
#

@urban zealot are brush entity rotations supposed to work on main? I think they're still broken right now

#

this is my test setup

image.png
#

And this is my spawn:

fn setup_light_window_brush_entity(
    trigger: Trigger<OnAdd, LightWindow>,
    brush_entity: Query<(&Transform, &Children), With<LightWindow>>,
    mut commands: Commands,
) {
    let entity = trigger.target();
    let Ok((transform, children)) = brush_entity.get(entity) else {
        return;
    };
    for brush in children.iter() {
        commands
            .entity(brush)
            .insert(children![(SpotLight {
                color: Color::srgb_u8(239, 173, 144),
                intensity: 200_000.0,
                radius: 0.1,
                shadows_enabled: true,
                #[cfg(feature = "native")]
                soft_shadows_enabled: true,
                ..default()
            },)])
            .queue(disable_shadow_casting);
    }
}
#

Note how I just spawn the spotlight as a child of the entity brush, as would assume it to point in the correct direction now

#

But this is how it looks in-game

#

Note how the light is pointing in the wrong direction

#

This is the Transform of the LightWindow:

image.png
#

This is the child holding the Mesh:

image.png
#

And this is the spot light itself:

image.png
#

Note the angles I used in TB are 270:

image.png
#

Oh wait, am I maybe not supposed to insert it as a child of the meshes? I see

#

Attempt 2:

fn setup_light_window_brush_entity(trigger: Trigger<OnAdd, LightWindow>, mut commands: Commands) {
    let entity = trigger.target();
    commands
        .entity(entity)
        .insert(children![(SpotLight {
            color: Color::srgb_u8(239, 173, 144),
            intensity: 200_000.0,
            radius: 0.1,
            shadows_enabled: true,
            #[cfg(feature = "native")]
            soft_shadows_enabled: true,
            ..default()
        },)])
        .queue(disable_shadow_casting);
}
#

Results in:

#

Light is correct

#

Not sure why the collider is over here though

#

Attempt 3:

fn setup_light_window_brush_entity(trigger: Trigger<OnAdd, LightWindow>, mut commands: Commands) {
    let entity = trigger.target();
    commands
        .entity(entity)
        .with_child(SpotLight {
            color: Color::srgb_u8(239, 173, 144),
            intensity: 200_000.0,
            radius: 0.1,
            shadows_enabled: true,
            #[cfg(feature = "native")]
            soft_shadows_enabled: true,
            ..default()
        })
        .queue(disable_shadow_casting);
}
#

Results in:

#

The light is correct, the mesh is correct (I intentionally placed the window like that for debugging), but the collider is rotated by 90 degrees around the origin brush

#

@dry portal I suppose your entity brushes with origins don't have a rotation?

dim warren
#

I'll stay on an earlier version until this is fixed then

dim warren
urban zealot
urban zealot
dim warren
#

sec

dim warren
urban zealot
dim warren
urban zealot
dry portal
dim warren
#

And just doing this triggers our bug:

urban zealot
dim warren
# 
fn setup_light_window_brush_entity(trigger: Trigger<OnAdd, LightWindow>, mut commands: Commands) {
    let entity = trigger.target();
    commands.entity(entity).insert(Children::default());
}
#

Results in:

image.png
#

(meshes are at origin)

dim warren
urban zealot
#

Neither does ChildOf though

dim warren
urban zealot
dim warren
#

That is useful when entities has some filter, e.g. entities: Query<Entity, (With<A>, With<B>, Without<Processed>)>

#

That way, this system will only execute once A and B have both been inserted into the entity

#

I don’t think BTB does anything like this, but if it did, it would explain it

dim warren
#

Idea: does children! override already pre-existing Children?

dim warren
#

@urban zealot little update: I ran this code:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .add_observer(on_parent_added_with_child)
        //.add_observer(on_parent_added_children)
        .add_systems(Update, print_hierarchy)
        .run();
}

#[derive(Component)]
struct Parent;

#[derive(Component)]
struct Child1;

#[derive(Component)]
struct Child2;

fn setup(world: &mut World) {
    let parent = world.spawn((Parent, Name::new("Parent"))).id();
    let child = world.spawn((Child1, Name::new("Child1"))).id();
    world.entity_mut(child).insert(ChildOf(parent));
}

fn on_parent_added_with_child(trigger: Trigger<OnAdd, Parent>, mut commands: Commands) {
    let parent = trigger.target();
    commands
        .entity(parent)
        .with_child((Child2, Name::new("Child2")));
}

fn on_parent_added_children(trigger: Trigger<OnAdd, Parent>, mut commands: Commands) {
    let parent = trigger.target();
    commands
        .entity(parent)
        .insert(children![Child2, Name::new("Child2")]);
}

fn print_hierarchy(
    parent: Single<Entity, With<Parent>>,
    children: Query<&Children>,
    names: Query<NameOrEntity>,
) {
    println!("{}", names.get(*parent).unwrap());
    for child in children.get(*parent).unwrap() {
        println!("  {}", names.get(*child).unwrap());
    }
    panic!("Done");
}
#

Running this, I get the following hierarchy with on_parent_added_with_child:

  • Parent
    • Child2
    • Child1
#

But using on_parent_added_children:

  • Parent
    • 8v1
    • Child2
    • Child1
#

There's an extra element in there hmm

#

But children definitly does not override past children, it appends new ones

urban zealot
# dim warren

Huh, well i appreciate you looking into this
I tried flushing commands before/after every spawner and nothing changed

dim warren
#

children! is new in 0.16, so reporting this bug now may lead to a fix in 0.16.1

#

but I struggle creating a minimal reproducible example

upper scroll
#

Anyone know why writing the game config might get deadlocked?

dim warren
#

Or maybe your OS is restricting the app from accessing the directory

upper scroll
#

It worked the first time, it might be locked...

dim warren
dim warren
#

btw, I got a commision to write something about 3D gamedev with Bevy, and I'd like to dedicate a chapter to BTB.
I believe the new attribute stuff got merged, right? 😄

#

If so, is there anything else of note that I should wait for before digging in?

#

No rush, I first need to finish my recastnavigation port

urban zealot
urban zealot
dim warren
#

Going through the open issues right now

#

If you don't get to it first, haha

urban zealot
#

I just don't know i would tackle it to be honest

dim warren
#

Add a #[ignore("blabla") to it

#

or was it #[ignored]?

dim warren
#

Been a while

urban zealot
dim warren
urban zealot
dim warren
dim warren
dim warren
dim warren
#

I'm so proud of this little crate for sniping half of all maintainers into discussing ergonomics haha

dim warren
#

This is cursed, but I believe this would fix our problems in a very unobtrusive way in case 0.17 doesn’t ship with nice semantics 👀

#

Reminder for self: change bevy_fix_gltf to this abomination

foggy glade
#

hey! could I get a hand lent into loading textures?

#

I guess it's not even a bevy_trenchbroom question, but more of a Trenchbroom question

#

maybe I should have a deeper look at the manual but I couldn't find much info besides creating a texture/ directory in the game_path

#

(which is not working?)

#

OOOOOOOH

#

Wait after loading bevy a new game engine appeared in the settings

#

when I opened trenchbroom for the first time bevy wasn't there

#

okay, I guess that did something but my .png is still not loading as a texture

#

😭

#

ima try to read this chat, because discord doesn't allow searchind inside an specific thread

#

Okay, it just needed to go into the assets/ folder instead of /

dim warren
foggy glade
#

I've got another question

#

I noticed by your talk that the way you attach properties to a point_class is by... well... the way you showed on the slide

#

with an observer and a trigger function

#

and I figured that for solid_classes it might be the exact same

#

and yeah, it works

dim warren
#

The collider is probably missing?

foggy glade
#

but how do I do it for non-point non-solid meshes?

#

no no, that code works perfectly fine

#

Im wondering how do I add components to the default meshes

#

that arent assigned anything

#

So the grey and blue

#

how would I give them components like the collider

dim warren
foggy glade
#

oh, so I can do the observertrigger pattern to worldspawn?

dim warren
#

There’s an annotation there that says to add colliders to that

#

See my slide where I show Worldspawn

foggy glade
#

oh the "convex_collider" part

dim warren
#

Ding ding ding!

foggy glade
#

handy but

#

how would I add custom properties?

#

is it non-trivial?

dim warren
# foggy glade how would I add custom properties?

Hmm, not sure if Worldspawn is allowed to have extra properties. If so, they would not be separate for the gray and blue area, but kinda global.
The idiomatic way is to use brush entities, like you did for the orange stuff

#

What exactly are you trying to achieve?

foggy glade
#

yeah, I assumed they would be the same for both gray and blue

#

but I'm not really trying to achieve anything yet

#

just getting comfy with the tool

dim warren
#

alright, makes sense then 🙂

foggy glade
dim warren
#

I recommend using inspector_egui to check out the hierarchy generated by bevy_trenchbroom. It made it much clearer to me how brushes were handled when I first started!

foggy glade
#

has the trenchbroom prelude changed recently?

dim warren
#

But my slides use the latest release

#

lol nvm

image.png
foggy glade
#

bevy_trenchbroom = { version = "0.9.1", features = ["avian"] }

#

I mean

dim warren
#

@urban zealot I didn't notice you already published the release haha

foggy glade
#

oh okay

#

hahahah

dim warren
#

yeah never mind my slides then hahahah

foggy glade
#

yeah that clears a big chunk of my confusion

#

I mind them a lot in fact

#

hahaha

dim warren
foggy glade
#

but Im glad the crate keeps evolving

#

WOAH that looks so much tiddy

#

tiddier?

dim warren
foggy glade
#

hah

dim warren
#

MUCH less boilerplate hehe

#

looks great 😄

#

Just noticed something 👀
I believe spawnflags could be used for Avian physics layers

image.png
foggy glade
#

TrenchBroomConfig writing now happens automatically with WriteTrenchBroomConfigOnStartPlugin. If you're writing out your config on startup, you can remove that system. If not, disable WriteTrenchBroomConfigOnStartPlugin through TrenchBroomPlugins.

#

does this mean I can remove this?

#

neat

dim warren
dim warren
foggy glade
#

it even returns the value so that you can keep chainin

#

Rust has been getting so much nicer lately

dim warren
foggy glade
#

I have a weird issue thonk

#

oh wait

#

nvm I dont

#

its just working perfectly

#

love to solve things just when I say them out loud

#

thanks for the help, I think I'm on the right path now

dim warren
#

Hehe

foggy glade
#

well I've in fact noticed a problem

#

but its related to probably rendering

#

notice the shadow casted on the plane mesh

#

it's flickery af

#

while the ones on the other meshes are completely smooth

urban zealot
# foggy glade how would I add custom properties?

Hello!! idk if you've solved this yet, but a bunch of entities (like worldspawn) are builtin, you can totally add more properties to them, you just have to define them yourself (feel free to just copy them) and .override_class::<T>()

urban zealot
dim warren
dim warren
foggy glade
#

nop

# 
    // Light
    commands.spawn((
        PointLight {
            intensity: 10000000.0,
            range: 999999999.0,
            shadows_enabled: true,
            ..default()
        },
        Transform::from_xyz(4.0, 20.0, 4.0),
    ));
dim warren
foggy glade
#

a ain't skimming

#

😂

dim warren
#

Just FYI, rendering is massively slower when you have lights with overlapping ranges on screen

#

So this will slow down to a crawl if you use 20 or so lights with that setting 😛

foggy glade
#

yeah, it goes exponential

dim warren
#

But yeah no clue about that rendering artifact, sorry

foggy glade
#

I just put it there to light the whole scene and not worry about it

dim warren
#

Might have to ask #rendering

foggy glade
#

I just asked

#

and they told me it is in fact normal

dim warren
#

ha, interesting

foggy glade
#

I dont really mind it anyway

#

im not gona use textureless meshes

#

and I'm gonna write a pixel-art shader

#

so a non-issue

#

aww

#

I was expecting checkboxes and radiobuttons

dim warren
#

There should be 👀

dim warren
#

Click on the number

dim warren
#

disclaimer: this was not generated with bevy_trenchbroom, this is from opening up a Quake map

foggy glade
#

hmmmm

#

is this wrong?

urban zealot
foggy glade
#

I would if I knew what that was

#

hahaha

#

maybe I should restart trenchbroom

#

?

#

nope, that wasn't it

urban zealot
foggy glade
#

tell me what the fgd is and I send it to you

urban zealot
#

/games/your_game/your_game.fgd

foggy glade
urban zealot
#

FGD looks good too

foggy glade
urban zealot
#

What version of TrenchBroom are you using?

foggy glade
#

2025.3

urban zealot
#

yeah i got nothing then

foggy glade
#

hahahaha don't worry

#

maybe it's because its the worldspawn?

#

@SolidClass base(worldspawn) = worldspawn

urban zealot
foggy glade
#

this looks like it could cause problems?

#

I assume its because of this

urban zealot
foggy glade
#

included the import

urban zealot
#

Ohh, there should be an error in the console telling you that 2 classes have the same name

foggy glade
#

Uh

#

this may be it

#

yeah

#

line 107

urban zealot
#

I meant Bevy console but that tells you too :)

foggy glade
#

checks out

urban zealot
#

Just remove the BaseWorldspawn

foggy glade
#

bevy console is clear

urban zealot
#

I'm too tired to track that down rn

foggy glade
#

hahahahah

#

don't worry

urban zealot
#

At least we got to the bottom of it

foggy glade
#

I'm glad I brought it to your attention tho, so you can fix it when you have time

urban zealot
#

indeed

foggy glade
#

however one question, what did the documentation mean then?

urban zealot
#

?

foggy glade
#

Here

#

the migration guide

#

sorry

urban zealot
#

BspWorldspawn has some compiler properties if you want to use .bsp files

#

If you're just using .map files you don't need any base classes

foggy glade
#

Oh

urban zealot
#

goated theme

foggy glade
#

helix catpuccin

#

heh

urban zealot
#

dang helix

#

nice

foggy glade
#

I've been considering switching to nvim so many times

#

but helix just works too well

#

for 99% of usecases

#

without any trouble

#

so.... I can't be bothered to care

urban zealot
#

Same, back when i trying using terminal editors i even put together an entire nvim config

#

but helix is just so already set up

#

never could get into it though for everyday use

#

maybe one day

foggy glade
#

Yeeeeeeees

#

its working now

#

I also had multiple tries in the past

#

with terminal editors

#

it never worked until I went FULL terminal

#

nowadays I basically just use Slack, a web browser, Discord and a couple of other things outside of the terminal

#

so it makes sense, having nix also helps with it

foggy glade
#

Would you say this is an Avian or a Trenchbroom issue?

#

For some reason when rotating brushes the collisions basically go crazy on spawn

#

This is all I'm doingto the colliders so it definitely isn't on my side

#

I'm so puzzled by this lmao

#

@digital heath any idea about what it could be?

foggy glade
#

huh

#

it happens when two brushes touch in that direction

#

weird af what

#

as you can see, all the geometries are stable but the ones that touch on that axis

#

this looks more like an avian issue now

#

but im still pretty lost