How can i create a custom builtin without forking/hacking this whole crate ?

[ethereumdegen]

How can i create a custom builtin without forking/hacking this whole crate ?

I would like to create a custom builtin in my own code, just by importing sub-modules of this crate. However many of them that i (most likely) need are private or private private.

Is there an example of how i can create a custom builtin easily? I want a builtin for hover/fly/climb

[idanarye]

First, to get the terminology out of the way - "custom builtin" is an oxymoron. The "builtin" part in the name of TnuaBuilinWalk and friends is to indicate that these movement commands are built into Tnua - as opposed to custom movement commands that the user can create.

So what you are trying to make is custom movement commands - or, more specifically, custom basis and/or custom actions.

Now, the whole basis/action system was designed to allow users (or, more likely, third party crates) create their own basis and actions (okay, that's not exactly accurate - the original goal was to allow organizing the code for the various movement commands without having to use huge types and functions. But user customization was always an important goal of Tnua). So in theory you should be able to impl TnuaBasis or impl TnuaAction for your own types, and if you can't then this is a bug that I'll need to fix.

What have you tried, and what did you get stuck on?

[idanarye]

Also, do you mind if I move this to Discussions? It feel like its going to be more of a Q&A thing (though I may end up adding things to the code, if it turns out it's not as extendable as I thought)

[ethereumdegen]

well i tried that but look

[ethereumdegen]

These squiggly red lines are what im talking about. These are preventing me from making a custom basis without forking and hacking up the whole crate

[idanarye]

I see...

• bevy_tnua_physics_integration_layer is a crate you need to add as a dependency. I can stand to re-export it if it'll make things easier (or maybe just re-export its math module?)
• TnuaBasisContext is reexported as bevy_tnua::TnuaBasisContext. Maybe I can change the code of walk itself to use it from there, to make things easier for those copying from the builtin movement commands source code.
• bevy_tnua::util is the only one that's really private. I guess the things there kind of are useful, so I don't mind making it public.

Okay, I won't move this to discussions because there really are some things I need to change.

[idanarye]

bevy_tnua_physics_integration_layer is a crate you need to add as a dependency. I can stand to re-export it if it'll make things easier (or maybe just re-export its math module?)

Wait, I think I already do that:

pub use bevy_tnua_physics_integration_layer::data_for_backends::*;
pub use bevy_tnua_physics_integration_layer::*;

So I just need to change the builtin movement commands' code to import from there.

[idanarye]

@ethereumdegen Can you try the fix-52-improve-extensibility branch? I think you'll have to use all the Tnua crates from there. I'm not 100% about the syntax, but I think if you just give them the proper name it'll look for subcrates inside the workspace:

[dependencies]
bevy-tnua = { git = "https://github.com/idanarye/bevy-tnua", branch = "fix-52-improve-extensibility" }
# Use the proper physics backend, of course:
bevy-tnua-xpbd3d = { git = "https://github.com/idanarye/bevy-tnua", branch = "fix-52-improve-extensibility" }

[ethereumdegen]

okay thanks that makes more sense i kind of fixed w OG branch except i reimplemented ProjectionPlaneForRotation and the Math typs (vector3, float) for now . I will dive in to your branch too.

My new deps look like this :

use super::math::{Vector3,Float,AdjustPrecision}; //reimplemented myself for now use bevy_tnua::TnuaBasisContext;

use bevy::prelude::*; use bevy_tnua::TnuaMotor;

//use bevy_tnua::util::ProjectionPlaneForRotation; // need to remake myself use bevy_tnua::{TnuaBasis, TnuaVelChange};

[idanarye]

Did you try fix-52-improve-extensibility? It exports bevy_tnua::util so you can use my implementation of ProjectionPlaneForRotation, and it reexports math as bevy_tnua::math so you can use that (note that it's only needed if you want to support both f32 and f64. Which you probably would for a third party library, but if you are making an actual game you'd want to pick one or the other)

If that branch works for you, I can make a release tomorrow (I still want to write docs for bevy_tnua::util if it's going to be public)

[idanarye]

@ethereumdegen I've added some more changes to fix-52-improve-extensibility to make it easier to use (these things were previously intended for internal usage only). Please check if it satisfies your code's needs before I merge it and make a release.

[idanarye]

The more I think about it, the more I hate the idea of making ProjectionPlaneForRotation public. I only ever create it for the identity orientation, and it's probably going to break for non-standard orientation. Which I should probably remove (I've opened #53) for that.

If the orientation is standard, rotation_to_set_forward could just be a standalone function.

[idanarye]

@ethereumdegen Version 0.17 is out, and should have everything you need.