[1.12.2] Do custom blocks render (or generate) slower (cause more lag) than vanilla?

[jabelar]

So I was working on making a mod that has a new dimension with terrain made from custom blocks. But I found the dimension was lagging a lot (actually it seemingly would run out of memory). I thought it was a bug in my code, so I kept simplifying until all my chunk generator did was generate a sea-level's worth of a single custom block. It was still laggy and running out of memory. So then I tried using a vanilla block and it worked much much better. I was starting to sense that it wasn't my chunk generator logic at all but rather something about the performance of custom blocks.

 

My custom block is super simple. It is copied after Block.ICE and except having its own texture and different slipperiness value I don't think there is any difference. I can show my code except I've been really ripping it up to try to debug so whenever you look at it I can't promise it is in working state: https://github.com/jabelar/ExampleMod-1.12

 

So then I decided to do a very simple experiment. I created a SuperFlat preset that made 1 layer of bedrock then 64 layers of my custom block. It also lags horribly then finally runs out of memory! I then did same preset using vanilla ice block and it works fine.

 

I'm suspecting it has to do with rendering, but may have to do with the generation itself since the generation seems to lag, but it really seems performance (or memory usage) is noticeably worse with a simple custom block. 

 

Has anyone generally experienced more lag when creating a dimension with custom blocks? if you get a chance, try comparing superflat with 64 layers of one of your custom blocks versus vanilla block...

 

My computer has decent specs -- i5 3GHz CPU with 8GB ram and GTX760 graphics card. I could try it on my gaming PC with GTX1080 instead, but I feel this PC should be sufficient. I have the VM getting 4GB heap. 

Edited January 29, 2018 by jabelar

[Draco18s]

Custom blocks do not take any more time to use during worldgen than vanilla blocks.

 

There's almost always something else at fault (e.g. using a block with a TE will be slower).

[jabelar]

Okay, but it is a really simple block. No TE at all.

 

So I found the culprit. It is a rendering performance issue. If you set the shouldSideBeRendered() method to return true, it lags horribly then crashes on its own. 

 

This block class lags horribly:

public class BlockCloud extends BlockIce
{

    public BlockCloud()
    {
        super();
        
        // DEBUG
        System.out.println("BlockCloud constructor");
        
        setTickRandomly(false);
    }
  
    @Override
    @SideOnly(Side.CLIENT)
    public boolean shouldSideBeRendered(IBlockState blockState, IBlockAccess blockAccess, BlockPos pos, EnumFacing side)
    {
        return true;
    }
}

 

Removing the shouldSideBeRendered() and it works great, no lag or crash.

 

I suppose it makes sense as it is a larger rendering burden. However, I was hoping to enable this because these cloud blocks are translucent but when you mine down into them if you don't have the shouldSideBeRendered enabled then they become invisible which I didn't want...

 

I don't suppose anyone knows of a solution? Guess it is expected if you have a bunch of translucent blocks being rendered fully...?

Edited January 29, 2018 by jabelar

[Draco18s]

Oh, oh yeah, that would be a problem.

I would make that function match other translucent blocks like Glass and Water, where it doesn't render the interior surfaces, just the exterior.

[Cadiboo]

Sorry for the bump, but the solution to this is to check if the block on the side is not opaque/normal.

return !world.getBlockState(pos.offset(facing)).isNormalCube(); inside shouldSideBeRendered should do the trick. Returning false if the BlockState is of the same type as your block is probably also desirable. 

Edited March 3, 2019 by Cadiboo