How to force Minecraft to render a specific block

[Rikka0_0]

My mod has some multi-block structures. In a structure, most blocks are invisible and used as placeholders, only one block has a visible model (huge one, much bigger than 1x1x1).

In most case, it just works fine, however the structure becomes invisible when I look at it from some perspective.

I believe the game thinks that this block can not be seen by the player, so the entire structure is not being rendered.

Is there any way to force the game to render a block? (Of course I can split my huge model into smaller ones, but it is going to take a lot of time and effort, and not elegant QAQ!!!)

TTTThanks in advance

[Rikka0_0]

1 hour ago, gummby8 said:

Not sure if it exists in blocks, but for entities you set ignoreFrustumCheck to true

true, for entities/tileentities, it is easy to do.

The reason why im not using TESR is the performance loss, my model is stationary. No animated parts.

 

I had a look at the vanilla rendering code, Minecraft does not render RenderChunks(16x16x16 instead of 16x256x16!) which are considered to be invisible to the player.

RenderGlobal#renderContainer holds a list of visible chunks, only these chunks will be rendered.

Seems that its impossible to attach any other RenderChunk to the list. RenderGlobal#renderContainer is private and there's also no way to get an instance of a RenderChunk from BlockPos. Vanilla clear the list before collecting visible chunks and after rendering them. If forge can have a hook inserted just before this.renderBlockLayer(blockLayerIn), its going to be tremendously helpful!!

[jabelar]

I think you should just create a stationary invisible entity placed at the source block location, give it the model, and ignore the frustum check.

 

Of course that would only take care of the issue of seeing the structure. In both cases, as block model or entity model, you'll have to do some tricky stuff to add collision boxes where necessary.

[jabelar]

1 minute ago, diesieben07 said:

You might as well use a TESR at that point...

Does that allow the ignore frustum? I suggested an actual entity because I have experience knowing that ignoring frustum works for that.

[jabelar]

9 minutes ago, diesieben07 said:

Yes, you can override getRenderBoundingBox in the TileEntity. Forge does this for the beacon, for example.

Ahh, good to know. Thanks.

[Rikka0_0]

19 hours ago, diesieben07 said:

You might as well use a TESR at that point...

TESR is resource consuming QAQ I try not to use TESR to render stationary stuff.

And break down the whole model into submodels...I dont think thats an elegant solution....

 

If I can insert a line of code inside a vanilla class, that is going to help a lot, and perhaps help to solve similar problems like this one.

I might end up with writing a coremod or submit a Forge PR QAQ

 

Also, I noticed that there's something new called FastTESR, is possible to render a bakedmodel in a FastTESR? and how is the performance?(compare to ordinary block model rendering and TESR)

[Cloudy]

There's information on FastTESR'S here: https://mcforge.readthedocs.io/en/latest/tileentities/tesr/

[jabelar]

Also, although it is good to think about performance the reality is that modern computers are getting faster and faster and a performance problem is only going to arise if you have a lot of something (or if you have big, recursive loops in your code, like scanning over lots of locations for something).

 

In programming it is usually recommended to do things the "proper" way first -- meaning the typical, expected and readable way -- since that usually avoids introducing new bugs and makes it more easy to maintain. Then you should profile your code and see if there are any areas of undue performance burden and the rewrite those if needed.

 

In other words, beds, chests, signs and other common minecraft stuff already use TESRs, so unless you expect to have a lot of your structures in the game then it shouldn't be much worse.

 

Lastly, I hope that each version of minecraft gets performance improvements. I know sometimes they go backwards -- I remember that 1.8 had a bunch of lag issues -- but generally would expect it to get better. For example, maybe TESRs are more efficient in 1.12.1. Only way to know is to profile.

 

Yes it is good to consider performance, but if you're going to go to coremods without even knowing how bad the performance is I suggest that you do more testing first.

Edited September 6, 2017 by jabelar

[Rikka0_0]

One of my friend points out a possible solution: at the end of the model baking phase, the huge baked model is splitted into smaller models, (each small model occupies a volume of a block) and then assign these smaller models to blocks. (I already have some invisible blocks to make collision boxes working properly). I'm thinking about doing this, so I don't have to modify my .obj model file.

 

Back to 1.7.10. I used to have a lot of TESRs to render my power poles, if I have lots of them, the fps can drop by about 15. (At that time my graphic card was HD3000). After migrating the rendering stuff to ISimpleBlockRenderHandler(ISBRH), the fps no longer drop that much. So I conclude that TESR degrade the performance.

Edited September 7, 2017 by Rikka0_0

[Rikka0_0]

1 hour ago, diesieben07 said:

Ensure that it was not actually the ticking TileEntities that hurt the performance.

It does nothing in the TileEntity ticking.

[Rikka0_0]

37 minutes ago, diesieben07 said:

Why is the TE ticking in the first place then?

In 1.7.10 there was no ITickable. /w\

 

[Draco18s]

canUpdate()