-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(nav): Gen3 Navigation policies and factory #3760
feat(nav): Gen3 Navigation policies and factory #3760
Conversation
Their lifetime needs to be controlled
@asalzburger I'm making some changes to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some general comments and questions about the logic from my side
After discussion with @andiwand, I refactored the interface of the function contained in the I'm also wrapping the navigation stream into a separate wrapper object called This is to be complemented (in a future PR) with a method like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that makes a lot of sense!
Lets get this in!
CI is green now @andiwand |
Quality Gate passedIssues Measures |
Terminology: - "Navigation delegate": the function that is registered with a tracking volume. In principle, this can be anything - "Navigation policy": the object that is registered with the tracking volume. It contains a method that is connected to the "navigation delegate". It has extra methods - "Navigation policy factory": To delay construction of the actual policy object **until after** the volume is fully sized and has all of its internal structure registered, the blueprint tree only contains *navigation policy factories*. This is configurable. During construction, the factory is applied to volumes, and produces a policy that is registered with the volume. This is called "navigation policy factory" from a conceptual point of view. - "MultiNavigationPolicy": chains together multiple policies in a sort of composition. You can have one policy that only deals with portals, one for sensitive and one for passive surfaces, for example. - To make this less annoying to construct, as you would have to manage the factory, I'm adding a concrete class `NavigationPolicyFactory`. Its job is to make defining a factory that produces a "MultiNavigationPolicy" easy, like: ```cpp using namespace Acts; using SurfaceArrayNavigationPolicy::LayerType; SurfaceArrayNavigationPolicy::Config config{ .layerType = LayerType::Cylinder, .bins = {10, 10} }; auto factory = NavigationPolicyFactory::make() .add<TryAllPortalNavigationPolicy>() .add<SurfaceArrayNavigationPolicy>(config); ``` or in python: ```python policy = ( acts.NavigationPolicyFactory.make() .add(acts.TryAllPortalNavigationPolicy) .add(acts.TryAllSurfaceNavigationPolicy) .add( acts.SurfaceArrayNavigationPolicy, acts.SurfaceArrayNavigationPolicy.Config( layerType=acts.SurfaceArrayNavigationPolicy.LayerType.Plane, bins=(10, 10), ), ) ) ``` Part of acts-project#3502
Terminology:
NavigationPolicyFactory
. Its job is to make defining a factory that produces a "MultiNavigationPolicy" easy, like:Part of #3502