Jump to content

[1.11.2] TileEntity Performance Question


Socratic_Phoenix

Recommended Posts

So this may be a vague question, but how performance intensive are tile entities?

 

Allow me to explain: I'm developing a new iteration of my mod, and I'm trying to weigh performance costs, but I don't really know how tile entities work. Basically, I'm trying to use 1 block as a sort of "flexible" block that can have whatever properties I assign to it, roughly. The tile entity itself would simply server too hold two nbt values: a long and an int. These values specify the definition of the block's properties. The reason I'd prefer 1 block is because I originally had 600 different blocks; 300 ores and 300 bricks. And, due to the nature of my mod, the textures for all these blocks were reloaded whenever the world started. It is also important to note that their will be a lot of these tile entities in the world, as they would generate as ores.

 

So, my question is, would it be less performance intensive to have one tile entity with two nbt tags (and no reloading textures), or to have these 300 ores that reload every time a world starts...

Developer of Randores (adds 256^3 ores to the game) and Arcane Bags (adds ridiculous storage with ridiculous crafting recipes).

I know Java pretty well... So yeah...

Quote

This is where I'd put an inspirational and/or clever quote, but I can't think of one right now...

This is the output of the totally, 100% working compiler for my programming language, Planet9:

Beginning Compilation...
Failed compilation!
planet9.compiler.error.CompilationException: Compiler not yet implemented
	at planet9.compiler.Compiler.compile(Compiler.java:39)
	at planet9.compiler.app.CompilerApp.main(CompilerApp.java:147)

 

Link to comment
Share on other sites

As long as your tiles do not implement ITickable they only affect the world load time. And that corresponds to the amount of data you put into your NBT. In your case it is a long(8 bytes) and an int(4 bytes) + vanilla TE data(position - 12 bytes, id - ? bytes(string - 2 bytes/char)) + some internal amount of bytes MC uses to "open and close" nbt tags, not sure how much that takes but I would be surprized if it takes more than 4-8 bytes. 

Long story short - it is mostly fine unless you push an insane amount of data into TE's NBT or make your tiles tickable. I am also using TEs for ores and I have not noticed any difference whatsoever between a world without them and a world with them.

Apart from that - could you explain a bit better about textures and 'reloading every time the world starts'. I can't quite make a connection between using a TileEntity and textures reloading. If you are going to do something that involves TESR of any kind - no, you will gain no performance. TESRs are quite heavy, even FastTESRs especially when there are lots of blocks in the world that use them as their buffers are computed each frame while IBakedModels just add their quads into a buffer on demand and that buffer is drawn each frame. If you mean a 'bake-on-demand' custom IBakedModel that depends on tile data - sure, that is fine if you use caching.

Edited by V0idWa1k3r
Link to comment
Share on other sites

10 minutes ago, V0idWa1k3r said:

As long as your tiles do not implement ITickable they only affect the world load time. And that corresponds to the amount of data you put into your NBT. In your case it is a long(8 bytes) and an int(4 bytes) + vanilla TE data(position - 12 bytes, id - ? bytes(string - 2 bytes/char)) + some internal amount of bytes MC uses to "open and close" nbt tags, not sure how much that takes but I would be surprized if it takes more than 4-8 bytes. 

Long story short - it is mostly fine unless you push an insane amount of data into TE's NBT or make your tiles tickable. I am also using TEs for ores and I have not noticed any difference whatsoever between a world without them and a world with them.

Apart from that - could you explain a bit better about textures and 'reloading every time the world starts'. I can't quite make a connection between using a TileEntity and textures reloading. If you are going to do something that involves TESR of any kind - no, you will gain no performance. TESRs are quite heavy, even FastTESRs especially when there are lots of blocks in the world that use them as their buffers are computed each frame while IBakedModels just add their quads into a buffer on demand and that buffer is drawn each frame. If you mean a 'bake-on-demand' custom IBakedModel that depends on tile data - sure, that is fine if you use caching.

Thanks, I'll be using TileEntities then.

 

To explain further, I was previously reloading textures every time the world starts. With the TileEntities, I'll be using BlockColors, not any special rendering.

Developer of Randores (adds 256^3 ores to the game) and Arcane Bags (adds ridiculous storage with ridiculous crafting recipes).

I know Java pretty well... So yeah...

Quote

This is where I'd put an inspirational and/or clever quote, but I can't think of one right now...

This is the output of the totally, 100% working compiler for my programming language, Planet9:

Beginning Compilation...
Failed compilation!
planet9.compiler.error.CompilationException: Compiler not yet implemented
	at planet9.compiler.Compiler.compile(Compiler.java:39)
	at planet9.compiler.app.CompilerApp.main(CompilerApp.java:147)

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.