[Suggestion] Additional IBakedModel Interfaces - Large Possibility

[EverythingGames]

Hi, the title describes the basic idea of adding more interfaces to the new rendering system. As of now, we have:

1.) ISmartItemModel - Customizes the model based on the ItemStack's NBT

2.) IPerspectiveAwareModel - Customizes the model based on the camera transform

3.) IFlexibleBakedModel - Customizes the model based on the returned VertexFormat

 

New suggested interfaces would be (Names are somewhat accurate to their description and are made up):

1.) IEntityItemModel - An interface allowing the entityitem's model to be changed

2.) ICombinedItemModel - An interface allowing the flexibility of being able to easily combine two models together, allowing both of them to use their own independent transform values / matricies (translation, rotation, scale).

 

As with suggesting something, there must be a reason for these suggestions:

 

IEntityItemModel

1.) Before IItemRenderer was removed, modders were able to render their items in different perspectives - including the entity item. This isn't possible with the new rendering system as of now.

 

ICombinedItemModel

2.) When trying to render two models together while returning a list of BakedQuads, the models rendered both get the same transform values (transformation, rotation, and scale). Think of the new models that could arise from being able to combine multiple models together into one, while each of them still being able to use their own independent transform values (again, transformation, rotation, and scale) provided by their .JSON's. This would help resourcepack authors, as well as mod developers, tremendously.

 

Additional Benefits From Suggestion:

Another thing to consider is that people would be finished with using IItemRenderer in 1.7.10, be more eager to adapt to the new modeling system, and would stop addressing to bring IItemRenderer back - considering these interfaces would allow mod developers to do anything they once did with IItermRenderer with additional, helpful features, while also including the resourcepack authors.

 

Hopefully these new interfaces suggested can be implemented, considering their wide array of possibilities. Thanks for taking the time to read my suggestion!

[EverythingGames]

That is correct to a certain extent. IPerspectiveAwareModel only allows you to change the model based on first person, third person, gui, and head. The only way you can modify the entity item model is if you listen for when the player drops and picks up the item via events, where you then set NBT there, and then check the NBT in ISmartItemModel and return a different IBakedModel there based on the NBT. So no, you actually have to use events, ItemStack NBT, and ISmartItemModel. I don't see IPerspectiveAwareModel doing anything there. I actually had to do this because I needed to change the model as soon as I dropped it on the ground and picked it back up. That's the case that you would need this for, it'd make code a lot cleaner and would reintroduce a feature from IItemRenderer.

 

To be honest, I don't see why EntityItem isn't a transform type (that would be better than the new interface, IEntityItemModel) is. That should be added so that you can return a model beforehand just like with first person, third, etc.

 

As for the second interface suggestion, I think that would be a great feature. Again, more features and capabilities to make an easier, more complex model.

[Abastro]

You can do more things with IModel implementation than ICombinedItemModel.

On IPerspectiveAwareModel, I think there should be something like entityItem mode, too.

[TrashCaster]

The ability to override the GL texture would be nice too, using ItemStack as a parameter. This way you could use dynamic textures without having to stitch a dynamic TextureAtlasSprite. I've tried to make an item have dynamic textures the way a clock and compass do, and not only is that hokey, it's a pain in the ass that I couldn't get to work for me, no matter what I tried.

 

So being able to re-assign a GL texture ID before the item is rendered would be awesome. Maybe even another parameter that identifies the current texture path of the render pass, so you can change the texture from both the NBT, as well as which texture layer to override.

[LexManos]

The ability to override the GL texture would be nice too, using ItemStack as a parameter. This way you could use dynamic textures without having to stitch a dynamic TextureAtlasSprite. I've tried to make an item have dynamic textures the way a clock and compass do, and not only is that hokey, it's a pain in the ass that I couldn't get to work for me, no matter what I tried.

 

So being able to re-assign a GL texture ID before the item is rendered would be awesome. Maybe even another parameter that identifies the current texture path of the render pass, so you can change the texture from both the NBT, as well as which texture layer to override.

No, there are better ways to achieve the desired effect without screwing with gl shit. And the benefit of using a standardized atlas performance wise far outweighs your issues with it.

[TrashCaster]

The ability to override the GL texture would be nice too, using ItemStack as a parameter. This way you could use dynamic textures without having to stitch a dynamic TextureAtlasSprite. I've tried to make an item have dynamic textures the way a clock and compass do, and not only is that hokey, it's a pain in the ass that I couldn't get to work for me, no matter what I tried.

 

So being able to re-assign a GL texture ID before the item is rendered would be awesome. Maybe even another parameter that identifies the current texture path of the render pass, so you can change the texture from both the NBT, as well as which texture layer to override.

No, there are better ways to achieve the desired effect without screwing with gl shit. And the benefit of using a standardized atlas performance wise far outweighs your issues with it.

 

Are there examples on how to achieve dynamic textures based on NBT? Note, I do not mean "change between a series of pre-done textures in the assets", I mean the ability to programmatically generate textures for items.

[Ernio]

Yes. If you need so much variety that it is not worth caching e.g 100000 different models on startup, you can generate them on-run.

 

You have to dive quite deep into vertex data of BakedQuad format. You can literally generate BakedQuads and return them in ISmartItemModel inside List<BakedQuad>.

 

Have a look at this:

https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java

 

And yeah - learning vertexes gonna take some time and is pain in the ass.

 

You can also track down vanilla code responsible for generating models from textures - it uses similar methods.

[TrashCaster]

Yes. If you need so much variety that it is not worth caching e.g 100000 different models on startup, you can generate them on-run.

 

You have to dive quite deep into vertex data of BakedQuad format. You can literally generate BakedQuads and return them in ISmartItemModel inside List<BakedQuad>.

 

Have a look at this:

https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java

 

And yeah - learning vertexes gonna take some time and is pain in the ass.

 

You can also track down vanilla code responsible for generating models from textures - it uses similar methods.

 

This is not at all what I was referring to. TEXTURES, not models. I am programmatically generating TEXTURES. And I want to bind GL textures I generate to a quad over top of the builtin/generated sprite. Making the quad is no problem. But the only way to get the texture to show up is to use the hokey methods provided using custom TextureAtlasSprites.

 

If there's a way to stitch a GL texture into the Texture Atlas, using the texture key of a dummy texture, that'd work fine too, so long as you can pick the GL texture from the item stack's NBT.