Add Structure to Model (replaces Structure Importer)

[MesterMan03]

Structure to Model (STM) is a plugin that improves on and replaces the previous Structure Importer plugin. Functionally it does the same thing; takes a structure file and converts it into a model. However, STM handles bigger structures much better, includes tinted texture support (grass, leaves etc. won't show up as their default grey texture) and generally improves on the old plugin, making that obsolete.

The plugin's source code can be found under https://github.com/MesterMan03/structure-to-model. It's written in TypeScript and gets bundled into a single minified JavaScript file (when needed, the plugin can be built with a sourcemap included to help debugging). For NBT reading, the plugin includes nbtify bundled into the final output instead of a custom in-house implementation.

Why

I used Structure Importer a lot for my project. It was fine for a while, however once I started importing bigger structures, I noticed that the plugin is simply unable to handle them. Blocks would not be loaded properly and the final model looked nothing like the structure. After some debugging, I've found out that the original plugin had major flaws that caused its internal palette to be out of sync with what's stored in the structure, causing the subsequent blocks to be completely off - which led to air being replaced with waterlogged kelp, slabs turning into stairs etc. Instead of fighting the plugin for days, I've decided to create my own plugin that actually does its job.

Fixes & Improvements compared to Structure Importer

• Support for big structures: STM correctly loads and supports structures of any arbitrary sizes. Obviously as you load in bigger structures performance will get worse due to the number of cubes Blockbench is trying to render, however this is not a bug in the plugin just a consequence of model complexity.
• Support for default blockstates: In certain cases, Structure Importer was incorrectly handling blocks with their default blockstates. One example is log blocks, which have an axis property that can be either x, y or z. If a structure includes multiple of these properties, the non-default variants get saved with the property explicitly set, but the default value gets left out. When Structure Importer then attempts to load in a log with axis=x (the default value), it couldn't find that property explicitly set in its palette and fails to place those blocks. STM fixes this and correctly loads in every block, regardless of its variants.
• Tinted textures: STM can create tinted variants of certain textures (examples are grass block, leaves etc.) on-the-fly and save it in a custom resource pack. It comes with 5 colour presets but can be configured to use any custom tint colour, or none at all.
• Better grouping: Rather than having one "structure" group with unnamed cube elements for every block, STM names every cube after the block they represent. Blocks with a single cube turn into a cube with the same name as the block, while the cubes of a multipart block get grouped together, once again named after the block.
• Better UX: When importing a bigger structure, instead of blocking the main thread until it's finished, STM shows a progress status that updates in real time (you can also see the individual blocks being placed, which is quite cool).

What about Structure Importer

This plugin effectively replaces Structure Importer and makes it obsolete. I obviously don't want to decide what should happen with it, I'll let the maintainers have the decision.

[JannisX11]

Hey, this looks good! Sorry for the late review.
I have two requests for changes:

1. Keeping the source code in a separate repository is ok, but please follow the guidelines in README.md. The plugin should have a min_version of 5.0.0 or higher, which also requires using the new repository structure with a sub folder for the plugin. I would recommend this anyways because you can create an about text.

2. Async operations are generally good for performance, however in this case you can improve performance quite a lot by limiting its use. Vue 2, which is used for rendering UI elements like outliner and UV editor, updates in ticks. So if you make the addition of each cube async and wait for it to finish before the next one, Vue will have a chance to update its UI after every cube, which is quite slow. Instead I would recommend to keep the pause after 100 elements, but remove the pause for each cube. Regarding the async tinted textures, you can return the texture synchronously, and just generate the content later.