V0idWa1k3r

No you didn't. You are still rendering your items at view origin and then translating the matrix. You are still not using generics for your TESR. And are still creating a new ItemStack x2 each frame. This is a segment of code that shows how you are doing it, not where and it certainly does not confirm that the TESR is even being registered. I am not really sure actually, I've never done that kind of a custom IBakedModel before. I assume that as with other custom IBakedModels you would need a custom ICustomModelLoader implementation with a custom IModel implementation that would allow you to have your custom IBakedModel to begin with. You would need to have 2 lists of quads in that model - 1 for your block and 1 for your item and in your getQuads implementation you would return a combination of those lists. While I can get the following to work in my test environment I am sure that there are more efficient ways to do this - (this part is written after my ~30 minute search )and I have found one on this very forum!

Your textureX/Y are of an integer type. So is 1. And so is 256. Dividing an integer 1 by an integer 256 prouces you 0 and well, anything *0 is 0. Why do people create abstractions to begin with? Let's all write our code in assembly! That is sure going to be fun! On a serious note - their BufferBuilder is very flexible - and that is why they did it. As long as you have the format you can easily upload anything you want to it and render it as desired without having to manualy setup GL buffers/arrays/attributes/younameit every time. Heck, you can even have custom formats defined and it will work just fine. Also it allows to easily modify the individual elements of the buffer if needed after they've been uploaded with a single method invocation. Doing it on a raw buffer is... A bit more challenging. And yet a lot of people had issues with MC starting to require OpenGL 3.3. I remember having one myself on a linux machine at work due to the way mesa drivers are done.

Well, look at the error message. It tells you exactly what is wrong. You should look into the entire fml_client_latest.log for more verbose output and figure out how to fix that. Do you know what generics are? Using them here will save you from a lot of redundant casts. As to the issue: Rendering an item with a block does not require a TESR and can be achieved with a custom IBakedModel. You are currently rendering at origin point(0,0,0). Well, view-space origin that is. Translate the matrix by x,y,z passed to you as parameters. Make sure that the item rendered does not end up inside a block where you can't see it before saying "it doesn't work either" It is probably not a good idea to create a new ItemStack object x2 each frame. Especially considering that they are identical by content. If you need to render a constant ItemStack like that have it in a constant field. You haven't shown how/where you are registering your TESR.

Position it in the middle of the screen then. It would be screenWidth/2 - yourWidth/2, screenHeight/2 - yourHeight/2. It is preferred because it is conventional. I mean in theory you can use java's ImageIO to load images from an InputStream, upload their pixel data to a buffer, setup a GLtexture and link the buffer to the texture every time you need a texture but you are not doing that, are you? Instead you use TextureManager::bindTexture. Same goes for BufferBuilder. And as I've said: As to how it worksL it basically has an internal buffer it fills with data you pass to it. The offsets, strides and elements/vertex are controlled by the VertexFormat specified. Once you invoke draw the buffer is passed to OpenGL and rendered. It is somewhat of a complex yet very flexible wrapper around GL 3.0+ rendering. If you are familiar with GL4.5 you should be familiar with this aswell. As a side bonus it allows for "modern" shaders to be used(and MC does that in some cases). Let's look at Gui::drawTexturedModalRect. Specifically at it signature: public void drawTexturedModalRect(int x, int y, int textureX, int textureY, int width, int height) The parameters I've marked as bold are to be processed into UVs in the method. textureX/Y are the start, and textureX/Y + width/height are the end. How are they processed? Well, let's look into that method. You will quickly notice that the results of manipulations with these values are multiplied by 0.00390625F. What is this magical number? It is 1/256. MC assumes the height/width of a GUI icon to be 256x256 and does calculations based on that assumption. If the texture is bigger in size(say via a resourcepack) it actually does not matter as the range of [0-1] is effectively a percentage and if the code is based around a 256x256 assumption(the variables passed to this method, that is) the end-result percentages are still going to be correct regardless of the texture width/height.

You already are. The NBTTagCompound you are writing to the file is the 'data' you are writing. As to the specifications Fill in the NBTTagCompound as you wish then. Do you know how NBT tags work? If you don't I suggest looking into vanilla classes that serialize/deserialize NBT, tileentities for example. It looks to me that you are writing some generic data into NBT. Is there a reason you are using NBT specifically?

Your file end-name will be storage.dat.dat as you add the extension in the constructor. Use the debugger to find out what's wrong. Put a breakpoint in your write method. I would say that if the file is not even being created then the issue most likely is within the fileLocation field so inspect it.

There are safeWrite and write methods that write the NBT without compression.

CompressedStreamTools, yes. A file can be anything you want, you can set anything as the "file name". All you need to do is write the NBT using methods from CompressedStreamTools into your FileOutputStream.

UVs must be within a range of [0-1] and you are passing a range of [0-16] x [0-51]. That won't work well. By default all MC textures have their wrap S/T set to repeat, and that's why you see "thousands of little textures" - it is actually your texture repeated 16 times on the x axis and 51 times on the y axis. Well, where are you expecting to see your quad? We can't tell what is wrong with the UI positioning just by looking at the code - although I can take a guess: you should subtract your position offsets after you've found the center of the screen. There is absolutely nothing stopping you from using static methods in the GUI class. Or copying the method for that matter. I still suggest using BufferBuilder/VertexBuffer rather than OpenGL directly. There is a reason MC switched to it entirely. And well, some people might assume that all drawing is indeed done using methods from that class and abuse that.

Don't create a new EntityItem each frame. Especially because you are using it only to re-route to the code that renders the ItemStack in pretty much the same way you've commented out. As you've said the lightmap coordinates are incorrect. Set them manually with OpenGlHelper.setLightmapTextureCoords. The first parameter is the texture unit(OpenGlHelper.lightmapTexUnit), second and third are your lightmap coordinates. Do not forget to reset them back to what they were after you are done - their current values are stored at OpenGlHelper.lastBrightnessX/Y

You need to potentially override TileEntity::getRenderBoundingBox and TileEntity::getMaxRenderDistanceSquared. The first method dictates whether to render your TE if it is's origin is not within camera's viewport, the second one dictates the distance to stop rendering your TE at. Mind the "squared" in the name of the method. By default it returns 4096 that translates to 64 blocks.

Well, you know that this feature exists in vanilla and you even named the object that has that feature. Why ask on how to do it when you can look how vanilla does that?

Lightmaps are not 3d. The first argument is a texture unit target to apply the coordinates to.

You can use Store the previous coordinates in locals(the current coordinates are stored in OpenGlHelper.lastBrightnessX and OpenGlHelper.lastBrightnessY), set the coordinates to whatever you want, render your thing and reset them back. The target parameter for OpenGlHelper.setLightmapTextureCoords would be OpenGlHelper.lightmapTexUnit

The ordering matters. If your format is POSITION_TEX_LMAP_COLOR then you must specify a position, a set of UVs, a lightmap and color in that order. Also as this format uses UVs you shouldn't disable the texture. You should also provide a set of UVs that makes sense, not fill it with zeroes. Additionally I believe that lightmap of 255 255 is actually pretty dark. I use 240 240 when I want full brightness. As you've pretty much got it done here is a code snippet that renders your quad: wr.pos(0, 0, 0).tex(0, 0).lightmap(240, 240).color(r, b, g, 255).endVertex(); wr.pos(1, 0, 0).tex(1, 0).lightmap(240, 240).color(r, b, g, 255).endVertex(); wr.pos(1, 1, 0).tex(1, 1).lightmap(240, 240).color(r, b, g, 255).endVertex(); wr.pos(0, 1, 0).tex(0, 1).lightmap(240, 240).color(r, b, g, 255).endVertex(); Note that it rendrs whatever texture was bound last, and it is a small face that only renders when you look at it from a specific side. This is most likely not what you want to achieve but it is a starting point, I suppose

Your format is POSITION_COLOR. It doesn't specify a lightmap.

Have you heard of gradients? How do you think they work? The color is a property of a vertex, aka a point. If you define a point with a red color and a point with a green color the color of the line drawn between those two points will be linearly interpolated. You put it after you define a vertex. When you call pos you define a position element of a vertex. When you call color you define another element of a vertex. wr.pos(0, 0, 0).color(100, 100, 100, 255).endVertex(); is a fully defined position + color vertex. You would either select a vertex format that uses lightmap as one of it's vertex elements or manualy set it with OpenGlHelper.setLightmapTextureCoords. If you use the later do not forget to reset it back. Additionally if your vertex format does not include UVs(texture) disable it before rendering(GlStateManager.disableTexture2D) and enable it after you are done.

color is a property of a vertex, you can't just put it into a buffer without any context and expect it to work. After defining a vertex you must end it's definition with VertexBuffer::endVertex. There is no point in applying color with GlStateManager as your vertex format already specifies a color. If you are changing states of GlStateManager - reset them after you are done. If you are disabling the lighting before drawing enable it after you are done. You have already translated everything by xyz with GlStateManager.translate. Putting xyz as origin in your vertices is going to translate them again, causing issues. If you want your rendering 'fullbright' disabling lighting is not going to be enough, you will need to specify lightmap coordinates. That is really up tou you. I do not think there are any tutorials out there that would describe how to render "a rift". You would want to play with rendering untill you achieve the effect you are after.

I'll repeat myself: 1. Override Item::getArmorTexture in your armor class and make it do the following: Check for a boolean value stored in the NBT of the ItemStack passed to the method as an argument. If it is true: return a texture that is completely transparent If it is false: return your normal armor texture. 2. In your wraithBell's onItemRightClick class modify that boolean value of armor's NBT if your conditions are correct.

Well, here is the cause of your NPE. The mc field is null as you've never assigned anything to it. Minecraft is a client-side only class. Using it like that will crash the server. Why on earth are you even using it to get the player when you have the player passed to you as an argument? Items are singletons. This means that changing this field will affect all items that are an instance of wraithBell. ItemStack is what you need to work with if you want to have some data that is unique to a specific... welll ItemStack. Please refrain from using logging to debug. The debugger and breakpoints exist for a reason. -> MobEffects.INVISIBILITY. Now all that out of the way: I assume you want the armor to become invisible with the player as they use your bell item, correct? Item::getArmorTexture has the ItemSteack of the armor as it's parameter - you can check for, say, a specific boolean being set to true in that stack's NBT and return a texture that is completely transparent.

Have your own counter field in your entity class and increment it each tick, then reset when needed. Move this field to your entity class, then access it from your model when needed. This is a basic OOP concept. As I've said models are singletons. Any change made to the model will affect rendering of all your entities which use that model.

Depends. The blockstates file fully controls the rendering of your model - you can apply your transformations there and they will be applied in the game just as any other item. I don't think that you can change the way a block renders in the world with blockstates. Maybe forge's animation system is capable of that - but I am no expert on it.

A mtl file is more than a texture pointer. It contains a "library" of materials(defines different materials for different model parts) and controls all properties of that material. While it is possible to use obj without mtl it is still required by forge to do model setups and baking. So no, you still need an mtl file. I have mine here.

Yes it is possible. You can define a texture for your material through a blockstates file just like you'd define a texture for a normal json model. I have an example of that here.

Block13.rotateAngleX = Math.toRadians((float)entityIn.ticksExisted / 2); Additionally models are singletons. If you change a value of a fieldin your model it will apply to all your entities. I am talking about this: