Block Rendering Hooks (NOT custom block hooks)

[Groxkiller]

Before someone tells me they have block render hooks, that is for custom blocks. What I'm suggesting is hooks for individual block renders, ie:

 

onBlockRenderPre(RenderBlocks renderer, Block block, int metadata, int x, int y, int z) - called before any world block render

onBlockRenderPost(RenderBlocks renderer, Block block, int metadata, int x, int y, int z) - called after any world block render

getBlockBrightness(EnumSkyBlock lightType, Block block, int metadata, int x, int y, int z, int currentBrightness) - Hook called to get the world brightness of the block.

 

These kind of hooks would be primarily useful in cases of wanting to alter coloration, add some render effect to a vanilla block, change light values, or some effect to a block's render. This would also allow for entities to (somewhat awkwardly) produce light on thier own.

 

The first two can easily be injected here (RenderBlocks.java):

    public boolean renderBlockByRenderType(Block par1Block, int par2, int par3, int par4)
    {
        int var5 = par1Block.getRenderType();
        par1Block.setBlockBoundsBasedOnState(this.blockAccess, par2, par3, par4);
        this.setRenderBoundsFromBlock(par1Block);

       //PRE HOOK HERE
        switch (var5)
        {
            // ... block render stuff
        }
        //POST HOOK HERE
    }

 

The Block Brightness hook would need to be put in the World class; it has far, far too many calls in RenderBlocks to be overridden there:

 

    public int getLightBrightnessForSkyBlocks(int par1, int par2, int par3, int par4)
    {
        //Sky brightness hook
        int var5 = eventMethodHere(EnumSkyBlock.Sky, this.getSkyBlockTypeBrightness(EnumSkyBlock.Sky, par1, par2, par3));
        // Block brightness hook
        int var6 = eventMethodHere(EnumSkyBlock.Block, this.getSkyBlockTypeBrightness(EnumSkyBlock.Block, par1, par2, par3));

        if (var6 < par4)
        {
            var6 = par4;
        }

        return var5 << 20 | var6 << 4;
    }

 

The Block Brightness hook would have complications if two or more people used it at once, so my suggestion would be to check which subscriber has the highest value returned and use that, or have a priority system like in other parts of Forge.

 

I hope this can be implemented as it would make custom lighting  and block render control a lot easier.

[Chancebozey]

the placement of your pre hook wont be very useful as the render methods that come after it check the block itself for color, light value and such or they define it in that method itself or it is predefined in the block class itself. Either way your pre hook will be overridden nearly every time or cause instability and crash. The post hook is useless as it will never be reached because of the switch to the render methods. To do as you suggested you would need to alter or rewrite the individual render methods and/or blocks associated with them.  If you are making your own block then do create your own custom render class. As for vanilla blocks your options are very limited. I hope this helps clarify things a bit as it can be confusing when trying to follow code paths.

[Groxkiller]

Thank you for the clarification, but after testing I can definitely confirm the last hook - for block brightness - will work. I still think it would be useful to make say a spotlight entity that can shoot a light from afar or a block that has a faked brightness radius greater than 16.

[LexManos]

Those things as such work fine, you just use invisible blocks.

[Groxkiller]

Those things as such work fine, you just use invisible blocks.

 

Yes but it won't work for glowing entities who are currently occupying the space of a non-normal block. (such as a fence, tall grass, cobble wall, glass panes, doors, trapdoors, webs, etc. etc.)

 

If your going to suggest making the block simply render the block it is occuping that won't work for every case (such as cobble walls, fences and doors) and if I make a new block for each non-normal one I'd be cloning a lot of blocks for one small job a hook could do.

 

For an example, Minecarts can't just plop an invisible block down as the block they are occupying already has a block in it - the rail. Putting it above the cart won't work either - you'd suddenly have a hollowed-out hole above the cart if it went down a 1 X 1 rail tunnel. The only solution in this case that I know of that would be practial would be the hook. (trust me, I tried doing it with the current system - at best it removes lighting already there, at worst it creates horrible light artifacts).

[LexManos]

Minecraft was not designed for entity based light, and adding in such a thing without proper design and testing will do nothing but horribly impact the performance of the game for very little value. As it stands, block based lighting is pretty much your only option right now.

There is however, already pre-and post world rendering hooks you can work with, however, performance is a huge issue, so for now we're not going to be adding in generic per-block hooks.