Migrate examples using text based UI to feathers

[IceSentry]

Many old examples used a combination of text and hardcoded key presses as a UI because bevy_ui was too much trouble. Now that we have feathers and bsn we can migrate them to use an actual UI.

Here's a list of all the rendering related examples using this pattern sorted by how many controls would need to be migrated.

Low - only 1 control to migrate

• 3d/clearcoat.rs
• 3d/occlusion_culling.rs
• 3d/specular_tint.rs

Medium - 2 to 4 controls to migrate

• 2d/2d_shapes.rs
• 2d/wireframe_2d.rs
• 3d/3d_shapes.rs
• 3d/anisotropy.rs
• 3d/atmospheric_fog.rs
• 3d/auto_exposure.rs
• 3d/blend_modes.rs
• 3d/deferred_rendering.rs
• 3d/depth_of_field.rs
• 3d/generate_custom_mesh.rs
• 3d/irradiance_volumes.rs
• 3d/motion_blur.rs
• 3d/parallax_mapping.rs
• 3d/post_processing.rs
• 3d/rect_light.rs
• 3d/reflection_probes.rs
• 3d/solari.rs
• 3d/ssao.rs
• 3d/visibility_range.rs
• 3d/volumetric_fog.rs
• gizmos/light_gizmos.rs
• gizmos/transform_gizmo.rs

High - 5 or more controls to migrate

• 2d/bloom_2d.rs
• 3d/anti_aliasing.rs
• 3d/bloom_3d.rs
• 3d/fog.rs
• 3d/lighting.rs
• 3d/shadow_biases.rs
• 3d/tonemapping.rs
• 3d/transmission.rs
• 3d/wireframe.rs
• gizmos/2d_gizmos.rs
• gizmos/3d_gizmos.rs

This is not an exhaustive list, there's likely more than that.

[viridia]

I assume that most of these are toggles? Perhaps we could invent some helper abstraction that would cut down the boilerplate even further.

[IceSentry]

I assume that most of these are toggles

Not really, a lot of them are essentially sliders. Many of them would also work well as radio buttons. There's definitely some toggles and just simple buttons too.

[IceSentry]

When I say sliders it could also be any kind of input for a floating point number

[viridia]

Ok, so we want to keep the amount of ui boilerplate in the example to a minimum, so that it doesn't distract from what we are trying to teach. However, we can put complicated stuff in a helper library that is outside of the example.

So we could envision a super-minimal reflection-based property editor that supports f32, i32 and boolean fields. In each example, you declare a struct for all of your on-screen options, along with annotations that give the human-readable name of each option, as well as range where appropriate. This won't support complex data types or recursion. This puts up a little floating panel, possibly with a minimize button, on the top left of the screen, and just runs through the struct using the reflection API and spawn a widget for each property.

So basically the example has no ui code in it at all, other than installing the plugin and declaring what properties you want to edit.

[IceSentry]

Many of these examples, especially the ones in the high category are already filled with state management so I wouldn't block on an abstraction just for that.

With that said, yeah, something like you are suggesting would be more than enough for most of these examples. I would add some kind of enum dropdown in your list of things it could support though.