Skip to content

Conversation

@zomb-676
Copy link

the origin logic for setting render type is this

for (Block block : ForgeRegistries.BLOCKS.getValues()) {
    BlockState state = block.defaultBlockState();
    Predicate<RenderType> predicate = getLayerCheck(state, Minecraft.getInstance().getModelManager().getBlockModelShaper().getBlockModel(state));
    if (predicate != null) {
        blockRenderChecks.put(block.delegate, getExistingRenderCheck(block));
        ItemBlockRenderTypes.setRenderLayer(block, predicate);
    }
}

the problem is that it only considers the default block state's model.
for example, the redstone ore's default block state is LIT:false .
if I only set the LIT:true model and need it to use layer/rendertype cutout

private @Nullable Predicate<RenderType> getLayerCheck(BlockState state, BakedModel model) {
    if (model instanceof AbstractCTMBakedModel ctmModel) {
        return layer -> ctmModel.getModel().canRenderInLayer(state, layer);
    }
    if (model instanceof WeightedBakedModel weightedModel) {
        return CachingLayerCheck.of(state, weightedModel.list, wm -> wm.getData());
    }
    if (model instanceof MultiPartBakedModel multiPartModel) {
        return CachingLayerCheck.of(state, multiPartModel.selectors, Pair::getRight);
    }
    return null;
}

the Predicate produce function will just return null as the LIT:false model is not any instance below
the layer/rendertype setting in LIT:false model is ignored

so , just use block.getStateDefinition().getPossibleStates() and Predicate#or to consider all models' setting

the problem is that if a block has many states, this may become a performance issue.
though forge add canRenderInLayer to replace getRenderLayer to allow one block to have multi rendertypes
current implementation just convert parameter from blockstae -> state
the map which stores the information is also Map<IRegistryDelegate<Block>, Predicate<RenderType>>
though we can just cache solid, cutout_mipped, cutout, translucent, tripwire
but it is not good for rendertype usage like MinecraftForge/MinecraftForge#8331

@tterrag1098
Copy link
Member

Yeah, the potential performance hit of this on blocks that might not even utilize it is too much to accept. Fortunately forge is including this feature itself in 1.19, so it's probably best to just leave it alone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants