EnderIO Glass compatibility
xenoflot opened this issue ยท 19 comments
Hi,
Not sure whether this is something for you or for Crazypants but I've found that with C&B ver 12.1 and EIO ver 3.0.1.95 (ECore 0.4.1.51b) I'm unable to chisel Ender IO's glass. It would be nice to be able to do so.
Discovered tonight that we can make dual texture blocks. So much love! Thank you for a great mod!
If you want to chisel someone else blocks please ask them to mark it as compatible,
I don't manage a white-list of blocks, and glass normally doesn't meet the requirements that C&B uses to auto-detect compatibility, for glass they have two options,
either they can return true for isFullBlock, which in my testing seems to work fine for glass.
Or they can send an IMC to C&B to tell C&B that the block can be chiseled, Example:
https://github.com/SlimeKnights/TinkersConstruct/blob/0076db29be2ad1c8ec84989e86866d1b738a1542/src/main/java/slimeknights/tconstruct/plugin/ChiselAndBits.java#L32
I tried it with the IMC. Sadly our glass's textures aren't picked up correctly:
That is the item (update: correct) texture with the transparency missing on the south side, no texture on the other sides, and it is detected as solid. So, any ideas how to tell c&b what the correct texture and tint values are "manually"? It isn't that hard for our glasses, there are only 2 textures and 16 tints...
(update: the texture is the right one, I forgot that we only render the borders and to save texturemap space we re-use the item texture. That'd be easy for me to change.)
PS: Also, the Reinforced Obsidian block isn't picked up quite correctly:
The up and down sides are flat colored instead of textured and the texture of the other 4 sides is mirrored. Again, anything I can to to help c&b pick up the block correctly?
C&B detects the textures from the sides, if there are multiple textures in play per side, or if it cannot find the model for the state it will likely be confused. As long as the block renders normally with just the standard state from the world and its a simple cube it should be fine.
I assume that this is not the case?
No. The glasses are a complex connected model and the "world state" is just a dummy that holds the smart model that computes the real quads by combining the json models from the other 26 (or so) blockstates as needed.
The obdisian has a complex json model, but it's just one model with no special states and just one texture.
I guess I'll have to find some time to look into it the code has worked pretty well so far, but I don't have much else to offer except for "it might be too complex" but you say its not.
And as for detecting transparency, I've never seen it fail at that, I don't know why it would be rendering glass as opaque.
It might be easiest if I could IMC you a texture for all sides, so you don't need to guess. And about the opaqueness, um, one variant is dark glass, but that shouldn't effect that. What are you calling to find out? Maybe it's failing on my side because some blockstate/world data is missing from the parameters? In that case, it'd be easy for me to change the "failure case answer"...
I'm actually a bit more concerned for the obsidian (honestly, why c&b a glass block that is 99% clear?). I may have a different texture rotation than expected because I made a complex model of one face and use it with rotations for all sides. Now, how to communicate that to c&b...
canRenderInLayer(state,layer) is used to determine what layer to render the faces in.
As for an IMC for textures, maybe if there is a reason, I'd prefer if the calculations worked, and based on what you said, theres no reason it shouldn't.
canRenderInLayer(), oh that explains that part. Our glass renders in layer SOLID because we only render the frame, so we don't need any transparency...
yeah, no reason not to go to CUTOUT. Combine that with a new texture that actually is blank in the center, and we have solved half of the problems. That leave the fact that the only texture that is picked up is SOUTH...
Yeah, it might be related to the issue with the obsidian as well, That part I'll have to look into.
Looking at the data as its based to C&B seems to indicate that the UV's at the corners reflect some unusual usage, it looks like some of the corners are using almost the same UV's either that or something else is confusing it greatly, threes a lot of faces involved and its hard to read the raw data.
However this is an example, each point is from a completely different face on the top of the model ( up facing )
X: 0 Z: 0 U: 0.9984379 V: 0.061813354
X: 1.0 Z: 0.0 U: 0.9984379 V: 0.061813354
X: 1.0 Z: 1.0 U: 0.9984379 V: 0.061813354
X: 0.0 Z: 1.0 U: 0.9984379 V: 0.061813354
Take note that every single U V matches, and each is a completely different corner, to me this sounds like the texture usage on the top of the Model is arbitrary, each face not reflecting its position on the model via the texture.
Yes, that's because each of the 12 edges and 8 corners is one submodel. There are 5 models (north_up, north_west_up, north_west, north_west_down, north_down), these are rotated around y to get all 20 variants edges and corners. Those edges and corners are then then combined in code depending on the connections to its neighbors. (You can see that better on the reservoir which uses the same code but has solid edges, not those L-shaped ones.)
So on the top and bottom you get the same one edge and one corner with the same piece of texture in 4 rotations.
(for reference: https://github.com/SleepyTrousers/EnderIO/blob/1.10/resources/assets/enderio/blockstates/blockFusedQuartz.json )
Well that explains the issue, it thinks that the entire top consists of a single pixel, thus the grey. This probobly requires some kind of override to get around, since the source model doesn't make much sense to C&B.
um, were you talking about the obsidian? I was talking about the glass, where all sides but the south one are empty.
But obsidian isn't that different. a side model rotated 4 times and 1 top/bottom model rotated into 2 positions. It's just much more static.