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

Handle special case assets #316

Closed
TheDuckCow opened this issue Jul 10, 2022 · 3 comments
Closed

Handle special case assets #316

TheDuckCow opened this issue Jul 10, 2022 · 3 comments
Labels
enhancement Feature requests or new functionality suggestions
Milestone

Comments

@TheDuckCow
Copy link
Member

TheDuckCow commented Jul 10, 2022

MCprep is made to work in a generic way so that anyone can author assets, but also so they may be used with confidence regardless of blender version and render engine (limited to those supported thus far: Cycles, Eevee, and the legacy Blender Internal). However, there is a growing number of assets that require some level of "special treatment". Hard coding these special cases is brittle or at least hard to track. The proposal is to create a system that instead identifies the way to handle these assets in the intended way, likely by extending the MCprep resources json file. The idea is that this should drive changes to how the UI draws, and not change actual operator code. This way, it's just changing the initially assigned operator properties but still leaves the user the chance to change after the fact if they want.

Some examples of assets to handle differently:

  • Don't auto-prep materials: By default, when spawning assets like mobs, prep materials automatically runs to ensure that the rigs will work well in any given version of blender and the render engine available, regardless of how it was saved. However, some rigs are set up with special material nodes that would be lost when using prep materials. For these assets, instead choose to not prep materials automatically (at the cost of the materials not working in other render engines, like Blender Internal or other future render engines MCprep may support):
    • Frog, due to the custom materials for skin switching
    • Simple Villager, due to the custom materials for skin switching
    • Glow squid, due to custom materials to make it glow lol
    • Strider, drivers used to swap between strider states.
    • Warden, due to custom materials for animated glowing.
    • Player rigs (presuming the armor updates come through and indeed use the UV switching approach).
  • Automatically "make instances real" from meshswap or effects spawning: Generally meshswap works efficiently if blocks are added as instances, so that data is not duplicated and things like pre-animations remain ("make instances real" clears animations). However, this means that the blocks are not easily edited and some meshswap blocks are set up with rigs. Users who don't know to tick the box "make instances real" then are frustrated they can't use the rig. Thus, for these assets with armatures but no animations, we should know to auto-make instances real. This could be automated, or hard coded for the specific assets known.
    • Chest & Chest_Double

There may be others, and I invite people to suggest them here.

@TheDuckCow TheDuckCow added the enhancement Feature requests or new functionality suggestions label Jul 10, 2022
@TheDuckCow TheDuckCow added this to the v3.4.0 milestone Jul 10, 2022
@Roni-Raihan
Copy link

Roni-Raihan commented Jul 11, 2022

for meshswap, so far only Chest and Chest_Double I think need to be instances real. for other meshswap I think it needn't be instances real

@TheDuckCow
Copy link
Member Author

thanks for quick checking @Roni-Raihan! Yeah that's my thought as well. I'm considering even whether some of the new effects spawners would benefit from it, but for the time being I think not. Can always add to it when needed.

TheDuckCow added a commit that referenced this issue Aug 2, 2022
Specified per #316 to change settings forcibly when the asset would be known to not work well with the default. Entirely driven by the json to avoid hardcoding, but only based on asset display names (so could clash with custom installed assets potentially)
@TheDuckCow
Copy link
Member Author

This has now been implemented, and I've found to be working well locally. Nothing is hard coded, all defined in the json file via new fields "mob_skip_prep" (mob spawning only) and "make_real" (meshswap only).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests or new functionality suggestions
Projects
None yet
Development

No branches or pull requests

2 participants