Model advice for 1.8?

[jaquadro]

Okay, so I'm trying to update Storage Drawers to 1.8, and the more I poke at the model system, the more utterly depressed I'm getting.

Ostensibly, I want to actually use the model system for the drawers, because I think texture artists actually have a good reason to modify the models. But I need metadata bits for wood style and direction, and that totals 5-6 bits. From what I can see, Forge uses IUnlistedProperties, but from that point the rabbit hole gets deep and dark.

It is unclear to me, but is it possible to process a BlockState file with a combination of listed and unlisted blockstate properties? Essentially, wrap it up in some thin ISmartBlockModel, and avoid reimplementing huge swaths of the model system?

The few examples I can find dealing with ISmartBlockModels look horrible. If that's the path I have to go, well I have a private RenderBlocks implementation in my 1.7 mods already, and if I can subvert the model system entirely, all I need is access to a tessellator and a place to run it.

 

[FyberOptic]

"Unlisted" block states are specifically meant for data that has no bearing on appearance. When the block/item model files are initially processed, the game literally creates a baked model in memory of every single listed block state combination. This is why it's rather important that people keep unnecessary values hidden from that process and keep visible states to a minimum. Otherwise the game ends up with a model list even more massive than it already is, which has to be searched constantly to render any block or item and will gradually degrade any performance benefit of pre-generating the models (although their rendering code probably already does that).

The other thing you need to remember is that block states are currently not any better than metadata. The only time you can really take advantage of more than 4 bits worth of information is on the client. Nothing beyond that can be stored to the disk or transmitted between the client and server. In fact, if you try to save more than 4 bits of data through your getMetaFromState method, you'll overwrite neighboring blocks and other data in the block array, because hooray Mojang. The client can use as many states as it wants though, which might be useful for caching information for rendering and whatnot.

There is no access to the tessellator since Lex doesn't appear to understand modding. There are some mods out there which reimplement the traditional hooks, which are probably pretty good, I've just not tried them myself. You could add your own hook if you don't want a mod dependency, just make sure it's rather benign both in how it's added and in its behavior, since obviously there are several people doing this (which is apparently still not a hint).

I always emphasize to people that you can implement both traditional hooks and still take advantage of models. The biggest problem is that Forge doesn't make much effort to extend the model infrastructure to the modder, since their be-all end-all solution is ISmartBlockModel, so you're going to have to really poke around to find the proper functionality to access and trigger rendering of models in your custom rendering, as well as to insert your models into the proper lists when everything is loaded (which there's at least a hook to do).

To be honest you're probably better off just doing the hook (or a mod to do it) and your own RenderBlocks implementation, and worry about models later on after it all works. Given your limited audience for 1.8 there doesn't seem to be a lot of point in spending incredible effort on it unless it's just out of a personal challenge to learn how it all works.

 

[jaquadro]

"Unlisted" block states are specifically meant for data that has no bearing on appearance. When the block/item model files are initially processed, the game literally creates a baked model in memory of every single listed block state combination. This is why it's rather important that people keep unnecessary values hidden from that process and keep visible states to a minimum. Otherwise the game ends up with a model list even more massive than it already is, which has to be searched constantly to render any block or item and will gradually degrade any performance benefit of pre-generating the models (although their rendering code probably already does that).

I started figuring this out last night. It doesn't help that the best explained examples (MinecraftByExample) are using exclusively unlisted properties to read their render data in an ISmartBlockModel, and not using block states at all as a consequence. My current theory is I can setup real properties as I need to, create the standard blockstate file, and replace the mappings in the ModelBakeEvent with an ISmartBlockModel to give back the correct model based on IExtendedBlockState. Still working on an implementation to test that.

The other thing you need to remember is that block states are currently not any better than metadata. The only time you can really take advantage of more than 4 bits worth of information is on the client. Nothing beyond that can be stored to the disk or transmitted between the client and server. In fact, if you try to save more than 4 bits of data through your getMetaFromState method, you'll overwrite neighboring blocks and other data in the block array, because hooray Mojang. The client can use as many states as it wants though, which might be useful for caching information for rendering and whatnot.

I came to this conclusion after the first 1.8 build dropped and I opened a world in NBTExplorer. Very dissappointing that we got none of the promised benefits, and all of the unpromised inflexibility and overhead.

There is no access to the tessellator since Lex doesn't appear to understand modding. There are some mods out there which reimplement the traditional hooks, which are probably pretty good, I've just not tried them myself. You could add your own hook if you don't want a mod dependency, just make sure it's rather benign both in how it's added and in its behavior, since obviously there are several people doing this (which is apparently still not a hint).

I always emphasize to people that you can implement both traditional hooks and still take advantage of models. The biggest problem is that Forge doesn't make much effort to extend the model infrastructure to the modder, since their be-all end-all solution is ISmartBlockModel, so you're going to have to really poke around to find the proper functionality to access and trigger rendering of models in your custom rendering, as well as to insert your models into the proper lists when everything is loaded (which there's at least a hook to do).

To be honest you're probably better off just doing the hook (or a mod to do it) and your own RenderBlocks implementation, and worry about models later on after it all works. Given your limited audience for 1.8 there doesn't seem to be a lot of point in spending incredible effort on it unless it's just out of a personal challenge to learn how it all works.

Do you have any opinions on the techniques used in this project? My principal concern with any hook technique is interfering with other mods trying to do the same thing.

Storage Drawers is supposed to be my feasibility study for 1.8. Given the hell so far though, it's unlikely I'll try to port something like Garden Stuff past 1.7 until there's some well established systems in place.

 

[FyberOptic]

Do you have any opinions on the techniques used in this project? My principal concern with any hook technique is interfering with other mods trying to do the same thing.

Storage Drawers is supposed to be my feasibility study for 1.8. Given the hell so far though, it's unlikely I'll try to port something like Garden Stuff past 1.7 until there's some well established systems in place.

Well, I dunno. It replaces some things outright to implement its solution. Though due to the method it's using, it might actually be easier to track down when there's a conflict with another mod. And it also seems very similar to how the original ISBRH worked from the dev's point of view, which is a plus.

The one I've seen is RenderCore, which uses actual ASM hooks. It appears to implement more of the original 1.7 functionality than the other mod, while also extending some of the newer functionality to take advantage of as well. But it's a bit more complicated, including setting it all up to use.

 

[ljfa]

It will get really messy when different mods require different incompatible coremods for that.

 

[jaquadro]

I'm taking a wait-and-see approach for now. My above theory panned out and I've got the blockstate system working for Storage Drawers. But Garden Stuff? I'm not sure I can pull off everything even with a render core.

 

[InfinityRaider]

I'm taking a wait-and-see approach for now. My above theory panned out and I've got the blockstate system working for Storage Drawers. But Garden Stuff? I'm not sure I can pull off everything even with a render core.

I recommend the "skip-1.8-aproach" it's working very well for me.

 

[jaquadro]

I recommend the "skip-1.8-aproach" it's working very well for me.

That hasn't worked out too well for the 'skip-1.7' folks.

I don't see 1.9 getting magically better.

 

[Lethosos]

I don't see 1.9 getting magically better.

They haven't been walking widdershins around their workstations while chanting Job's creed and shaking their lucky rabbit's feet in the proscribed manner these days. Quality control, man!

Sent from my SGH-T769 using Tapatalk 2