Jump to content

[1.8] Drawing enchantment glint over a regular quad


TheNuclearDuck

Recommended Posts

I've been able to draw the enchantment effect over a quad in 1.7.10, using the following method:

/** Bits which are modified while rendering item glints, so must be pushed/popped.
     * @see #drawTexturedGlintRect(int, int, int, int, int, int) */
    public static final int GL_GLINT_BITS =
            GL_ENABLE_BIT | GL_TEXTURE_BIT | GL_TRANSFORM_BIT |
            GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT | GL_CURRENT_BIT;

    /** Render an 'item glint' over the specified quad with the currently bound texture for clipping.
     * @param x X coordinate of the top-left
     * @param y Y coordinate of the top-left
     * @param u Texture X coordinate, in pixels
     * @param v Texture Y coordinate, in pixels
     * @param width The width of the quad to draw, in pixels
     * @param height The height of the quad to draw, in pixels
     * @see ItemRenderer#renderItem(net.minecraft.entity.EntityLivingBase, ItemStack, int, net.minecraftforge.client.IItemRenderer.ItemRenderType) */
    public void drawTexturedGlintRect(int x, int y, int u, int v, int width, int height) {
        mc.mcProfiler.startSection("glint");
        // Push bits we modify to restore later on
        glPushAttrib(GL_GLINT_BITS);

        glDepthFunc(GL_EQUAL);
        glDisable(GL_LIGHTING);
        glEnable(GL_BLEND);
        // Mapped OpenGL constants from [768, 1, 1, 0]
        OpenGlHelper.glBlendFunc(GL_SRC_COLOR, GL_ONE, GL_ONE, GL_ZERO);

        glColor4f(0.38F, 0.19F, 0.608F, 1.0F); // #61309B, light purple tint
        mc.getTextureManager().bindTexture(RES_ITEM_GLINT);

        glMatrixMode(GL_TEXTURE);

        long time = Minecraft.getSystemTime();

        // Rect #1
        glPushMatrix();
        glScalef(0.125F, 0.125F, 0.125F);
        glTranslatef((float) (time % 3000L) / 3000.0F * 8.0F, 0.0F, 0.0F);
        glRotatef(-50.0F, 0.0F, 0.0F, 1.0F);
        this.drawTexturedModalRect(x, y, u, v, width, height);
        glPopMatrix();

        // Rect #2
        glPushMatrix();
        glScalef(0.125F, 0.125F, 0.125F);
        glTranslatef((float) (time % 4873L) / 4873.0F * -8.0F, 0.0F, 0.0F);
        glRotatef(10.0F, 0.0F, 0.0F, 1.0F);
        this.drawTexturedModalRect(x, y, u, v, width, height);
        glPopMatrix();

        glPopAttrib();
        mc.mcProfiler.endSection();
    }

 

This works perfectly, if I run it after drawTexturedModalRect. It was ripped and slightly modified from vanilla's method for rendering over items, but since item rendering has changed a lot between 1.7.10 and 1.8 it no longer works. The new method of rendering items seems to be so complicated that I can't find any new method of doing this.

 

In 1.8, this code sort of works correctly, for the first quad I draw it over. Any further quads cause the texture to remain blank for most of the time, then very quickly the entire enchantment texture moves across the quad and disappears again for a second or two. Any ideas on how this same effect can be achieved in 1.8?

Link to comment
Share on other sites

In 1.8, this code sort of works correctly, for the first quad I draw it over. Any further quads cause the texture to remain blank for most of the time, then very quickly the entire enchantment texture moves across the quad and disappears again for a second or two. Any ideas on how this same effect can be achieved in 1.8?

Not directly a solution, but the error on the additional quads sounds like an undersized UV area. I've messed around previously with the Glint for a shield esque overlay and when its UV coords aren't displaced enough you get gaps akin to what you've described because it 'zooms' in on the textures.

I think its my java of the variables.

Link to comment
Share on other sites

In 1.8, this code sort of works correctly, for the first quad I draw it over. Any further quads cause the texture to remain blank for most of the time, then very quickly the entire enchantment texture moves across the quad and disappears again for a second or two. Any ideas on how this same effect can be achieved in 1.8?

Not directly a solution, but the error on the additional quads sounds like an undersized UV area. I've messed around previously with the Glint for a shield esque overlay and when its UV coords aren't displaced enough you get gaps akin to what you've described because it 'zooms' in on the textures.

Why would the UVs have changed at all between me rendering these two quads (the only thing inbetween is a regular quad, drawTexturedModalRect). I wouldn't thought it was some OpenGL state that's now changed in 1.8... Hmm. I wish I could say I had any ideas.

Link to comment
Share on other sites

I couldn't tell you with certainty, but if you're seeing the artifacts of the texture then it's likely a uv scaling/ timing issue... do you mind showing where/how you're invoking this?

GitHub. This is for 1.7.10, but none of the code has changed apart from things like replacing .addVertexWithUV from Tessellator to WorldRenderer.

Link to comment
Share on other sites

width=800 height=450Screenshot%202016-01-28%2008.37.52.png?d [/img]

Got this from snagging RenderItem.renderEffect(IBakedModel) and replacing model rendering with

Minecraft.getMinecraft().ingameGUI.drawTexturedModalRect(0,0,0,0,scaledWidth, scaledHeight);

and it worked fine as far as speed and such goes.... So comparing against this and looking at your code I *think* I see the culprit:

 

this.drawTexturedGlintRect(left + this.left, this.top, (int) uv.x, (int) uv.y, 5, 9);

your UV is set to a specific slot... try forcing it to use the full Glint texture instead of a portion of it.

I think its my java of the variables.

Link to comment
Share on other sites

FIXED! The solution wasn't exactly what you said, but your findings did cause me to look into a few things. First, I rendered the whole texture so I could see better, then I looked into RenderItem#renderEffect(). I found that some of my calculations were weirdly flipped (*8 instead of /8, for example). I think this was actually part of a previous attempt to fix the problem, someone suggested using the reciprocal. Either way, that caused the animation to work properly again (did have to mess around with the bound texture, though...)

 

Thank you RANKSHANK!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Try deliting feur builder  It caused this issue in my modpack
    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.