Best option for rendering a modular block?

[AnZaNaMa]

Alright, so I have a block with a TileEntity that is basically a frame that will hold different "parts". I'm trying to determine whether I should use a JSON model (or OBJ) or a TESR. In the end, there will be quite a few unique parts that all will need to render differently and one of my blocks will need to be able to hold multiple different parts. I feel like if I tried to do this using JSON models, it would be way too complex. Also, I have experience using OpenGL apart from Minecraft so I'd probably be able use a TESR pretty well. I don't know if they will cause too much lag, though. Are they a lot more expensive than JSON models? I need the player to be able to use quite a few of these before they lag too badly.

 

Sorry if this question seems unclear. I find it difficult to put what I'm thinking into words. Is there some other option I'm missing or a better way to dynamically render a TileEntity?

[Draco18s]

TESR should only really be used if the model animates.

 

I can't really advise on how best to proceed trying to do this with JSON models, but if you do go TESR, go FastTESR.

[AnZaNaMa]

Well, the model probably will be changing a lot. I'm not sure if I'll be animating yet. I'll look into FastTESR

[Elix_x]

If you won't be animating, use custom IBakedModel. If you do want to animate, as Draco said, use Fast TESR.

 

By creating custom implementation of IBakedModel, you can override getQuads. In order to provide tile's data to get quads, pass unlisted properties from your block to model (override unlisted prop methods in your block class). getQuads is called each time model is drawn (item / in-world render update). So, in there, get baked models for all your parts, stream all the quads transforming accordingly, collect into a list and that list (considering your frame is rather a non-full block, you should do it only when side arg is null - side arg is for adjacency culling - ).

 

Example (might be too many files to all link here) : IBaked, Helper, Uses client baked lib and client baked pipeline (and here), Model reg manager for using loaded & mapped json/obj/baked models for custom stuff, and a lot more...

Edited September 30, 2017 by Elix_x
Example & Links 2

[AnZaNaMa]

Oh boy, what have I gotten myself into... I'm already half-way through creating a FastTESR, so I'm going to see how well that does. I'll probably end up coming back to this, though.

[AnZaNaMa]

Honestly, I was pretty overwhelmed reading through that the first time. However, on closer inspection this doesn't seem all that complicated. I'm just wondering - if getBakedQuads is called every frame, how is it more efficient than a TESR or FastTESR? I mean, obviously it may be because with a TESR, I'd be pushing and popping matrices, and drawing point-by-point and whatnot, but doesn't that eventually have to be done anyway, whether I give Minecraft a BakedModel, or I just render it myself?

[Draco18s]

19 minutes ago, AnZaNaMa said:

getBakedQuads is called every frame

It isn't. Its only called when the chunk is re-rendered, which is only whenever a block in that chunk changes state.

[AnZaNaMa]

Oh, okay. So @Elix_x I don't really understand how you're passing the TileEntity to the getQuads(). I know you're using some sort of workaround with the UnlistedPropertyGeneric, but I don't see what's going on. Is there any chance you could give an example of passing the TileEntity to getQuads() without the Optionals and lambda functions? I'm not well versed in Java 8, so it's extremely confusing to me.

[AnZaNaMa]

Actually, I think I may have managed to figure it out. Here's what I'm doing in getQuads() to access the TileEntity:

@Override
    public List<BakedQuad> getQuads(@Nullable IBlockState state, @Nullable EnumFacing side, long rand) {
        if(side != null) {
            return Collections.EMPTY_LIST;
        }
        IExtendedBlockState extState = (IExtendedBlockState)state; 
        TileEntityBase  tile = (TileEntityBase)extState.getValue(UnlistedProperty.BLOCK_ACCESS).getTileEntity(extState.getValue(UnlistedProperty.POS));
    }

 

Are you using the UnlistedPropertyGeneric.WORLD and UnlistedPropertyGeneric.TILE elsewhere, or am I missing something? Do I need to map these properties to the block somewhere else so that I can actually access them without error here?

[Elix_x]

Yep, you have to declare them in block class to make MC know about them, and actually provide/update them.

FYI: This is similar for saved, actual and extended props. The declaration of all 3 is in createBlockState, saved props are handled by meta<->state methods, actuals by getActualState and extended - by getExtendedState. The difference between actual and extended, is that actual is used on server and client, has a limited number of serializeable values it can take and can be used in state mapping (~json model). Extended state is used only on client, can take any values of any type, and cannot be used for state mapping - aka only custom IBaked models.

 

FYI 2: Actually, if you can create a single unlisted property for tile entity and pass it directly, instead of world and position. I'm just using 2 separate props, because i'm using them for other blocks too, which don't always have a tile entity, or i simply don't need it.

[AnZaNaMa]

Thanks for your help! I was doing some more research and found another topic here where you linked a topic related to IBakedModels, but it seems the link doesn't work anymore. Don't suppose you know how I can find it?

[Elix_x]

Hmmm....

 

Doesn't look like this thread exists anymore. It seems like it was long ago enough for it to vanish somewhere... And me to forget what exactly was it about.

[diesieben07]

19 hours ago, Elix_x said:

Yep, you have to declare them in block class to make MC know about them, and actually provide/update them.

I am sorry, but this is precisely what not to do. Blockstate properties (unlisted or not) may be passed off to a rendering thread, which must not interact with the main game objects like the world. This is precisely why block states work the way they work. If you must pass custom data through unlisted properties, you must grab it all in getExtendedState and then pass it into the block state as an immutable (or immutable-like, i.e. not changing anymore) object. An IBlockState object should never suddenly change it's contents, which yours does, since the World can and will change.

[Elix_x]

1 hour ago, diesieben07 said:

I am sorry, but this is precisely what not to do. Blockstate properties (unlisted or not) may be passed off to a rendering thread, which must not interact with the main game objects like the world. This is precisely why block states work the way they work. If you must pass custom data through unlisted properties, you must grab it all in getExtendedState and then pass it into the block state as an immutable (or immutable-like, i.e. not changing anymore) object. An IBlockState object should never suddenly change it's contents, which yours does, since the World can and will change.

I understand that concurrency is an issue that can occur at any time. But what's the other way of passing required information to the model? You could compile everything you need into immutable objects to be passed, and that work on that in tessellation, but that creates compilation (+decompilation) overhead.

[diesieben07]

20 minutes ago, Elix_x said:

You could compile everything you need into immutable objects to be passed

That is exactly the way to go.

[Elix_x]

3 hours ago, diesieben07 said:

That is exactly the way to go.

But getExtendedState is called on the same thread, and right before getQuads... So, would it not change anything?

[diesieben07]

16 minutes ago, Elix_x said:

But getExtendedState is called on the same thread, and right before getQuads... So, would it not change anything?

To be honest, that sounds like a bug then, because it is not at all save to interact with the World or let alone TileEntities in that thread.