[1.15.1] Transparent Blocks, Arn't

[Ommina]

Perhaps it's too early to start asking about 1.15.1 rending changes.  But I'm going to anyway.

 

I've created a test mod with exactly one block.  Said block is merely an instance of the vanilla GlassBlock, using the vanilla Block.Properties (copied from Blocks):

 

Block b = new GlassBlock( Block.Properties.create( Material.GLASS ).hardnessAndResistance( 0.3F ).sound( SoundType.GLASS ).func_226896_b_() );
b.setRegistryName( "testglass" );
event.getRegistry().register( b );

 

Test Mod has one BlockItem for its lonely block:

 

event.getRegistry().register( new BlockItem( TESTGLASSBLOCK, new Item.Properties().group( ItemGroup.MISC ).maxStackSize( 64 ) ).setRegistryName( "testglass" ) );

 

And that's it.

 

Yet they render dramatically different:

 

https://imgur.com/a/UEcagsa

 

Texture is a copy/paste of vanilla's.  Item version DOES render fine in inventory.

 

Am I missing something here?  Or am I just experiencing the consequences of a lot of rendering changes within a very new Forge release?

Edited December 18, 2019 by Ommina

[Ommina]

I'm not a fan of bumping my own posts, but I want to throw this out here again before taking it to the bug tracker.

 

I've taken as much mod code out as I can, while still demonstrating my issue.  The whole code:

 

@Mod( "examplemod" )
@ObjectHolder( "examplemod" )
public class ExampleMod {

    @ObjectHolder( "testglass" ) public static Block TESTGLASSBLOCK;

    public ExampleMod() {

        MinecraftForge.EVENT_BUS.register( this );
    }

    @Mod.EventBusSubscriber( bus = Mod.EventBusSubscriber.Bus.MOD )
    public static class RegistryEvents {

        @SubscribeEvent
        public static void onBlocksRegistry( final RegistryEvent.Register<Block> event ) {

            Block b = new GlassBlock( Block.Properties.create( Material.GLASS ).hardnessAndResistance( 0.3F ).sound( SoundType.GLASS ).func_226896_b_() );
            b.setRegistryName( "testglass" );
            event.getRegistry().register( b );

        }

        @SubscribeEvent
        public static void onItemsRegistry( final RegistryEvent.Register<Item> event ) {

            event.getRegistry().register( new BlockItem( TESTGLASSBLOCK, new Item.Properties().group( ItemGroup.MISC ).maxStackSize( 64 ) ).setRegistryName( "testglass" ) );

        }

    }

}

 

With one blockstate json that points to the vanilla model:

 

{
  "variants": {
    "": { "model": "minecraft:block/glass" }
  }
}

 

And one item model json:

 

{
  "parent": "minecraft:block/glass"
}

 

And that's it.

 

https://github.com/Ommina/PaneInTheGlass if anybody is excited by a GitHub repository of the above.

[RaphGamingz]

On 12/20/2019 at 6:56 PM, Ommina said:

 

{
  "variants": {
    "": { "model": "minecraft:block/glass" }
  }
}

Shouldnt it be "examplemod":block/testglass

Because your using the model in your model json

 

And it might be because you did block.properties.glass

[Ommina]

Nope, I'm deliberately using the vanilla model because I want to remove as much mod code from the equation as I can.  So 'examplemod' blockstate points into vanilla's model, which in turn uses vanilla's texture.  (I did try using a mod model and a copy of the texture originally, but it made no difference.)

 

The Block.Properties.create( Material.GLASS ) bit is likewise a copy/paste of how vanilla creates its glass block.  I don't think there is some Forge-added Material that modders are supposed to use instead (it seems rather odd if there were), but I'll take a peek just the same.

[Braydongem]

Could this have anything to do with it?

[ChampionAsh5357]

You need to set the render layer using

RenderTypeLookup#setRenderLayer

within your FMLClientSetupEvent to make blocks transparent.

 

It takes in two parameters: the block and the RenderType.

The RenderTypes are as follows:

Solid - field_228615_R_

Cutout Mipped - field_228616_S_

Cutout - field_228617_T_

Translucent - field_228618_U_

Translucent (No Crumbling) - field_228619_V_

Leash - field_228620_W_

Water Mask - field_228621_X_

Glint - field_228622_Y_

Entity Glint - field_228623_Z_

Lightning - field_228624_aa_

 

What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

[Heltrato]

On 12/23/2019 at 5:33 AM, ChampionAsh5357 said:

You need to set the render layer using

RenderTypeLookup#setRenderLayer

within your FMLClientSetupEvent to make blocks transparent.

 

It takes in two parameters: the block and the RenderType.

The RenderTypes are as follows:

Solid - field_228615_R_

Cutout Mipped - field_228616_S_

Cutout - field_228617_T_

Translucent - field_228618_U_

Translucent (No Crumbling) - field_228619_V_

Leash - field_228620_W_

Water Mask - field_228621_X_

Glint - field_228622_Y_

Entity Glint - field_228623_Z_

Lightning - field_228624_aa_

 

What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

Thanks bro you dope, you know dopes makes me high and its good, no but for real thank you

[OrangeVillager61]

On 12/22/2019 at 4:33 PM, ChampionAsh5357 said:

You need to set the render layer using

RenderTypeLookup#setRenderLayer

within your FMLClientSetupEvent to make blocks transparent.

 

It takes in two parameters: the block and the RenderType.

The RenderTypes are as follows:

Solid - field_228615_R_

Cutout Mipped - field_228616_S_

Cutout - field_228617_T_

Translucent - field_228618_U_

Translucent (No Crumbling) - field_228619_V_

Leash - field_228620_W_

Water Mask - field_228621_X_

Glint - field_228622_Y_

Entity Glint - field_228623_Z_

Lightning - field_228624_aa_

 

What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

This is pretty helpful for me too, but what uses the RenderTypeLookup method in FMLClientSetupEvent? I can't find the method using the event or the block.

Edited February 3, 2020 by OrangeVillager61

[Cadiboo]

On 2/4/2020 at 8:20 AM, OrangeVillager61 said:

This is pretty helpful for me too, but what uses the RenderTypeLookup method in FMLClientSetupEvent? I can't find the method using the event or the block.

What do you mean?

[OrangeVillager61]

1 hour ago, Cadiboo said:

What do you mean?

Well, I'm wondering what holds the function so I can implement it such as, something.something.rendertypelookup.

Edited February 4, 2020 by OrangeVillager61

[Cadiboo]

On 12/23/2019 at 8:33 AM, ChampionAsh5357 said:

RenderTypeLookup#setRenderLayer

This means “an method called setRenderLayer in the class RenderTypeLookup”. (Usually “#” is the same as “.” but specifically means instance, however many people use “#”, “.” and “::” interchangeably which defeats their purpose).

 

On 2/4/2020 at 8:20 AM, OrangeVillager61 said:

This is pretty helpful for me too, but what uses the RenderTypeLookup method in FMLClientSetupEvent?

Your code will use RenderTypeLookup#setRenderLayer from inside the FMLClientSetupEvent.

 

RenderTypeLookup#setRenderLayer needs to be called after block registration on the client distribution so the FMLClientSetupEvent callback is the perfect place to call it. You need to be careful though as RenderTypeLookup and RenderType are client side only classes. This usually isn’t an issue as you’re using them inside a method that will only get called on the client, however, if you specify multiple RenderTypes for your via a lambda, you need to take extra precautions that your code isn’t loaded serverside because of how lambdas work. Therefore it’s best to subscribe to the FMLClientSetupEvent in a client only event subscriber (subscribed to the mod event bus obviously) rather than in your main class.

 

Since ChampionAsh wrote their response, mappings for 1.15.1 have been released. You should have updated your mappings to the latest (or latest stable) version and therefore should be referencing the mapped names not the SRG names in your source code.