[1.8] Connected textures in 1.8?

[NoonShadow]

Ok, so I have looked all over the place for a tutorial on connected textures.  I have gone and looked at the default fence code,but, that makes little to no sense at all.  I have a reasonable amount of experience with programming and have gotten my hands dirty in model files and other aspects of item and block rendering, but this just seems to elude me.  Anyone got some insight or tutorials that I could go read?  Am I missing something insanely simple?

[Choonster]

Most blocks store the value of each of their properties in the metadata, which is saved with the world; but some blocks have properties whose values are only determined at runtime and aren't saved in the metadata.

 

The individual connection properties of

BlockFence

are an example of these unsaved properties: they're not stored in the metadata, they're only determined by calling

Block#getActualState

. This returns an

IBlockState

with each connection property set based on blocks adjacent to the fence at the specified position (

BlockFence#canConnectTo

).

 

Minecraft calls this method before choosing the model to render at each position (though it's also called in a few other places), allowing you to choose the model based on information only available at specific positions like neighbouring blocks or values from a

TileEntity

.

 

I don't have any examples of connected textures using this system, but I do have a few other blocks that use it:

• BuildCraft-like pipes that connect to adjacent pipes:

  [url=https://github.com/Choonster/TestMod3/tree/dc884dbe20a1fa803ef4d7be2fd7d3babfda3d8d/src/main/java/com/choonster/testmod3/block/pipe]Block[/url]

  classes, blockstates file
  

• Coloured rotatable blocks with values stored in a

  TileEntity

  :
  

  • Coloured Rotatable:

    [url=https://github.com/Choonster/TestMod3/blob/dc884dbe20a1fa803ef4d7be2fd7d3babfda3d8d/src/main/java/com/choonster/testmod3/block/BlockColoredRotatable.java]Block[/url]

    ,

    [url=https://github.com/Choonster/TestMod3/blob/dc884dbe20a1fa803ef4d7be2fd7d3babfda3d8d/src/main/java/com/choonster/testmod3/tileentity/TileEntityColoredRotatable.java]TileEntity[/url]

    , blockstates file
    

  • Coloured Multi Rotatable:

    [url=https://github.com/Choonster/TestMod3/blob/dc884dbe20a1fa803ef4d7be2fd7d3babfda3d8d/src/main/java/com/choonster/testmod3/block/BlockColoredMultiRotatable.java]Block[/url]

    ,

    [url=https://github.com/Choonster/TestMod3/blob/dc884dbe20a1fa803ef4d7be2fd7d3babfda3d8d/src/main/java/com/choonster/testmod3/tileentity/TileEntityColoredMultiRotatable.java]TileEntity[/url]

    , blockstates file
    

[NoonShadow]

The code that I looked at made sense for the pipe, but does it have to be that complex for a simple block?  I am not sure that I completely understand how connected textures on a block would work.  Would I have to make separate textures for each scenario and have it change models when a neighbor changes?  All of the code that I can find the implements connected textures is for 1.7.10, so I have no clue how they did it to begin with.

[Choonster]

I had a look at Chisel's 1.7.10 CTM code and it's pretty complex. For each face, it checks for connections to all eight blocks surrounding the face and chooses the appropriate sub-icon from  to render in each quarter of the face.

 

It's probably possible in 1.8, but it will be tricky to implement using the standard blockstate/model system. You'll probably need a model composed of eight 8x8x8 cubes (a full block is 16x16x16) and a property for each corner of each face with seven possible values:

• not connected
  
• connected on side A, connected on side B
  
• connected on side A and B, connected on side A and diagonal, connected on side B and diagonal
  
• connected on side A, B and diagonal

 

The value of this property will determine which texture you use for the corner. The individual cubes only need to have their outside faces defined, the inside faces don't need to be rendered.

 

Forge's blockstates format will come in handy here.

 

Using a custom model class may make things easier, but I don't know much about the system.

[ZeroNoRyouki]

Connected textures are one of the things that had me banging my head on a wall for some time...

 

For a simple block you could check out this class of mine:

 

https://github.com/ZeroNoRyouki/TestMod18/blob/master/src/main/java/zero/mods/testmod18/common/blocks/OrnatedEmeraldBlock.java

 

http://s18.postimg.org/ndkwmm2ed/IMG_3012.jpg[/img]

 

All the work is done, as stated by others before me, in getActualState. There is no actual state saved in the in-world blocks metadata

 

The isAdjacentBlockOfMyType method is just an helper function that check if and adjacent block is of the kind of the calling block

 

Please note that this is just a test mod I use to try stuff so the code is not, uhm, production-grade

 

The blockstate file is an ugly mess:

 

https://github.com/ZeroNoRyouki/TestMod18/blob/master/src/main/resources/assets/testmod18/blockstates/ornatedEmeraldBlock.json

 

I've tried to use the forge blockstate variant when I worked on some multiblocks code but I didn't find it usefull in this situation.

 

Hope this could be of help

 

Z

 

[NoonShadow]

Ok, so the code worked great, I successfully created a block that connects textures, however, I am not sure how to define the inventory model.  I have an item model, but, I do not know how to get it to use that for the inventory model.  Any ideas?  Thanks so much ZeroNo, this has been a great help.

[Zarathul]

Don't know if it's the best way, but it works for me.

 

(preInit)
GameRegistry.registerBlock(yourBlock, yourBlockItem.class, yourBlockName);

(init)
Item yourBlockItem = GameRegistry.findItem(yourModId, yourBlockName);
Minecraft.getMinecraft().getRenderItem().getItemModelMesher().modelMesher.register(yourBlockItem , 0, new ModelResourceLocation("yourModId:yourBlockName", "inventory"));