[1.8] Custom block renderer?

[gcewing 40]

Is there any way to register a custom block renderer in 1.8?

 

In Greg's Blocks for 1.7 I have a block renderer that dynamically computes what to render based on information in the block's tile entity and those of surrounding blocks. There are too many variations on the shape to use a separate model for each one. The textures to be used also depend on the tile entity. I don't want to use a TESR because these blocks are typically used in large numbers, and re-rendered on every frame would be very inefficient.

 

I can't see how to handle this with the new rendering system in 1.8.

[TheGreyGhost 820]

Hi

 

Depending on what you want to do, an ISmartBlockModel might help.  The github for Forge has an example on how to use it.

https://github.com/MinecraftForge/MinecraftForge/blob/master/src/test/java/net/minecraftforge/debug/ModelBakeEventDebug.java

 

Haven't tried it myself, yet.

 

-TGG

[gcewing 40]

Someone please tell me this is all a bad dream...

 

It seems that to use ISmartModel I need to pass information from the tile entity to the model via an IBlockState.

 

That's not going to work. There are far too many possible states to encode that way. Plus I need information from adjacent blocks as well.

[TheGreyGhost 820]

Hi

 

You can have as many states or flags combined in IBlockState as you want.  You can't store more than 4 bits' worth in metadata, but that doesn't matter:

 

Some multiblock structures, such as BlockDoor or BlockBed, use a third method called Block.getActualState() which checks the IBlockState of the other blocks in the multiblock - this allows the multiblock to

synchronise the state of all blocks in the multiblock (eg BlockBed - OCCUPIED); and/or

store more than 4 bits' worth information- for example BlockDoor:

- the upper block of the door stores the HINGE position (LEFT/RIGHT), and whether the door is POWERED or not.

- the lower block of the door stores the FACING (NORTH, SOUTH, EAST, WEST) and whether the door is OPEN or not.

The same method Block.getActualState() is also used by blocks which change appearance depending on their neighbours - for example BlockFence, BlockRedstoneWire.

Block.getActualState() is generally called just before a render, to make sure the block has the correct appearance.

 

-TGG

 

[gcewing 40]

It still seems like terribly convoluted way of going about things. Seemingly I have to extract all the information out of my tile entity and encode it as Properties, only to immediately decode it again in my model. It would be much easier if I just got the world and position passed in directly.

 

Then in the model, instead of just rendering things using the tessellator, I have to construct a list of quads in a screwy low level format that involves shoehorning floats into ints? Really?

 

The whole thing feels like a massive kludge. The old way may not have been ideal, but it was easy to do unusual things with it. This seems very constraining.

 

I hate to think how mods such as Forge Multipart will deal with this. It's not going to be fun for them.

[TheGreyGhost 820]

Hi

 

The reason for introducing BlockModels is for the benefit of the resource pack creators, not the programmers.  IMHO that's the way it should be, no more ridiculous switch() statements in RenderBlocks for every type of block and special cases and instance of all over the place.  Much more extensible and modular too.

 

But yeah it is a lot more complicated for us.

 

-TGG

[gcewing 40]

Don't get me wrong, I don't object to the model-based system. For mostly-static rendering, it's fine, and a great improvement. But I don't like being forced to use it, and having to use ugly workarounds to make it more dynamic when needed.

 

The frustrating thing is that it doesn't need to be that hard. There's a place in BlockRendererDispatcher that switches on the block's renderType to choose between model rendering and fluid rendering. If there were a Forge hook in there to allow you to plug in a custom renderer at that point, like there used to be, all would be well.

 

Is there an official place to make Forge feature requests?

[LexManos 1633]

Models are the way Minecraft is going. Don't like it don't mod for Minecraft.

It's been mandated that we do not encourage people to use direct tesselator/GL calls.

The current system is functional, and if you design your TE/Models correctly highly efficient.