[1.10.2] Options for massive models (.obj)?

[Matryoshika]

So, I got a Menger Sponge iteration going for compressing blocks, in a project.
With compression iteration; [n < 3], there's no issues at all. [n = 1] .obj file is 9.5KiB. [n = 2] .obj file is 60.5KiB large... So we're starting to see the obvious  exponential growth in sizes here.
However, with [n = 3], the size suddenly skyrockets to 1.3MiB big.
That is, a tad too big for a model.
To answer first "why not just make the model smaller": The model has to be split in 27 parts on all axii, as a "face" cannot have a texture, and a smaller hole inside of it. That hole has to be surrounded by equally large solid faces.
Overall, the [n = 3] model has 19,584 faces, even with optimizations done. That is as small as I can get the model.

 

Now, with that out of the way.

As stated, I have this compression system. You put x blocks -> 1 new block.
It's configurable, to allow for compression for blocks in other mods.
Now, I've been copying a "main" model, and replacing names (of the file, and inside of it) to match the new block.
I don't want to clog all resources, if if there's let's say 20+ [n = 3] blocks.

 

Is there any way to go around the 1.3MiB models?
Can I use the same model, but keep the correct texture for each block (which are specified in the accompanying .mtl)
Would a custom OBJLoader work here? EG load the same model, but apply different texture to each?
Or something akin to "camouflaged" blocks, like TGG's MBE example MBE04?

Are there any other options? Or should I just stick with what I have??

Edited April 18, 2017 by Matryoshika
Fixed small misnomer

[Elix_x]

Use custom IBakedModel for your block.

In the getQuads method, find model of the "original" block and retrieve its' quads. Now, just re-add these qauds applying necessary transforms as many times as you want. You can find the basics of applying transformation matrices to quads here: https://github.com/Elix-x/EXCore/blob/rendering--vertex-pipeline/src/main/java/code/elix_x/excore/utils/client/render/pipeline_old/MatVecApplicator.java#L52.

 

And you probably also want to cache models to not recalculate quads each time (RIP FPS). I have a model cache here, it is free to use. Just register it as a reload listener and you're good to go.

[Matryoshika]

Thanks.
As far as I can see, you mean that I should merely use the base quads, and merely "clamp" them together into one model, translating them by a*n*0.33 where a equals axii, and n equals iterations per side, and jump over iterations [5, 11, 13,14,15, 17 & 22]
This brings up the issue with "find the model of the "original" block".

I never mentioned this in the OP, but I wanted to add the functionality of allowing full configurability for this compression, allowing any block to be compressed.
I keep to the preferred RegistryEvent, though most mods still use preInit for content-registration, so of course, there'll be nullpointers even if I used "after:*" in dependencies.
As such, I believe this can be surpassed by defining a block in-game (when the server is up), get the blockstate, get textures from it, serialize it (to a file), then after the next restart, actually add the new compressed blocks to the game, and have the new block invoke the original blocks methods (for consistency).

 

Anyone seeing any issues in doing it this way?

[Elix_x]

5 hours ago, Matryoshika said:

Thanks.
As far as I can see, you mean that I should merely use the base quads, and merely "clamp" them together into one model, translating them by a*n*0.33 where a equals axii, and n equals iterations per side, and jump over iterations [5, 11, 13,14,15, 17 & 22]
This brings up the issue with "find the model of the "original" block".

I never mentioned this in the OP, but I wanted to add the functionality of allowing full configurability for this compression, allowing any block to be compressed.
I keep to the preferred RegistryEvent, though most mods still use preInit for content-registration, so of course, there'll be nullpointers even if I used "after:*" in dependencies.
As such, I believe this can be surpassed by defining a block in-game (when the server is up), get the blockstate, get textures from it, serialize it (to a file), then after the next restart, actually add the new compressed blocks to the game, and have the new block invoke the original blocks methods (for consistency).

 

Anyone seeing any issues in doing it this way?

I did understand that you wanted to make support for all blocks, but i though that you have already set up the tile entity. Apparently you did not.

 

Tile Entities can be used to store additional data with blocks that is not serializeable in 4 bytes of metadata. And it is what you want to use to store the original block (or even IBlockState ). Just implement load/save to NBT methods to make sure that it is saved (Block can be saved by saving its' registry name, simple/meta-serializeable IBlockStateby saving block and serializing it into metadata and complex/not-serializeable IBlockState can be saved by saving block and than a map of properties to serialized values).

 

How to pass original block/state from tile to model? Implement Block#getUnlistedProperties (or similarly named method) - it allows to pass unlisted properties (properties that can store absolutely any values) to the IBaked. Now just create a (static) unlisted property holding original block/state and then in the method (you have both world and pos) retrieve tile, get original and store it in unlisted prop.

Now in the IBaked, you can back the original by retrieving value of unlisted property from state you have as param.

 

Getting model of the original: (i don't remember exact methods, so) Look through model classes - ModelLoader, ModelBakery. All models (items and blocks) should be cached there somewhere. Just find how to get to them.

 

PS: Try using this method of quads "clamping". If there will be important FPS drops, i have an idea on how to make it a lot better. But it involves interaction with Open GL directly (without MC engine & wrappers) and a lot of infrastructure. So if it is not required, there's no need in implementing it.

[Matryoshika]

Thanks, but you are jumping the gun a bit there at least.
I am talking about a mere block, that is based on another, and is nothing more than storage (Think ExtraUtilities compressed blocks, for example).

I never stated, nor implied that I was using a TileEntity in conjunction with these blocks, and I do not feel inclined to do so, unless I am forced to do so, due to rendering issues etc.

Storing data (original block|blockstate etc) can be done in the block, here, as the data is not meant to ever be changed.

 

Thanks for the rendering pointers though.

Edited April 19, 2017 by Matryoshika

[Draco18s]

Use the 60 KiB version and render it 22 times in slightly different places.

[Elix_x]

9 minutes ago, Matryoshika said:

Thanks, but you are jumping the gun a bit there at least.
I am talking about a mere block, that is based on another, and is nothing more than storage (Think ExtraUtilities compressed blocks, for example).

I never stated, nor implied that I was using a TileEntity in conjunction with these blocks, and I do not feel inclined to do so, unless I am forced to do so, due to rendering issues etc.

Storing data (original block|blockstate etc) can be done in the block, here, as the data is not meant to ever be changed.

 

Thanks for the rendering pointers though.

1. I forgot to mention -  since 1.8, Tile Entity =/= Lag. Because since 1.8, tile entities can be not tickable (aka not require update). Just look at Chisel & Bits - the great example.

2. This way, you will never support all the blocks. Minecraft Forge is limited to 4096 block ids and 16 states/block... In 70% of modpacks, amount of used up block ids can be easily beyond 60%. You just can't create duplicate for every variation in the space that is left.

3. Just don't tell me you store your data in a block like this:
 

public class CompressedBlock extends Block {
  
  public Block unCompressedVariant;
  
}

 

[Matryoshika]

 

43 minutes ago, Elix_x said:

You just can't create duplicate for every variation in the space that is left

8 hours ago, Matryoshika said:

I never mentioned this in the OP, but I wanted to add the functionality of allowing full configurability for this compression, allowing any block to be compressed.

I never stated I wanted to add compressed blocks for each and every block there is, merely support the option of adding new compressed blocks, based on other. I know some pack-maker's are painfully diligent, but I do not see anyone adding 100+ of these blocks.

 

I am aware of TileEntity no longer ticking off of the bat in 1.8+, but my... disdain for them, stems more from the rendering perspectives of TESR's, than the actual usage of TileEntities. I believed you were advising me to use TE's merely for rendering, which I now stand corrected in.

 

No, I do not store anything more than the tier, as I place each new block, in a custom registry.

Spoiler

	public CompressedBlock(IBlockState blockstate, byte tier){
		super(blockstate.getMaterial());
		this.tier = tier;
		this.setRegistryName(Echo.MODID, blockstate.getBlock().getRegistryName().getResourcePath()+tier);
		MengerRegistry.nonNullAdd(blockstate.getBlock().getRegistryName(), tier);
		this.setUnlocalizedName(getRegistryName().toString());
		this.setCreativeTab(Echo.TAB);
	}

The custom registry is a map with RegistryName & ArrayList containing the tiers. 1,2,3 etc. (Amount of tiers is also customizable)
Yes, I am well aware I am using a byte instead of integer. Why? Essentially, why not. Don't see anyone managing to get 20¹²⁷+ blocks of anything, not that I'm implementing such high compression.

I merely stated that storing data can be done in the block, not that I am doing so for every little tidbit, though I cannot fault you on that. I do believe I need to work on making myself more clear in these matters.

[Elix_x]

16 minutes ago, Matryoshika said:

I am aware of TileEntity no longer ticking off of the bat in 1.8+, but my... disdain for them, stems more from the rendering perspectives of TESR's, than the actual usage of TileEntities. I believed you were advising me to use TE's merely for rendering, which I now stand corrected in.

Well, tile entities can even be as simple data storage things now. Not be used for ticking nor for rendering.

16 minutes ago, Matryoshika said:

 

I never stated I wanted to add compressed blocks for each and every block there is, merely support the option of adding new compressed blocks, based on other. I know some pack-maker's are painfully diligent, but I do not see anyone adding 100+ of these blocks.

 

I merely stated that storing data can be done in the block, not that I am doing so for every little tidbit, though I cannot fault you on that. I do believe I need to work on making myself more clear in these matters.

Ok. I see now.

I'd still personally prefer tiles for this, but at this point it does not matter much.

 

16 minutes ago, Matryoshika said:

Yes, I am well aware I am using a byte instead of integer. Why? Essentially, why not. Don't see anyone managing to get 20¹²⁷+ blocks of anything, not that I'm implementing such high compression.

Because java's native/default type is integer?

Edited April 19, 2017 by Elix_x
Corrections

[Matryoshika]

1 hour ago, Elix_x said:

Because java's native/default type is integer?

"I need something to hold 5-7 books"
"The smallest room we have is a 2.56m² room, but I'm going to provide you a 42949672m² room"¹

*places books* echo...cho...ho...o...

 

¹Yes, I am aware that the difference is not that severe, memory wise. More like 8 vs 32, but it all boils down to me not wanting to soak up space, no matter how insignificant it is in the large span.

Edited April 19, 2017 by Matryoshika

[Draco18s]

8 hours ago, Matryoshika said:

I am aware of TileEntity no longer ticking off of the bat in 1.8+, but my... disdain for them, stems more from the rendering perspectives of TESR's, than the actual usage of TileEntities. I believed you were advising me to use TE's merely for rendering, which I now stand corrected in.

TESR are also no longer needed. You can use json models with tile entities just fine.