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

Be able to customize MAX_JOINTS and MAX_MORPH_WEIGHTS #17128

Open
victorb opened this issue Jan 3, 2025 · 0 comments
Open

Be able to customize MAX_JOINTS and MAX_MORPH_WEIGHTS #17128

victorb opened this issue Jan 3, 2025 · 0 comments
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!

Comments

@victorb
Copy link

victorb commented Jan 3, 2025

What problem does this solve or what need does it fill?

Currently, MAX_JOINTS and MAX_MORPH_WEIGHTS are hard-coded to a pair of values that are described as "guaranteed to work everywhere" which I don't think it's true, since the max of those values depend on the GPU/platform.

These hard-coded limits puts both a maximum and minimum hardware requirement from the engine, with no developer choice if they want it to be higher/lower. For example, complex rigs easily blow past those limits, and really low specced hardware can't load things with those limits.

It makes sense that there are limits, but if they could be configurable, then developers don't need to fork bevyengine/bevy just because they want to support moderately complicated rigs. Developers should also be the ones who decide what hardware requirements they are OK with for their games, but right now Bevy is making that choice for them.

What solution would you like?

Some way of configuring MAX_JOINTS and MAX_MORPH_WEIGHTS without having to maintain a fork of Bevy.

What alternative(s) have you considered?

I did attempt a PR to just double the values, but it's not really a proper fix.

Beyond that, I think the only alternative is to add some heuristics to make Bevy automatically figure out those limits, but that sounds both error-prone, magical and still wouldn't give the developer themselves control over what their requirements are.

Additional context

cc @mockersf, @alice-i-cecile, @BenjaminBrienen as you seem to be the ones you've been involved with this previous

@victorb victorb added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jan 3, 2025
@BenjaminBrienen BenjaminBrienen added A-Rendering Drawing game state to the screen S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it! D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes and removed S-Needs-Triage This issue needs to be labelled labels Jan 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Projects
None yet
Development

No branches or pull requests

2 participants