bevyengine / bevy-assets Goto Github PK
View Code? Open in Web Editor NEWA collection of Bevy assets, plugins, learning resources, and apps made by the community
Home Page: https://bevyengine.org/assets
A collection of Bevy assets, plugins, learning resources, and apps made by the community
Home Page: https://bevyengine.org/assets
Currently there is only one plugin in the assets page that deals with games that save stuff to the disk to be loaded later - bevy_save - and it's located under "Helpers". But I'm aware of several other plugin that deal with such things:
They are not exactly the same - some deal with saving/loading scenes, others with resources or manually picked data - but I still think a category like "Persistence" or "Saving/Loading" or something like that would describe them neatly, and this is something important enough in gamedev to justify a separate category.
BTW - do we need permission from the authors to add these crates to the list, or can we just add them?
Looking at the source, the current maximum appears to be 100 characters.
Currently bevy lists bevy_retro in assets. (main/Assets/2D/bevy_retro.toml)
bevy_retro is licensed under what they call the Katharos license
The core issue i have with this license is that very large parts of the limitations it puts on usage are very subjective and up to interpretation. Interpretation of one of the most disputed and re-interpreted texts in human history. Something a user might think the license allows, might be forbidden by the authors interpretation of it. This leads to enormous uncertainty - if i may play devils advocate: the author could turn around and suddenly proclaim that a big project using bevy_retro is infringing on something the author interprets the license to say. This would require a legal battle, which could cost both sides a lot of time and money.
I think keeping something this ambigous on a site which could easily be understood as a "official bevy endorsement" is a risk bevy shouldn't be willing to take.
Hi, I am the author of benimator, currently referenced on bevy assets.
Yesterday, I took the decision and announced that benimator 4.0.0 (currently in beta) will no longer be a bevy plugin. I will continue to showcase examples of how to use it from bevy. But nothing more than that.
Therefore, I am wondering if the benimator entry can stay or should be removed from bevy assets.
Of course, I will not push to remove it. But I thought I should inform you of this change, and allow you to remove the benimator entry if you feel it no longer deserves to be there.
There has been a lot of discussion in the bevy discord around possible improvements to Awesome Bevy. Some of these cool things don't fit well into the "single markdown file maintained by one person" model.
Cart has a vision for what an "Awesome Bevy 2.0" would look like:
awesome-bevy
becomes a structured file format (something like json or yaml)And some other thoughts
i think making awesome-bevy "fairer" is a bit of a priority
right now order is arbitrary / comes from how bold contributors decide to be and how willing i am to change the order
it would be nice to be able to provide a curated section of high quality plugins (and content)
/ with vetted licenses
Here's some prior art that may be of interest:
https://github.com/discord/discord-open-source (the back-end, anyway)
Here's the discord conversation that inspired this issue:
https://discord.com/channels/691052431525675048/692572690833473578/829793619132022814
There is a section dedicated to "shapes." bevy_mod_rounded_box
might even be the shapiest plugin there is.
We should be consistent with the bevy
and rfcs
repositories and switch from master
to main
.
In the readme there is a link to Bevy Plugin Guidelines that points to https://github.com/bevyengine/bevy/blob/main/docs/plugins_guidelines.md however following this link leads to a 404.
I would like to create a new asset category called "Assets", and moving a few of those present in "Helper":
bevy_asset_loader
by @NiklasEibevy_asset_ron
by @inodentrybevy_assetio_zip
by katharostech (@zicklag ?)bevy_assets_bundler
by @hanabi1224bevy_embedded_assets
by @mockersfbevy_loading
by @inodentrybevy_prototype_inline_assets
by @emosenkisbevy_web_asset
by @johanhelsingCould you reply on this issue if you agree or if you can think of a better name? Thanks!
We manually sort "Official Bevy Examples" in the learning section, so there is precedent for this.
In my opinion, we should sort this first, add an image, and adjust the title to "Official Github Template."
This issue is motivated by a user who was under the impression that Bevy Shell
was the official template because it is coincidentally currently sorted first and has a nice graphic with the bevy logo. That user then went on to have various issues with native builds during Bevy Jam 3.
This is an issue and not a pr because I don't know whether to create a new category(i think we should) and where to place such category in relation to the others, my guess would be near development tools.
bevy_fluent
is located here: https://github.com/kgv/bevy_fluent
Now that Bevy Assets are deployed as part of the website, it's a little strange to have the migration guides take so much space: https://bevyengine.org/assets/#migration-guides when they are also https://bevyengine.org/learn/book/migration-guides/. I think it makes sense to keep them as a separate category if we plan to rely on community for migration guides, but not if they are officials
Proposal:
Learning/Tutorials
categoryLearning/Migration Guides
categoryLearning/Tutorials
for general migration guides linking to https://bevyengine.org/learn/book/migration-guides/Tutorials
from Learning
. This would need an evolution on Bevy Assets website to allow assets on parent categoryAlmost 2 MB of gif, can it be reduced?
Btw I noticed some entries that already have a 2mb gif. If size is a concern, maybe all entries should be static-image only going forward? With time that page is only going to become increasingly burdensome for low-bandwidth connections.
Allowing looped .mp4s is another option as those are a lot easier to optimize without significant quality loss.
Originally posted by @erlend-sh in #222 (comment)
Related: #188
As the Assets page grows, it becomes notably harder to sort through the assets that are actually usable with a recent or current Bevy version. IMO, the page would be well suited to sorting by assets which have been more recently updated to the current Bevy version. Especially when there are Assets among them which only work on very old Bevy versions.
The current image space on the website is 83.7 x 128 px. Most images are way larger than that. On the other hand, the current website layout is not very good and could be improved, which could lead to displaying a larger preview image in the future (and hopefully better the largest allowed description text, which is currently cropped; see #159). I think it would be nice to set expectations and provide a recommended image dimension, the largest we think we will reasonably ever display in the future for any asset.
For the sake of discussion I'd propose something like 256 x 256 px, which is about 2x the current display so would allow crisp rendering on high DPI monitors, and is square so we can future proof it with respect to various current and future layouts of the website. We can consider larger sizes too, but being mindful some images are animated (GIF) so disk size will grow quickly.
Right now the job takes more than 5 minutes generating metadata. Since every asset is filled sequentially it will only get worse linearly as more assets are added. This is especially noticeable when developing locally, but might also become an issue in GitHub Actions as the quotas are reached.
On a full site redeploy for example 8m 20s out of 11m 20s are spent in the asset phase, out of which 3m are compile time and the 5m 20s are running the generation.
The proposed solution is to parallelize metadata requests as much as possible while trying to not hit service throttling limits.
Edit: my bad, this should probably have been opened in the bevy-website repository.
We're storing significant amounts of binary (image) data, and should probably be using a better solution than raw git.
Git LFS is by far the most simple to integrate, so probably works well here.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.