Add a FabricBlockModelSupplier, FabricTextureMap and SimpleBlockStateSupplier for easier data generation with Block Models & States.

[karatebiscuit]

Currently, data generation is very new and restricted. In this case, block model generation is very limited - being incredibly inaccessible and anything even slightly more complex than a cube_all model requires custom classes to be built for generating them. A FabricBlockModelSupplier would fix this issue, where you could easily simply provide the parent type and a (see below) new class - FabricTextureMap with the texture name and location, which can then be turned into a resulting JSON. As an example, creating a cube_column model can be easily made, like so - the SimpleBlockStateSupplier allows for no-variant based blockstates to be generated easily, because this isn't a built-in feature for fabric at the moment:

public static class ModelGenerator extends FabricModelProvider
{
    private static final Block CHEESE_LOG = // ... 
    public ModelGenerator(FabricDataOutput output) { super(output); }

    @Override
    public void generateBlockStateModels(BlockStateModelGenerator blockStateModelGenerator)
    {
        // We can create the block's model & simple state like so:
        blockStateModelGenerator.blockStateCollector.accept(new SimpleBlockStateSupplier(CHEESE_LOG, new Identifier("modid", "cheese_log")));
        blockStateModelGenerator.modelCollector.accept(new Identifier("modid", "cheese_log"),
            () -> new FabricBlockModelSupplier("cube_column") // The parent type is the parameter.
                .addTextureData(new FabricTextureMap("end", "side")
                    .set(new Identifier("modid", "block/cheese_log_end"), new Identifier("modid", "block/cheese_log_side")))
                .get());
    }

    @Override
    public void generateItemModels(ItemModelGenerator itemModelGenerator)
    {
        // ...
    }
}

Which would then be outputted as this, and if done correctly should also generate a basic block parent item model, as well - however some methods won't produce Item Models. Unsure as to the reason of this, looking into it.

{
  "parent": "minecraft:block/cube_column",
  "textures": {
    "end": "modid:block/cheese_log_end",
    "side": "modid:block/cheese_log_side"
  }
}

{
  "parent": "modid:block/cheese_log"
}

The creation of a FabricTextureMap not only could potentially help in the long run with other future classes requiring something similar but also, as a whole, it's much easier to use than a raw HashMap - it allows for the code to be more readable than initially (especially without double bracket indentation) and also reduces the line count and should also help reduce external variables being used when people wouldn't use double bracket indentation for the HashMap.

As a whole, I think these additions could greatly help the data generation part of fabric, although more specifically attributed towards Block Models - although the FabricBlockModelSupplier could work perfectly fine with Item Models, as well - for example, this is a snippet of how I had recently used it as a custom class for one of my mods more recently:

// Model Generator code...
protected void simpleItem(ItemModelGenerator generator, String ID)
{
	generator.writer.accept(new Identifier("modid", "item/" + ID),
			() -> new FabricBlockModelSupplier("modid", ID)
					.get());
}

@Override
public void generateItemModels(ItemModelGenerator itemModelGenerator) {
	simpleItem(itemModelGenerator, "myblockitem")
}

This generates a simple Item Model JSON like so:

{
  "parent": "modid:block/myblockitem"
}

This is because of the FabricBlockModelSupplier's support for custom model types and it's immediate initialization of the "parent" JSON.

[anscg]

LGTM!

[apple502j]

@hellvet3 Hmm, I'm sure vanilla has them?

[karatebiscuit]

Vanilla has some capabilities from what I know - but as a whole it's lacking a lot of features. What I showed was a class that could actually easily generate block model jsons, because there isn't many if not any built in classes for that already - but from what I can see anything that does actually generate Block Models aren't very accessible, customisable, etc.

As for the SimpleBlockStateSupplier it's mainly to generate BlockState files like this which (as far as I know) are just not creatable on it's own, for some reason:

{
    "variants": {
        "": {
            "model": "modid:block/myblockmodel"
        }
    }
}

Whilst I'd understand SimpleBlockStateSupplier not being merged, I do think a FabricBlockModelSupplier could seriously help because there isn't really a class vanilla or from the Fabric API that acts like this - the Block Model generation has almost if not nothing for it.

[apple502j]

Could you explain the difference between this and vanilla TextureMap?

[karatebiscuit]

Can't actually remember why I wrote that, I will probably have to exclude it from the commits - I'll look into it soon though as I'm currently away.

[karatebiscuit]

The difference between the two appears to be that the FabricTextureMap will just return the raw HashMap because it is much easier to access that way, the vanilla TextureMap appears to have no direct way to actually get the entries from a separate class, the existence of FabricTextureMap is to make it easier to create inline without the use of double-bracket indentation (since some don't know of it) for HashMaps, although initially it was just taking in a HashMap.

This is how we get the entries for a FabricTextureMap:

HashMap<String, Identifier> textureMap = fabricTextureMap.get();

You can't get the entries from a TextureMap - in fact, you can't access any of the inputted data without at least having one bit of pre-existing data. I'm contemplating whether to just revert back to the HashMap being a parameter or keeping it as FabricTextureMap, since some could argue it is technically redundant.

[Linguardium]

couldn't this be a simple interface injection to add a method to do so?

[karatebiscuit]

Yeah, it doesn't really matter to me which implementation we go for (HashMap parameter, interface injection, etc.) - I'm mainly focused on the FabricBlockModelSupplier and the SimpleBlockStateSupplier, the existence of FabricTextureMap isn't necessarily required, although helpful. It's more like syntax sugar.