Navimesh child transforms

[OhKannaDuh]

Kawari/tools/navimesh/src/main.rs

Lines 480 to 488 in 4e98cd7

	let child_transform = Transformation {
	translation: [
	transform.translation[0] + object.transform.translation[0],
	transform.translation[1] + object.transform.translation[1],
	transform.translation[2] + object.transform.translation[2],
	],
	rotation: object.transform.rotation,
	scale: object.transform.scale,
	};

This is my favourite comment in the repo.

I'd suggest using a library like glam for matrix maths, it's still nice and fast.

fn physis_transform_to_affine3a(transformation: &Transformation) -> Affine3A {
    let translation = Vec3::from(transformation.translation);
    let scale = Vec3::from(transformation.scale);

    let rotation = Quat::from_euler(
        EulerRot::XYZ,
        transformation.rotation[0],
        transformation.rotation[1],
        transformation.rotation[2],
    );

    Affine3A::from_scale_rotation_translation(scale, rotation, translation)
}

    pub fn process_layer(&mut self, layer: &Layer, world: Affine3A) -> MeshCollection {
        let mut collection = MeshCollection::default();

        for object in &layer.objects {
            let local = world * physis_transform_to_affine3a(&object.transform);
...

let meshes = layer_processor.process_layer(layer, Affine3A::IDENTITY);

That's some similar code I've used in the past.

[redstrate]

Yes I noticed this is a re-occurring problem:

• Kawari's navmesh generation (and possibly some parts of LGB parsing, but I don't think so yet?)
• Novus map tooling which does the same thing - it at least does it properly
• Pretty much any other tool built on top of Physis

I'm unsure if I want to move this kind of helper into Physis, but we should definitely do it correctly in Kawari at least!

[OhKannaDuh]

I wouldn't put it in Physis because that shouldn't be opinionated like this, but Kawari could benefit from something like it. I did try shoving my own navmesh generation stuff into Kawari to test, but my exports of that always resulted in subpar navmeshes when compared to what I was generating in my own tool. I'm not sure if that's something to do with the different recast params used or something else

[redstrate]

I wouldn't call it opinionated as there's only one correct way to do child transformation, but it's probably more of a "out of scope" thing and left up to the library consumer.

I'm not sure if that's something to do with the different recast params used or something else

Yeah it's probably that, recast is extremely picky and while the current navmesh isn't perfect still it's basically a ton of trial and error...

[OhKannaDuh]

Although, even taking the default params from the RecastNavimesh sheet, I seem to get good results. I might try serializing the navmesh in my app to the format you've made for Kawari and seeing if by some chance that works as expected. At least that'll give me some perspective if something weird is happening during Kawari's generation, deserialization, or my own serialization when I was writing the data to the obj format from Kawari.

I had my own hell of trail and error getting navmesh to generate using ffxivs level data.

[redstrate]

Question: do you have any interest in replacing our custom primitives (Position) with the glam crate in Kawari? Otherwise I can do it myself, but wondering if you wanted to make an appreciated contribution :)

[OhKannaDuh]

I'm not against doing it (If I find the time), I'll let you know if I start so we don't overlay. And likewise if you start let me know