# Objective
- The `OrthographicCameraBundle` constructor for 2d cameras uses a hardcoded value for Z position and scale of the camera. It could be useful to be able to customize these values.
## Solution
- Add a new constructor `custom_2d` that takes `far` (Z position) and `scale` as parameters. The default constructor `new_2d` uses this constructor with `far = 1000.0` and `scale = 1.0`.
A couple more uncontroversial changes extracted from #3886.
* Enable full feature of syn
It is necessary for the ItemFn and ItemTrait type. Currently it is indirectly
enabled through the tracing dependency of bevy_utils, but this may no
longer be the case in the future.
* Remove unused function from bevy_macro_utils
# Objective
- Part of the splitting process of #3692.
## Solution
- Add more tests to `input.rs` inside of `bevy_input`.
## Note
- The tests would now catch a change like #4410 and fail accordingly.
# Objective
- Debug logs are useful in release builds, but `tracing` logs are hard-capped (`release_max_level_info`) at the `info` level by `bevy_utils`.
## Solution
- This PR simply removes the limit in `bevy_utils` with no further actions.
- If any out-of-the box performance regressions arise, the steps to enable this `tracing` feature should be documented in a user guide in the future.
This PR closes#4069 and closes#1206.
## Alternatives considered
- Instruct the user to build with `debug-assertions` enabled: this is just a workaround, as it obviously enables all `debug-assertions` that affect more than logging itself.
- Re-exporting the feature from `tracing` and enabling it by default: I believe it just adds complexity and confusion, the `tracing` feature can also be re-enabled with one line in userland.
---
## Changelog
### Fixed
- Log level is not hard capped at `info` for release builds anymore.
## Migration Guide
- Maximum log levels for release builds is not enforced by Bevy anymore, to omit "debug" and "trace" level logs entirely from release builds, `tracing` must be added as a dependency with its `release_max_level_info` feature enabled in `Cargo.toml`. (`tracing = { version = "0.1", features = ["release_max_level_info"] }`)
# Objective
To test systems that implement frame rate-independent update logic, one needs to be able to mock `Time`. By mocking time, it's possible to write tests that confirm systems are frame rate-independent.
This is a follow-up PR to #2549 by @ostwilkens and based on his work.
## Solution
To mock `Time`, one needs to be able to manually update the Time resource with an `Instant` defined by the developer. This can be achieved by making the existing `Time::update_with_instant` method public for use in tests.
## Changelog
- Make `Time::update_with_instant` public
- Add doc to `Time::update_with_instant` clarifying that the method should not be called outside of tests.
- Add doc test to `Time` demonstrating how to use `update_with_instant` in tests.
Co-authored-by: Martin Dickopp <martin@zero-based.org>
# Objective
- The single threaded task pool is not documented
- This doesn't warn in CI as it's feature gated for wasm, but I'm tired of seeing the warnings when building in wasm
## Solution
- Document it
# Objective
- The strategy for delegation has changed!
- Figuring out exactly where the "controversial" line is can be challenging
## Solution
- Update the CONTRIBUTING.md
- Specify rough guidelines for what makes a PR controversial.
- BONUS: yeet references to old roadmap.
# Objective
- Part of the splitting process of #3692.
## Solution
- Rename `ElementState` to `ButtonState`
## Reasons
- The old name was too generic.
- If something can be pressed it is automatically button-like (thanks to @alice-i-cecile for bringing it up in #3692).
- The reason it is called `ElementState` is because that's how `winit` calls it.
- It is used to define if a keyboard or mouse **button** is pressed or not.
- Discussion in #3692.
## Changelog
### Changed
- The `ElementState` type received a rename and is now called `ButtonState`.
## Migration Guide
- The `ElementState` type received a rename and is now called `ButtonState`. To migrate you just have to change every occurrence of `ElementState` to `ButtonState`.
Co-authored-by: KDecay <KDecayMusic@protonmail.com>
# Objective
- related to #4575, but not a complete fix
- links to GitHub.com can't be checked from inside a GitHub Actions as GitHub is protecting itself from being flooded by an action execution
- it seems they added that protection to GitHub doc site
## Solution
- Ignore links to docs.github.com
# Objective
`AsSystemLabel` has been introduced on system descriptors to make ordering systems more convenient, but `SystemSet::before` and `SystemSet::after` still take `SystemLabels` directly:
use bevy::ecs::system::AsSystemLabel;
/*…*/ SystemSet::new().before(foo.as_system_label()) /*…*/
is currently necessary instead of
/*…*/ SystemSet::new().before(foo) /*…*/
## Solution
Use `AsSystemLabel` for `SystemSet`
The only way to soundly use this API is already encapsulated within `EntityMut::get`, so this api is removed.
# Migration guide
Replace calls to `EntityMut::get_unchecked` with calls to `EntityMut::get`.
# Objective
When using `derive(WorldQuery)`, then clippy complains with the following:
```rust
warning: missing documentation for a struct
--> src\wild_boar_type\marker_vital_status.rs:35:17
|
35 | #[derive(Debug, WorldQuery)]
| ^^^^^^^^^^
|
= note: this warning originates in the derive macro `WorldQuery` (in Nightly builds, run with -Z macro-backtrace for more info)
```
## Solution
* Either `#[doc(hidden)]` or
* Add a generic documentation line to it.
I don't know what is preferred, but I'd gladly add it in here.
# Objective
- The current API docs of `Commands` is very short and is very opaque to newcomers.
## Solution
- Try to explain what it is without requiring knowledge of other parts of `bevy_ecs` like `World` or `SystemParam`.
Co-authored-by: Charles <IceSentry@users.noreply.github.com>
Free at last!
# Objective
- Using `.system()` is no longer needed anywhere, and anyone using it will have already gotten a deprecation warning.
- https://github.com/bevyengine/bevy/pull/3302 was a super special case for `.system()`, since it was so prevelant. However, that's no reason.
- Despite it being deprecated, another couple of uses of it have already landed, including in the deprecating PR.
- These have all been because of doc examples having warnings not breaking CI - 🎟️?
## Solution
- Remove it.
- It's gone
---
## Changelog
- You can no longer use `.system()`
## Migration Guide
- You can no longer use `.system()`. It was deprecated in 0.7.0, and you should have followed the deprecation warning then. You can just remove the method call.
![image](https://user-images.githubusercontent.com/36049421/163688197-3e774a04-6f8f-40a6-b7a4-1330e0b7acf0.png)
- Thanks to the @TheRawMeatball for producing
# Objective
We are currently asking contributors to "skip" optional sections, which is a bit confusing. "Skip" can be taken to mean that you should "leave that section alone" and result in these bits of template being left in the PR description.
## Solution
Let contributors know that it's okay to delete the section if it's not needed.
# Objective
- Fix `ClusterConfig::None`
- This fix is from @robtfm but they didn't have time to submit it, so I am.
## Solution
- Always clear clusters and skip processing when `ClusterConfig::None`
- Conditionally remove `VisiblePointLights` from the view if it is present
# Objective
- https://github.com/bevyengine/bevy/pull/4098 still hasn't fixed minimisation on Windows.
- `Clusters.lights` is assumed to have the number of items given by the product of `Clusters.dimensions`'s axes.
## Solution
- Make that true in `clear`.
# Objective
- Fixes#4234
- Fixes#4473
- Built on top of #3989
- Improve performance of `assign_lights_to_clusters`
## Solution
- Remove the OBB-based cluster light assignment algorithm and calculation of view space AABBs
- Implement the 'iterative sphere refinement' algorithm used in Just Cause 3 by Emil Persson as documented in the Siggraph 2015 Practical Clustered Shading talk by Persson, on pages 42-44 http://newq.net/dl/pub/s2015_practical.pdf
- Adapt to also support orthographic projections
- Add `many_lights -- orthographic` for testing many lights using an orthographic projection
## Results
- `assign_lights_to_clusters` in `many_lights` before this PR on an M1 Max over 1500 frames had a median execution time of 1.71ms. With this PR it is 1.51ms, a reduction of 0.2ms or 11.7% for this system.
---
## Changelog
- Changed: Improved cluster light assignment performance
Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
- in #3851, a feature for tracing was added to bevy_transform
- usage of that feature was moved to bevy_hierarchy, but the feature was not updated
## Solution
- add the feature to bevy_hierarchy, remove it from bevy_transform
# Objective
Continue the effort to clean up this example
## Solution
- Store contributor name as component to avoid awkward vec of tuples
- Name the variable storing the Random Number Generator "rng"
- Use init_resource for resource implementing default
- Fix a few spots where an Entity was unnecessarily referenced and immediately dereferenced
- Fix up an awkward comment
# Objective
- Provide more information when despawning an entity
## Solution
- Add a debug log when despawning an entity
- Add spans to the recursive ways of despawning an entity
```sh
RUST_LOG=debug cargo run --example panic --features trace
# RUST_LOG=debug needed to show debug logs from bevy_ecs
# --features trace needed to have the extra spans
...
DEBUG bevy_app:frame:stage{name=Update}:system_commands{name="panic::despawn_parent"}:command{name="DespawnRecursive" entity=0v0}: bevy_ecs::world: Despawning entity 1v0
DEBUG bevy_app:frame:stage{name=Update}:system_commands{name="panic::despawn_parent"}:command{name="DespawnRecursive" entity=0v0}: bevy_ecs::world: Despawning entity 0v0
```
## Objective
Fixes#4122.
## Solution
Inherit the visibility of the struct being derived for the `xxItem`, `xxFetch`, `xxState` structs.
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
The documentation of the `Time::last_update` and `Time::time_since_startup` methods contains typos. It uses apostrophe instead of backtick characters around `Instant` and `Duration`, so that these words are not recognized as identifiers in the generated API documentation. This should be fixed.
## Solution
Fix the typos.
# Objective
Fixes https://github.com/bevyengine/bevy/issues/3499
## Solution
Uses a `HashMap` from `RenderTarget` to sampled textures when preparing `ViewTarget`s to ensure that two passes with the same render target get sampled to the same texture.
This builds on and depends on https://github.com/bevyengine/bevy/pull/3412, so this will be a draft PR until #3412 is merged. All changes for this PR are in the last commit.
# Objective
glTF files can contain cameras. Currently the scene viewer example uses _a_ camera defined in the file if possible, otherwise it spawns a new one. It would be nice if instead it could load all the cameras and cycle through them, while also having a separate user-controller camera.
## Solution
- instead of just a camera that is already defined, always spawn a new separate user-controller camera
- maintain a list of loaded cameras and cycle through them (wrapping to the user-controller camera) when pressing `C`
This matches the behavious that https://github.khronos.org/glTF-Sample-Viewer-Release/ has.
## Implementation notes
- The gltf scene asset loader just spawns the cameras into the world, but does not return a mapping of camera index to bevy entity. So instead the scene_viewer example just collects all spawned cameras with a good old `query.iter().collect()`, so the order is unspecified and may change between runs.
## Demo
https://user-images.githubusercontent.com/22177966/161826637-40161482-5b3b-4df5-aae8-1d5e9b918393.mp4
using the virtual city glTF sample file: https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/VC
Co-authored-by: Jakob Hellermann <hellermann@sipgate.de>
Bumps [JamesIves/github-pages-deploy-action](https://github.com/JamesIves/github-pages-deploy-action) from 4.1.7 to 4.3.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/JamesIves/github-pages-deploy-action/releases">JamesIves/github-pages-deploy-action's releases</a>.</em></p>
<blockquote>
<h2>v4.3.0</h2>
<h2>Changes</h2>
<ul>
<li>Implements a new option available behind a flag, <code>force</code>. If set to <code>false</code> the action will no longer force push, instead attempting 3 times to resolve rejected commits when making parallel/subsequent deployments. In a future version <code>false</code> will be set as the default. Massive thanks to <a href="https://github.com/rossjrw"><code>@rossjrw</code></a> for this feature addition.</li>
<li>Modified the Node version which the action is developed/tested against from <code>14</code> to <code>16</code>.</li>
</ul>
<h2>Minor Changes</h2>
<ul>
<li>Third-party dependency updates.</li>
<li>Test coverage improvements.</li>
</ul>
<h2>v4.2.5</h2>
<h2>Minor Changes</h2>
<ul>
<li>Corrects an issue in the publishing pipeline that was causing workflow failures.</li>
</ul>
<h2>v4.2.4</h2>
<h2>Minor Changes</h2>
<ul>
<li>Modified how workflow notices get displayed. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1033">#1033</a> Thanks to <a href="https://github.com/hemberger"><code>@hemberger</code></a>)</li>
<li>Dependency upgrades.</li>
</ul>
<h2>v4.2.3</h2>
<h2>Minor Changes</h2>
<ul>
<li>Improved action logging. This is part 1 or 2 updates that will make the logs easier to traverse. Warnings and notices are now provided so you don't need to expand the logs to get the termination message.</li>
<li>Dependency bumps across the board.</li>
</ul>
<h2>v4.2.2</h2>
<h2>Minor Changes</h2>
<ul>
<li>Introduces major version tags. You can now point your workflow to <code>JamesIves/github-pages-deploy-action@v4</code> if you'd like to always have the most cutting edge changes outside of using the release branch directly.</li>
<li>The version tags for this project now include a <code>v</code> to be consistent with other officially provided actions by GitHub. You can use <code>JamesIves/github-pages-deploy-action@v4.2.2</code> for instance. Dependabot should pick up this change automatically.</li>
</ul>
<h2>4.2.1</h2>
<h2>Minor Changes</h2>
<ul>
<li>Resolves an issue where the operating system warning was showing incorrectly.</li>
</ul>
<h2>4.2.0</h2>
<h1>Happy New Year 2022!</h1>
<p><img src="https://media.giphy.com/media/pYhFb0kn2GhQQ/giphy.gif" alt="London" /></p>
<h2>Minor Changes</h2>
<ul>
<li>Implements a warning if you're using an unsupported operating system. This will occur if the workflow runs within MacOS or Windows. The workflow will not be cancelled.</li>
<li>The action is now case insensitive, allowing you to make casing changes to files so long as you commit them using the <code>git mv</code> command prior to the workflow running. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/895">#895</a>)</li>
<li>Fixes an issue that was causing <code>single-commit</code> to fail when using <code>repository-name</code> if the branch name was equal from the origin to destination. (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/665">#665</a>)</li>
<li>Enabled Dependabot updates for the GitHub Actions that are used as part of the projects integration tests.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="360c8e75d0"><code>360c8e7</code></a> Merge branch 'dev' into releases/v4</li>
<li><a href="6ae2891783"><code>6ae2891</code></a> Update integration.yml</li>
<li><a href="e6c302f297"><code>e6c302f</code></a> Update README.md</li>
<li><a href="cf0ab8fab5"><code>cf0ab8f</code></a> Deploy Production Code for Commit 7598e9b3fc39a35565f529abe095d4dfe75d52e4 🚀</li>
<li><a href="7598e9b3fc"><code>7598e9b</code></a> Merge branch 'dev' into releases/v4</li>
<li><a href="36e9415933"><code>36e9415</code></a> Improe coverage</li>
<li><a href="e71f256f1c"><code>e71f256</code></a> Bump prettier from 2.6.1 to 2.6.2 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1068">#1068</a>)</li>
<li><a href="95f8a2cd05"><code>95f8a2c</code></a> Resolve simultaneous deployments with rebase (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1054">#1054</a>)</li>
<li><a href="cd846deedd"><code>cd846de</code></a> Bump <code>@actions/github</code> from 5.0.0 to 5.0.1 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1067">#1067</a>)</li>
<li><a href="7117b56a56"><code>7117b56</code></a> Bump prettier from 2.6.0 to 2.6.1 (<a href="https://github-redirect.dependabot.com/JamesIves/github-pages-deploy-action/issues/1065">#1065</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/JamesIves/github-pages-deploy-action/compare/4.1.7...v4.3.0">compare view</a></li>
</ul>
</details>
<br />
[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=JamesIves/github-pages-deploy-action&package-manager=github_actions&previous-version=4.1.7&new-version=4.3.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
# Objective
- Several examples are useful for qualitative tests of Bevy's performance
- By contrast, these are less useful for learning material: they are often relatively complex and have large amounts of setup and are performance optimized.
## Solution
- Move bevymark, many_sprites and many_cubes into the new stress_tests example folder
- Move contributors into the games folder: unlike the remaining examples in the 2d folder, it is not focused on demonstrating a clear feature.
# Objective
- While playing with volume, I noticed that when setting the volume just after playback start, I still get a few milliseconds at normal volume
## Solution
- Replace `play_in_loop` with `play_with_settings` that allows from more controls
- Adds a `PlaybackSettings` to specify the settings from start. Can be used: `PlaybackSettings::LOOP.with_volume(0.75)`
Currently `tracy` interprets the entire trace as one frame because the marker for frames isn't being recorded.
~~When an event with `tracy.trace_marker=true` is recorded, `tracing-tracy` will mark the frame as finished:
<aa0b96b2ae/tracing-tracy/src/lib.rs (L240)>~~
~~Unfortunately this leads to~~
```rs
INFO bevy_app:frame: bevy_app::app: finished frame tracy.frame_mark=true
```
~~being printed every frame (we can't use DEBUG because bevy_log sets `max_release_level_info`.~~
Instead of emitting an event that gets logged every frame, we can depend on tracy-client itself and call `finish_continuous_frame!();`
# Objective
- Fixes the issue with orthographic camera imported from glTF not displaying anything (mentioned in #4005).
## Solution
- This was due to wrong scaling mode being used. This PR simply changes WindowSize scaling mode to FixedHorizontal.
## Important Note
Currently, othographic scale in Blender, three.js, and possibly other software does not translate to Bevy (via glTF) because their developers have [misinterpreted the spec](https://github.com/KhronosGroup/glTF/issues/1663#issuecomment-618194015). The camera parameters have been clarified in glTF 2.0, which was released on October of 2021. In Blender 3.0.1 this issue has **not** been fixed yet. If you are importing orthographic cameras from Blender, you have to divide the scale by 2.
# Objective
- Previously, `iter_combinations()` does not work on queries that have filters.
- Fixes#3651
## Solution
- Derived Copy on all `*Fetch<T>` structs, and manually implemented `Clone` to allow the test to pass (`.count()` does not work on `QueryCombinationIter` when `Clone` is derived)
Co-authored-by: Carter Anderson <mcanders1@gmail.com>