-
Notifications
You must be signed in to change notification settings - Fork 26
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
feat: Upstream Vivy material system #600
base: dev
Are you sure you want to change the base?
Conversation
Vivy is a new material system that is based around the concept of templates instead of generation. I created it in my spare time in 2023 and used it for my new year's piece https://www.standingpad.org/posts/2023/12/new-years/#vivy Initially, I have said that I didn't want to upstream Vivy in MCprep to avoid users from opening bug reports after underestimating the complexity of using the system. That said, #274 already had plans to revamp the material system for greater user flexibility, and I'm unable to maintain Vivy on my own (given the fast pace of upstream MCprep). Therefore, I've decided to begin the work of upstreaming Vivy into MCprep itself. I initially tried to merge Vivy into a separate branch, but that turned out to be impossible due to massive changes in mainline MCprep. Thus, I've included the Vivy files here and added the necessary changes to `conf.py` and `load_modules.py`. This was made easier by the fact that Vivy does not change anything internal, mostly due to laziness on my part (instead, I just copied and pasted functions I needed to modify for Vivy). As such, everything in Vivy is a separate operator, using the `vivy` prefix instead of `mcprep`. I've not included the necessary reference changes for Vivy, since I don't want to start overriding operators yet. As it stands, Vivy is lacking in the following areas: - UI for setting up materials - Documentation for using - Integration in the rest of MCprep (like mob rigs) In addition, Vivy also has the following issues due to the way its designed: - Use of `VIVY` and `vivy` prefixes - Lose integration (again, due to laziness on my part) - No tests Seeing as this is more of a long term project however, I think we can get these tackled sometime by MCprep 4.0. Once those are done, we'd also need to discuss how this would coexist with the existing generation based system (should we choose to keep it). Closes #274 Signed-off-by: Mahid Sheikh <[email protected]>
Just to be clear as well, after MCprep 3.6 releases, I'll be taking a break from MCprep development to focus more on college applications and BpyBuild, so @TheDuckCow if you want, you can develop on this branch without conflicts for the most part. This is more of a long term thing anyway. |
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
After a little effort (mostly with missing stuff), I've added the ability to build MCprep with Vivy exposed in the UI through the Make sure when enabling Vivy support, you have |
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Updated some of the references so basic things work. Vivy-based textureswap seems to not want to work for some reason, but prepping materials in general works fine |
Signed-off-by: Mahid Sheikh <[email protected]>
Got the Vivy-based textureswap fixed partially (issue was due to an outdated check for |
Signed-off-by: Mahid Sheikh <[email protected]>
Fixed the last remaining issue with Vivy-based textureswap, so now it should work on all texture packs |
Alright, got an idea to make merging this PR less of a pain: what if we make this PR solely dedicated to cleaning up and properly upstreaming the Vivy code (for say MCprep 3.7), and then gate the loading of Vivy behind a runtime check (which we do for the UI, but not the actual registration)? This does mean the UI is technically in an incomplete when merged, but it also means less of a pain with merge conflicts as the PR wouldn't be too far behind. We could also make Vivy usable to end users using the experimental flag in MCprep, so we can get some community feedback (especially when we do start working on the UI). |
Signed-off-by: Mahid Sheikh <[email protected]>
@TheDuckCow ready for first review. To be clear, this is a long term feature that will be developed over multiple PRs, and perhaps won't be enabled for users until MCprep 4.0. This PR specifically works on cleaning up the code for the Vivy material system, and getting it up to par with upstream standards. That way, we don't have to worry about a single long PR that gains conflicts over time, and instead have smaller PRs merged over a longer period of time. It does mean having unstable code in production, but I think that's a reasonable tradeoff to make. By default, Vivy modules won't even be registered unless |
Hey @StandingPadAnimations thanks for making a great head start on this! To make things easier, would you be able to record a short demo video of how it's mean to be used right now? That way you save some time documenting and it's easier for me to see how it's currently working. I installed the branch to see that at the very least, nothing appears broken per-se, but wasn't too sure where to go after there (without diving more into the code first). We can either treat this as a feature branch, or try to merge parts of it at a time until the UI side is fully ready. |
Here's some demos I uploaded on Mastodon a long time back (not much has changed though): |
I think the latter would be better in the long run, mostly to try and avoid as many merge conflicts as possible. That said, it might make more sense to make this a feature branch |
I tend to agree, ok let's go with that strategy. Thanks for providing the demos, will take a look and get back to you - but I agree, seems like a good stepping stone to include this in 3.6.2 since it's mostly backend to what the user sees for now. |
Looked at the demos, veyr nice. Something I definitely will need to noodle on - these fill a similar, but not exactly the same, space as the current day "Sync materials" which are made to exist alongside the asset pack. I think we should find a way to unify these (likely taking yours as a base, but then integrating into other operators similar to how sync materials is today). Not sure if there was meant to be audio in your recordings, but at the end of the pbr one you were waving your cursor around the water. What is your thought on finding a way to mark a material to work for specific blocks/materials, vs working as the template for all of them? I could imagine we can create some kind of tags so you can optionally specify a given vivy material is to be used for specific things. e.g. maybe a user wants to use one layout for all "fire" blocks, another layout for all grass/leaves, but then the default MCprep for everything else. And thirdly, I'm also contemplating whether this is a good time to make these things work nicely together in the asset browser. If we are already marking a material template, maybe we should register them as an asset as well?? We could potentially even do some fancy post-material import things like detect if you dropped a vivy template onto a material slot that had a pre-existing world import material, and go in after to make unique and swap in the correct images (there's a PR for creating python hooks after asset browser drops via Greg Zaal that would need to be completed first) |
Vivy actually does support such a feature, referred to as refinements (as in refining a material for a specific subset of blocks). These are based on the existing MCprep block categories (like emissive, glossy, etc). I had plans as well for specific blocks, but never got around to doing it. I think I've showcased refinements in the above demos but if not, I could put one together.
That would be interesting, but there are a few things that might make this a bit of a challenge:
As an aside, should Vivy be the "official" name of this feature, or just a codename? The name might be a little confusing to users when we do eventually introduce this (it's a pretty obscure reference to a light novel I was reading at the time 😅) |
Also, the code is ready for review, not sure if I mentioned that earlier |
Signed-off-by: Mahid Sheikh <[email protected]>
Alright, since it seems like Vivy builds for the most part without errors, I'll move Vivy from a build-time option to an experimental feature (which I believe would make Vivy the first experimental feature in MCprep) |
Signed-off-by: Mahid Sheikh <[email protected]>
This makes it easier for users to opt-in Vivy if they wish to do so. This also makes Vivy officially the first experimental feature in MCprep. This requires 2 levels of opt-in: first enabling the experimental feature set, and then enabling the Vivy system. This is due to all of the overrides we do in the UI for Vivy. Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
To avoid conflicts, I propose we merge this initially, and then make features such as the simplified UI and ability for user-defined paths separate PRs. That way, this doesn't become a long-winded PR. @TheDuckCow This PR is ready for initial review |
Alright basic config editing. This is in the same location as the Vivy node tools 2024-08-30.21-39-21.mp4 |
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Signed-off-by: Mahid Sheikh <[email protected]>
Vivy is a new material system that is based around the concept of templates instead of generation. I created it in my spare time in 2023 and used it for my new year's piece
https://www.standingpad.org/posts/2023/12/new-years/#vivy
Initially, I have said that I didn't want to upstream Vivy in MCprep to avoid users from opening bug reports after underestimating the complexity of using the system. That said, #274 already had plans to revamp the material system for greater user flexibility, and I'm unable to maintain Vivy on my own (given the fast pace of upstream MCprep). Therefore, I've decided to begin the work of upstreaming Vivy into MCprep itself.
I initially tried to merge Vivy into a separate branch, but that turned out to be impossible due to massive changes in mainline MCprep. Thus, I've included the Vivy files here and added the necessary changes to
conf.py
andload_modules.py
. This was made easier by the fact that Vivy does not change anything internal, mostly due to laziness on my part (instead, I just copied and pasted functions I needed to modify for Vivy). As such, everything in Vivy is a separate operator, using thevivy
prefix instead ofmcprep
. I've not included the necessary reference changes for Vivy, since I don't want to start overriding operators yet.As it stands, Vivy is lacking in the following areas:
In addition, Vivy also has the following issues due to the way its designed:
VIVY
andvivy
prefixesSeeing as this is more of a long term project however, I think we can get these tackled sometime by MCprep 4.0. Once those are done, we'd also need to discuss how this would coexist with the existing generation based system (should we choose to keep it).
Closes #274