You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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)
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).
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:
There may be others, and I invite people to suggest them here.
The text was updated successfully, but these errors were encountered: