Zaerudath

I just updated from 1608 to 1635 and blocks with .OBJ models stopped rendering. Before, with 1608: After, with 1635: The block has a complex setup with extended state model variants but I didn't change anything else. JSON models (shown in the background) render fine. I back-leveled to 1608 and then re-updated to 1635 just to be sure. Error log is clean. The item uses the same model and renders OK in the tool bar, so it appears the model and textures are still being loaded correctly. I probably did something I shouldn't have that didn't cause a problem until now, but it isn't something obvious to me. I've gone through the forge change log and didn't see anything that looked like it would cause this. (And the test code for .OBJ models on github also hasn't changed as far as I could tell.) I noted in the changelog there were some enhancements to face culling, but I haven't looked at those changes yet. I'm going to take another pass at it now in more detail, but thought I'd check in here in case anyone else has already seen this. My (ugly) code is at https://github.com/grondag/Adversity, but it is a lot to wade through. I was about to do some refactoring after the update then this happened. edit: forgot to mark this solved.

Guessing your are on a Mac. If so, this is caused by an out of date library. See here for details: http://www.minecraftforge.net/forum/index.php/topic,28998.msg149318.html

I have been banging my head on model rotation for ISBMs the past couple and finally got it to work. Spend some time studying the TRSRDeserializer class and how it sets up transformations for rotations that it parses from a JSON files. Set up a JSON file with what you want and you can trace it through in the debugger if you like. The Forge V1 blockstate docs will also be useful: http://mcforge.readthedocs.org/en/latest/blockstates/forgeBlockstates/ https://gist.github.com/RainWarrior/0618131f51b8d37b80a6 Lastly (and this is the part it took me a while to track down) you'll probably need to call TRSRTransformation.blockCenterToCorner on your TRSRTransformation instance before you use it to bake your model. If you don't, you model will be rotated around the origin instead of the center of the block. See the ForgeBlockStateV1 class for examples of usage.

Yes, not just different textures but it appears Mojang created distinct blocks for each color. Was just browsing the vanilla blockstate folder and each color has its own blockstate file. It seems Mojang stopped using metadata for most or all colored blocks. I imagine they didn't use tint index to allow for more interesting and varied textures on colored blocks than could be had just by tinting a single base texture. But I do wonder why they stopped using metadata (now block states) altogether unless they just don't care about conserving block IDs any more. Also, I tested tint index to confirm that it does work irrespective of the lighting model. That is going to save me a lot of tedium in creating textures. I want some blocks to get progressively darker as they absorb damage from explosions, and I can just override colorMultiplier to be based on blockstate and let all the blockstate variants point to the same model. Thanks again.

Thanks Are you sure that Block.colorMultiplier only works with Ambient Occlusion enabled? I see this in renderModelStandardQuads(), which is used when AO is off: if (bakedquad.hasTintIndex()) { int i1 = blockIn.colorMultiplier(blockAccessIn, blockPosIn, bakedquad.getTintIndex()); -TGG I'm only sure of death and taxes. That does look promising. Will do some testing later this evening. Would be great if it works in the general case. You might know: I tried to track down how vanilla handles blocks like colored wool. I got as far as BlockColored last night before I ran out of time. That class doesn't override colorMultiplier, and the base class implementation returns a hard-coded 0xFFFFFF. Will keep looking if you don't know.

I thought the Explosion Events were added recently to Forge for 1.8. If that's accurate, it won't help for 1.7.10.

Aha! Found it. The tintindex in the block model file is indeed a boolean as jabelar suggested. Any value other than -1 will be interpreted as true. For it to do anything, you also have to override Block.colorMultiplier. It initially seemed to do what I wanted. I had hoped to use it to shade the block based on blockstate while using the same block model for each block state. Sadly, looking at BlockModelRenderer, it appears this won't actually work reliably because colorMultiplier is only applied if ambient occlusion is enabled. It also won't work if the block is a light source, though that doesn't apply in my situation. TheGreyGhost:. I had read that before but didn't make the connection. I read it again and it clicked this time. The material you have online is supremely useful, and much appreciated.

I would like to use it to shade some textures instead of creating 16 textures per block that are subtly different shades of the same texture. This, for example, seems to do nothing: { "textures": { "face": "oddities:blocks/unob_block_a", "particle": "blocks/stone" }, "elements": [ { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "texture": "#face", "cullface": "down", "tintindex": 255 }, "up": { "texture": "#face", "cullface": "up", "tintindex": 255 }, "north": { "texture": "#face", "cullface": "north", "tintindex": 255 }, "south": { "texture": "#face", "cullface": "south", "tintindex": 255 }, "west": { "texture": "#face", "cullface": "west", "tintindex": 255 }, "east": { "texture": "#face", "cullface": "east", "tintindex": 255 } } } ] } I've looked at the vanilla JSON files (they all have tintindex 0). Not much on the web. I've tried to trace it down in the vanilla code but it doesn't seem to be referenced directly. I started tracing through the various render-related classes and then thought to come here and ask. I know there are other ways to do it, but has anyone gotten tintindex to do their bidding? edit: added 1.8 tag