Request: model -> image API

[tryashtar]

First of all, thank you for your excellent work on this project! It's exactly what I needed for porting my work to beet, and I was very pleasantly surprised to see how accurate and up-to-date this renderer is with all the new item model features. And the animations, wow!

However, some difficulties with the API have required me to fork it, and I think rather than maintaining that I'd prefer to explain my use case here so we can consider some changes to the API.

My project involves iterating over item models in vanilla and rendering them to images. I'll summarize and explain some of my pain points using model_resolver here.

1. Vanilla fetching: Currently model_resolver downloads its own version of vanilla, as specified in the global config. In my use case, I already have my own version of vanilla. Due to Vanilla release registry fetches the wrong version mcbeet/beet#476, my version doesn't always exactly match model_resolver's version, which has caused issues.
2. Task pattern: Currently model_resolver has you create a renderer, add tasks to it, then run it, and it dumps all the images to the context resource pack. This causes issues for me because I want to use the images for other purposes, often during iteration. Instead, I need to postpone all that work until the tasks have been run, find the images in the context pack, delete them, and only then use them.
3. Model sourcing: Currently the tasks merely contain an identifier for the model to render. This means that in some cases I need to artificially inject models into my context pack just so that model_resolver can look them up. I need to keep track of these injected models to delete them afterwards.
4. Pack merging: The renderer merges its downloaded vanilla with a copy of my context resource pack when it's created. This means I need to inject all these fake models beforehand. So I can't even create the renderer until that's done. I have to separately keep track of the tasks I'm going to add to it, then create, then add the tasks, then run it, then clean up.

These problems would be solved if I could pass in my own resource pack to source models from, instead of model_resolver finding one itself, give full models instead of just their identifiers, and could render images right away without saving them to the pack in one fell swoop.

So my ideal API for this project is one that looks something like this:

render_item_model(model: ItemModelBase, settings: RenderSettings) -> Image
# likewise for models, block states, items, etc.

RenderSettings would include a ResourcePack, so I could pass in my own vanilla.assets, some of the formerly global settings like render_size, and I had another cool idea: some of the item model properties (like compass or use_duration) are marked as "Not possible to implement" for good reason (they don't show up in the item data), but we actually could include values for those in the RenderSettings to support them, like some kind of "current context" field. I don't actually require this for my use case, but could be interesting.

I wish I had the skill and experience to write an implementation of this API myself, but sadly I do not, so my meager fork only attempts to (poorly) fix the vanilla mismatch problem. Anyway, these are just my thoughts, I am still a happy and grateful user with no expectations that you take on all this work on my account.

[edayot]

Hello,
First of all thank for the suggestions (it demonstrates that I'm not the only one using this library and it’s cool), and also sorry I'm a bit late to respond.

• for the minecraft version thing there is this parameter : https://github.com/edayot/model_resolver/blob/master/model_resolver%2Futils.py#L51
• i agree that a task pattern is not the best thing, in a future version specifing nether path_ctx or path_save would just store the image in the task object
• if you generate model on the fly there is an internal api that i can expose for you
• i know this problem, a copy of the context is made when creating the Render class, will fix this to create it when rendering

The Rendersettings object is a great idea, adding a context to resolve theses models would be usefull !

To finish subtasks to all issue/suggestions will mention this one to keep track of them.