Closes #1854. Previously attempted in #1888.

We should think about how to coordinate this with #3412. @HackerFoo, do you have a preference?

We should think about how to coordinate this with #3412. @HackerFoo, do you have a preference?

I'd like #3412 and #3568 to be considered, because they make it useful to run the draw_3d_graph subgraph on multiple cameras. It would be useful to attach some identifier to the types, to somehow control the layering order, and make other minor modifications to passes. I might have more feedback after reading through this PR.

I also have an idea for specifying the pass order in Camera, to allow e.g. skyboxes (behind everything else) and UI layers (in front.)

We should think about how to coordinate this with #3412. HackerFoo, do you have a preference?

Rebasing one on top of the other once it is merged shouldnt be too hard, the changes are in similar code paths but are mostly unrelated.

This is looking much cleaner. I'm really happy to see this finally get cleaned up. Just a few nits :)

do we need a replacement for ActiveCameras? What about a component ActiveCamera { is_active: bool } similar to Visibility?

And here’s another instance of the same question. I’ve seen this 4 times in the past two days. :) @mockersf suggested adding enable/disable for lights while I was doing some other things but it’s not trivial imo because of the question of whether to have something like a ZST for the less likely case (i.e. an empty InactiveCamera component) which introduces archetype fragmentation but is directly queryable, or always adding an ActiveCamera { is_active: bool } component and forcing visiting all entities just to find one or the other subset, and always using the storage for the component. @cart suggested adding Visibility to the light bundles but Visibility feels like the wrong property for lights. I felt like something more generically usable everywhere like Enabled { is_enabled: bool } or Active { is_active: bool } or some better name, for all cases. Visibility, lights being enabled, cameras being active, whatever. And then when we make an editor there is one component that handles them all in a sensible and consistent way. But, I didn’t proceed because there’s still the question of the component with a bool member or the marker component for the less likely case. It feels like marker components should be used only where iteration performance is a top priority because I fear the combinatoric explosion and subsequent fragmentation if we use too many marker components… :/ I don’t know

I felt like something more generically usable everywhere like Enabled { is_enabled: bool } or Active { is_active: bool } or some better name, for all cases

I'm in favor of this: being able to standardize the ecosystem around this pattern is super useful.

But, I didn’t proceed because there’s still the question of the component with a bool member or the marker component for the less likely case. It feels like marker components should be used only where iteration performance is a top priority because I fear the combinatoric explosion and subsequent fragmentation if we use too many marker components… :/

So, IMO archetype fragmentation is less important performance-wise than the requirement to constantly check values. I'd prefer a marker component: if we use sparse-set storage it'll be faster to add and remove too. I would be fine with either Enabled/Active or Disabled/Inactive as the marker, depending on which pattern you think is clearer / more useful for your rendering use cases.

Overall I think a Inactive marker component is going to be the clearest for debugging purposes, and the most natural to reuse in other contexts. I'd probably toss it in bevy_ecs; it'll be reused all over the place.

How about RenderLayers::none() to disable a camera? That should already work, but maybe isn't optimized. I like RenderLayers because you can define complex relations between cameras and renderable entities.

Similar mechanisms are used for physics (e.g. in Rapier.)

It would be useful to attach some identifier to the types

I suppose this could be done with some other component if needed.