2020-04-06 03:19:02 +00:00
|
|
|
[package]
|
|
|
|
|
name = "bevy_render"
|
2023-07-10 21:19:27 +00:00
|
|
|
version = "0.12.0-dev"
|
2021-10-25 18:00:13 +00:00
|
|
|
edition = "2021"
|
2020-08-10 00:24:27 +00:00
|
|
|
description = "Provides rendering functionality for Bevy Engine"
|
|
|
|
|
homepage = "https://bevyengine.org"
|
|
|
|
|
repository = "https://github.com/bevyengine/bevy"
|
2021-07-23 21:11:51 +00:00
|
|
|
license = "MIT OR Apache-2.0"
|
2020-08-10 00:24:27 +00:00
|
|
|
keywords = ["bevy"]
|
2020-04-06 03:19:02 +00:00
|
|
|
|
2021-12-14 03:58:23 +00:00
|
|
|
[features]
|
|
|
|
|
png = ["image/png"]
|
2023-02-19 20:38:13 +00:00
|
|
|
exr = ["image/exr"]
|
2021-12-14 03:58:23 +00:00
|
|
|
hdr = ["image/hdr"]
|
|
|
|
|
tga = ["image/tga"]
|
|
|
|
|
jpeg = ["image/jpeg"]
|
|
|
|
|
bmp = ["image/bmp"]
|
Added `WebP` image format support (#8220)
# Objective
WebP is a modern image format developed by Google that offers a
significant reduction in file size compared to other image formats such
as PNG and JPEG, while still maintaining good image quality. This makes
it particularly useful for games with large numbers of images, such as
those with high-quality textures or detailed sprites, where file size
and loading times can have a significant impact on performance.
By adding support for WebP images in Bevy, game developers using this
engine can now take advantage of this modern image format and reduce the
memory usage and loading times of their games. This improvement can
ultimately result in a better gaming experience for players.
In summary, the objective of adding WebP image format support in Bevy is
to enable game developers to use a modern image format that provides
better compression rates and smaller file sizes, resulting in faster
loading times and reduced memory usage for their games.
## Solution
To add support for WebP images in Bevy, this pull request leverages the
existing `image` crate support for WebP. This implementation is easily
integrated into the existing Bevy asset-loading system. To maintain
compatibility with existing Bevy projects, WebP image support is
disabled by default, and developers can enable it by adding a feature
flag to their project's `Cargo.toml` file. With this feature, Bevy
becomes even more versatile for game developers and provides a valuable
addition to the game engine.
---
## Changelog
- Added support for WebP image format in Bevy game engine
## Migration Guide
To enable WebP image support in your Bevy project, add the following
line to your project's Cargo.toml file:
```toml
bevy = { version = "*", features = ["webp"]}
```
2023-03-28 19:53:55 +00:00
|
|
|
webp = ["image/webp"]
|
2022-03-15 22:26:46 +00:00
|
|
|
dds = ["ddsfile"]
|
2023-05-16 23:51:47 +00:00
|
|
|
pnm = ["image/pnm"]
|
2023-05-01 18:00:01 +00:00
|
|
|
bevy_ci_testing = ["bevy_app/bevy_ci_testing"]
|
2022-03-15 22:26:46 +00:00
|
|
|
|
2023-04-25 19:30:48 +00:00
|
|
|
shader_format_glsl = ["naga/glsl-in", "naga/wgsl-out"]
|
|
|
|
|
shader_format_spirv = ["wgpu/spirv", "naga/spv-in", "naga/spv-out"]
|
|
|
|
|
|
2022-03-15 22:26:46 +00:00
|
|
|
# For ktx2 supercompression
|
|
|
|
|
zlib = ["flate2"]
|
|
|
|
|
zstd = ["ruzstd"]
|
|
|
|
|
|
2022-07-04 09:14:04 +00:00
|
|
|
trace = ["profiling"]
|
2022-04-08 22:50:23 +00:00
|
|
|
tracing-tracy = []
|
2021-12-14 03:58:23 +00:00
|
|
|
wgpu_trace = ["wgpu/trace"]
|
|
|
|
|
ci_limits = []
|
2021-12-22 20:59:48 +00:00
|
|
|
webgl = ["wgpu/webgl"]
|
2021-12-14 03:58:23 +00:00
|
|
|
|
2020-04-06 03:19:02 +00:00
|
|
|
[dependencies]
|
|
|
|
|
# bevy
|
2023-07-10 21:19:27 +00:00
|
|
|
bevy_app = { path = "../bevy_app", version = "0.12.0-dev" }
|
|
|
|
|
bevy_asset = { path = "../bevy_asset", version = "0.12.0-dev" }
|
|
|
|
|
bevy_core = { path = "../bevy_core", version = "0.12.0-dev" }
|
|
|
|
|
bevy_derive = { path = "../bevy_derive", version = "0.12.0-dev" }
|
|
|
|
|
bevy_ecs = { path = "../bevy_ecs", version = "0.12.0-dev" }
|
|
|
|
|
bevy_encase_derive = { path = "../bevy_encase_derive", version = "0.12.0-dev" }
|
|
|
|
|
bevy_hierarchy = { path = "../bevy_hierarchy", version = "0.12.0-dev" }
|
|
|
|
|
bevy_log = { path = "../bevy_log", version = "0.12.0-dev" }
|
|
|
|
|
bevy_math = { path = "../bevy_math", version = "0.12.0-dev" }
|
|
|
|
|
bevy_mikktspace = { path = "../bevy_mikktspace", version = "0.12.0-dev" }
|
|
|
|
|
bevy_reflect = { path = "../bevy_reflect", version = "0.12.0-dev", features = ["bevy"] }
|
|
|
|
|
bevy_render_macros = { path = "macros", version = "0.12.0-dev" }
|
|
|
|
|
bevy_time = { path = "../bevy_time", version = "0.12.0-dev" }
|
|
|
|
|
bevy_transform = { path = "../bevy_transform", version = "0.12.0-dev" }
|
|
|
|
|
bevy_window = { path = "../bevy_window", version = "0.12.0-dev" }
|
|
|
|
|
bevy_utils = { path = "../bevy_utils", version = "0.12.0-dev" }
|
|
|
|
|
bevy_tasks = { path = "../bevy_tasks", version = "0.12.0-dev" }
|
2020-04-06 03:19:02 +00:00
|
|
|
|
|
|
|
|
# rendering
|
2022-05-28 02:00:55 +00:00
|
|
|
image = { version = "0.24", default-features = false }
|
2020-04-06 03:19:02 +00:00
|
|
|
|
|
|
|
|
# misc
|
improve shader import model (#5703)
# Objective
operate on naga IR directly to improve handling of shader modules.
- give codespan reporting into imported modules
- allow glsl to be used from wgsl and vice-versa
the ultimate objective is to make it possible to
- provide user hooks for core shader functions (to modify light
behaviour within the standard pbr pipeline, for example)
- make automatic binding slot allocation possible
but ... since this is already big, adds some value and (i think) is at
feature parity with the existing code, i wanted to push this now.
## Solution
i made a crate called naga_oil (https://github.com/robtfm/naga_oil -
unpublished for now, could be part of bevy) which manages modules by
- building each module independantly to naga IR
- creating "header" files for each supported language, which are used to
build dependent modules/shaders
- make final shaders by combining the shader IR with the IR for imported
modules
then integrated this into bevy, replacing some of the existing shader
processing stuff. also reworked examples to reflect this.
## Migration Guide
shaders that don't use `#import` directives should work without changes.
the most notable user-facing difference is that imported
functions/variables/etc need to be qualified at point of use, and
there's no "leakage" of visible stuff into your shader scope from the
imports of your imports, so if you used things imported by your imports,
you now need to import them directly and qualify them.
the current strategy of including/'spreading' `mesh_vertex_output`
directly into a struct doesn't work any more, so these need to be
modified as per the examples (e.g. color_material.wgsl, or many others).
mesh data is assumed to be in bindgroup 2 by default, if mesh data is
bound into bindgroup 1 instead then the shader def `MESH_BINDGROUP_1`
needs to be added to the pipeline shader_defs.
2023-06-27 00:29:22 +00:00
|
|
|
wgpu = { version = "0.16.0", features=["naga"] }
|
2021-12-22 22:16:42 +00:00
|
|
|
codespan-reporting = "0.11.0"
|
2023-04-26 15:34:23 +00:00
|
|
|
naga = { version = "0.12.0", features = ["wgsl-in"] }
|
2020-05-26 01:27:04 +00:00
|
|
|
serde = { version = "1", features = ["derive"] }
|
2023-06-01 08:41:42 +00:00
|
|
|
bitflags = "2.3"
|
Add morph targets (#8158)
# Objective
- Add morph targets to `bevy_pbr` (closes #5756) & load them from glTF
- Supersedes #3722
- Fixes #6814
[Morph targets][1] (also known as shape interpolation, shape keys, or
blend shapes) allow animating individual vertices with fine grained
controls. This is typically used for facial expressions. By specifying
multiple poses as vertex offset, and providing a set of weight of each
pose, it is possible to define surprisingly realistic transitions
between poses. Blending between multiple poses also allow composition.
Morph targets are part of the [gltf standard][2] and are a feature of
Unity and Unreal, and babylone.js, it is only natural to implement them
in bevy.
## Solution
This implementation of morph targets uses a 3d texture where each pixel
is a component of an animated attribute. Each layer is a different
target. We use a 2d texture for each target, because the number of
attribute×components×animated vertices is expected to always exceed the
maximum pixel row size limit of webGL2. It copies fairly closely the way
skinning is implemented on the CPU side, while on the GPU side, the
shader morph target implementation is a relatively trivial detail.
We add an optional `morph_texture` to the `Mesh` struct. The
`morph_texture` is built through a method that accepts an iterator over
attribute buffers.
The `MorphWeights` component, user-accessible, controls the blend of
poses used by mesh instances (so that multiple copy of the same mesh may
have different weights), all the weights are uploaded to a uniform
buffer of 256 `f32`. We limit to 16 poses per mesh, and a total of 256
poses.
More literature:
* Old babylone.js implementation (vertex attribute-based):
https://www.eternalcoding.com/dev-log-1-morph-targets/
* Babylone.js implementation (similar to ours):
https://www.youtube.com/watch?v=LBPRmGgU0PE
* GPU gems 3:
https://developer.nvidia.com/gpugems/gpugems3/part-i-geometry/chapter-3-directx-10-blend-shapes-breaking-limits
* Development discord thread
https://discord.com/channels/691052431525675048/1083325980615114772
https://user-images.githubusercontent.com/26321040/231181046-3bca2ab2-d4d9-472e-8098-639f1871ce2e.mp4
https://github.com/bevyengine/bevy/assets/26321040/d2a0c544-0ef8-45cf-9f99-8c3792f5a258
## Acknowledgements
* Thanks to `storytold` for sponsoring the feature
* Thanks to `superdump` and `james7132` for guidance and help figuring
out stuff
## Future work
- Handling of less and more attributes (eg: animated uv, animated
arbitrary attributes)
- Dynamic pose allocation (so that zero-weighted poses aren't uploaded
to GPU for example, enables much more total poses)
- Better animation API, see #8357
----
## Changelog
- Add morph targets to bevy meshes
- Support up to 64 poses per mesh of individually up to 116508 vertices,
animation currently strictly limited to the position, normal and tangent
attributes.
- Load a morph target using `Mesh::set_morph_targets`
- Add `VisitMorphTargets` and `VisitMorphAttributes` traits to
`bevy_render`, this allows defining morph targets (a fairly complex and
nested data structure) through iterators (ie: single copy instead of
passing around buffers), see documentation of those traits for details
- Add `MorphWeights` component exported by `bevy_render`
- `MorphWeights` control mesh's morph target weights, blending between
various poses defined as morph targets.
- `MorphWeights` are directly inherited by direct children (single level
of hierarchy) of an entity. This allows controlling several mesh
primitives through a unique entity _as per GLTF spec_.
- Add `MorphTargetNames` component, naming each indices of loaded morph
targets.
- Load morph targets weights and buffers in `bevy_gltf`
- handle morph targets animations in `bevy_animation` (previously, it
was a `warn!` log)
- Add the `MorphStressTest.gltf` asset for morph targets testing, taken
from the glTF samples repo, CC0.
- Add morph target manipulation to `scene_viewer`
- Separate the animation code in `scene_viewer` from the rest of the
code, reducing `#[cfg(feature)]` noise
- Add the `morph_targets.rs` example to show off how to manipulate morph
targets, loading `MorpStressTest.gltf`
## Migration Guide
- (very specialized, unlikely to be touched by 3rd parties)
- `MeshPipeline` now has a single `mesh_layouts` field rather than
separate `mesh_layout` and `skinned_mesh_layout` fields. You should
handle all possible mesh bind group layouts in your implementation
- You should also handle properly the new `MORPH_TARGETS` shader def and
mesh pipeline key. A new function is exposed to make this easier:
`setup_moprh_and_skinning_defs`
- The `MeshBindGroup` is now `MeshBindGroups`, cached bind groups are
now accessed through the `get` method.
[1]: https://en.wikipedia.org/wiki/Morph_target_animation
[2]:
https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#morph-targets
---------
Co-authored-by: François <mockersf@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2023-06-22 20:00:01 +00:00
|
|
|
bytemuck = { version = "1.5", features = ["derive"] }
|
2021-12-14 03:58:23 +00:00
|
|
|
smallvec = { version = "1.6", features = ["union", "const_generics"] }
|
2020-09-10 19:54:24 +00:00
|
|
|
downcast-rs = "1.2.0"
|
2022-06-21 18:10:27 +00:00
|
|
|
thread_local = "1.1"
|
2020-05-16 02:30:02 +00:00
|
|
|
thiserror = "1.0"
|
2021-12-14 03:58:23 +00:00
|
|
|
futures-lite = "1.4.0"
|
|
|
|
|
anyhow = "1.0"
|
2023-05-16 01:24:17 +00:00
|
|
|
hexasphere = "9.0"
|
2022-07-14 21:17:16 +00:00
|
|
|
parking_lot = "0.12.1"
|
2022-03-15 22:26:46 +00:00
|
|
|
ddsfile = { version = "0.5.0", optional = true }
|
|
|
|
|
ktx2 = { version = "0.3.0", optional = true }
|
improve shader import model (#5703)
# Objective
operate on naga IR directly to improve handling of shader modules.
- give codespan reporting into imported modules
- allow glsl to be used from wgsl and vice-versa
the ultimate objective is to make it possible to
- provide user hooks for core shader functions (to modify light
behaviour within the standard pbr pipeline, for example)
- make automatic binding slot allocation possible
but ... since this is already big, adds some value and (i think) is at
feature parity with the existing code, i wanted to push this now.
## Solution
i made a crate called naga_oil (https://github.com/robtfm/naga_oil -
unpublished for now, could be part of bevy) which manages modules by
- building each module independantly to naga IR
- creating "header" files for each supported language, which are used to
build dependent modules/shaders
- make final shaders by combining the shader IR with the IR for imported
modules
then integrated this into bevy, replacing some of the existing shader
processing stuff. also reworked examples to reflect this.
## Migration Guide
shaders that don't use `#import` directives should work without changes.
the most notable user-facing difference is that imported
functions/variables/etc need to be qualified at point of use, and
there's no "leakage" of visible stuff into your shader scope from the
imports of your imports, so if you used things imported by your imports,
you now need to import them directly and qualify them.
the current strategy of including/'spreading' `mesh_vertex_output`
directly into a struct doesn't work any more, so these need to be
modified as per the examples (e.g. color_material.wgsl, or many others).
mesh data is assumed to be in bindgroup 2 by default, if mesh data is
bound into bindgroup 1 instead then the shader def `MESH_BINDGROUP_1`
needs to be added to the pipeline shader_defs.
2023-06-27 00:29:22 +00:00
|
|
|
naga_oil = "0.8"
|
2022-03-15 22:26:46 +00:00
|
|
|
# For ktx2 supercompression
|
|
|
|
|
flate2 = { version = "1.0.22", optional = true }
|
2023-06-06 21:04:07 +00:00
|
|
|
ruzstd = { version = "0.4.0", optional = true }
|
2022-03-15 22:26:46 +00:00
|
|
|
# For transcoding of UASTC/ETC1S universal formats, and for .basis file support
|
2023-05-17 23:29:31 +00:00
|
|
|
basis-universal = { version = "0.3.0", optional = true }
|
2023-05-16 01:24:17 +00:00
|
|
|
encase = { version = "0.6.1", features = ["glam"] }
|
2022-07-04 09:14:04 +00:00
|
|
|
# For wgpu profiling using tracing. Use `RUST_LOG=info` to also capture the wgpu spans.
|
|
|
|
|
profiling = { version = "1", features = ["profile-with-tracing"], optional = true }
|
2023-01-20 13:20:28 +00:00
|
|
|
async-channel = "1.8"
|
2023-04-28 19:37:11 +00:00
|
|
|
|
|
|
|
|
[target.'cfg(target_arch = "wasm32")'.dependencies]
|
|
|
|
|
js-sys = "0.3"
|
|
|
|
|
web-sys = { version = "0.3", features = [
|
|
|
|
|
'Blob',
|
|
|
|
|
'Document',
|
|
|
|
|
'Element',
|
|
|
|
|
'HtmlElement',
|
|
|
|
|
'Node',
|
|
|
|
|
'Url',
|
|
|
|
|
'Window',
|
|
|
|
|
] }
|
|
|
|
|
wasm-bindgen = "0.2"
|
