Skip to content
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

[pull] main from bevyengine:main #214

Merged
merged 4 commits into from
Dec 12, 2024
Merged

[pull] main from bevyengine:main #214

merged 4 commits into from
Dec 12, 2024

Conversation

pull[bot]
Copy link

@pull pull bot commented Dec 12, 2024

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

pcwalton and others added 4 commits December 12, 2024 04:24
…d multidraw. (#16755)

This commit resolves most of the failures seen in #16670. It contains
two major fixes:

1. The prepass shaders weren't updated for bindless mode, so they were
accessing `material` as a single element instead of as an array. I added
the needed `BINDLESS` check.

2. If the mesh didn't support batch set keys (i.e. `get_batch_set_key()`
returns `None`), and multidraw was enabled, the batching logic would try
to multidraw all the meshes in a bin together instead of disabling
multidraw. This is because we checked whether the `Option<BatchSetKey>`
for the previous batch was equal to the `Option<BatchSetKey>` for the
next batch to determine whether objects could be multidrawn together,
which would return true if batch set keys were absent, causing an entire
bin to be multidrawn together. This patch fixes the logic so that
multidraw is only enabled if the batch set keys match *and are `Some`*.

Additionally, this commit adds batch key support for bins that use
`Opaque3dNoLightmapBinKey`, which in practice means prepasses.
Consequently, this patch enables multidraw for the prepass when GPU
culling is enabled.

When testing this patch, try adding `GpuCulling` to the camera in the
`deferred_rendering` and `ssr` examples. You can see that these examples
break without this patch and work properly with it.

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective

The doc comments and function namings for `BorderRect` feel imprecise to
me. Particularly the `square` function which is used to define a uniform
`BorderRect` with equal widths on each edge. But this is potentially
confusing since this "square" border could be around an oblong shape.

Using "padding" to refer to the border extents seems undesirable too
since "padding" is typically used to refer to the area between border
and content, not the border itself.

## Solution
* Rename `square` to `all` (this matches the name of the similar method
on `UiRect`).
* Rename `rectangle` to `axes` (this matches the name of the similar
method on `UiRect`).
* Update doc comments. 

## Migration Guide
The `square` and `rectangle` functions belonging to `BorderRect` have
been renamed to `all` and `axes`.

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective

Fixes #16771 

## Solution

Fixed typo in code.

## Testing

- Did you test these changes? If so, how?
I tested on my own example, that I included in the issue. It was
behaving as I expected.

Here is the screenshot after fix, the screenshot before the fix can be
found in the issue.

![image](https://github.com/user-attachments/assets/f558363f-718d-4244-980c-d224feb2ba0b)
# Objective

There are two of the same instruction in this example's instruction
text.

## Solution

Delete one

## Testing

`cargo run --example lighting`
@pull pull bot added the ⤵️ pull label Dec 12, 2024
@pull pull bot merged commit cca6a2b into VitalyAnkh:main Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants