Jump to content

[SOLVED]transparent texture in Entities without ruining water render


WeAthFolD

Recommended Posts

I've been recently working on some special effects in my mod, so I started using transparent PNG textures in my entity rendering. But I noticed one(Rather annoying) flaw:

When the back of the entity are plain blocks, the rendering is perfectly OK. However, if the back of the entity are some water blocks, then part of water(To be exact, part which the texture's pixels are really drawn) are not being renderered at all, so I'm blending with whatever block that is beneath the water.

When testing with blended TileEntities, same error occurs.

I also noticed that the GL_ALPHA_TEST switch is enabled and some low-alpha pixels are being filtered. When I turn that switch off, the whole picture area I'm rendering ruins the water rendering.

With multiple entities in the world, sometimes the same problem occurs. It seems that the problem is highly dependent on the drawing order.

So, how can I fix that? Or it is a fixed problem of the MC render engine and we have to just stand it?(If it's the latter one I'll be really sad :()

BTW, all I did in my EntityRender class is equivalent to the following:

@Override
public void doRender(Entity ent, double x, double y, double z, float wtf, float isthis) {
GL11.glEnable(GL11.GL_BLEND);
GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);
GL11.glPushMatrix(); {
GL11.glTranslated(x, y, z);
//bind the texture
//render the model or whatever by calling tessellator
} GL11.glPopMatrix();
GL11.glDisable(GL11.GL_BLEND);
}

 

221759opm0k0j4kmddtxt7.jpg

A screenshot(When disabled GL_ALPHA_TEST)

The MC version is 172 and Forge version is 172 recommended.

 

Thanks for your time reading and answering!

 

EDIT: After looking up some informations, I found that this problem is hardly solveable because of limits on OpenGL rendering pipeline. Depth test is done regardless of pixel transparency, and alpha blending is done in later stages. To make it right you have to either not write Z value of current drawing (Which may cause this draw call to be improperly covered), or make depth sorting for all of the transparent stuff within the render scene(Which for current MC rendering routine, impossible). So currently maybe we can just stand this design flaw and use original alpha tests?

Link to comment
Share on other sites

A soft sell for mcbbs and 360, well done.

There are two pass in the rendering process of Minecraft. The first pass is used to render all non-transparent block, most entities and tileentity (in fact, all vanilla ents & tiles), and the second one is used to render transparent block, such as water.

Although I think that it is possible to play some "Z buffer tricks" to avoid this problem, you can just simply let your ents & tiles be rendered in the second pass. Just override the shouldRenderInPass method in your ent/tile class (not the renderer class. Don't confuse shouldRenderInPass and shouldRenderPass of RendererEntityLiving).

However, I'm not sure will it solve this problem. I can't reproduce it...

Link to comment
Share on other sites

You have to make sure your object is rendered after the water, if your object is closer than the water.  For water that works fine, but if you (say) look through ice at your object, it will look mighty strange.  Likewise if you look through one of your objects to see a second one of your objects

 

I don't think in 1.7.10 that this can be properly solved without a big effort.  In 1.8, transparent blocks are depth-sorted so it should work better!

 

-TGG

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

    • I'm using Modrinth as a launcher for a forge modpack on 1.20.1, and can't diagnose the issue on the crash log myself. Have tried repairing the Minecraft instillation as well as removing a few mods that have been problematic for me in the past to no avail. Crash log is below, if any further information is necessary let me know. Thank you! https://paste.ee/p/k6xnS
    • Hey folks. I am working on a custom "Mecha" entity (extended from LivingEntity) that the player builds up from blocks that should get modular stats depending on the used blocks. e.g. depending on what will be used for the legs, the entity will have a different jump strength. However, something unexpected is happening when trying to override a few of LivingEntity's functions and using my new own "Mecha" specific fields: instead of their actual instance-specific value, the default value is used (0f for a float, null for an object...) This is especially strange as when executing with the same entity from a point in the code specific to the mecha entity, the correct value is used. Here are some code snippets to better illustrate what I mean: /* The main Mecha class, cut down for brevity */ public class Mecha extends LivingEntity { protected float jumpMultiplier; //somewhere later during the code when spawning the entity, jumpMultiplier is set to something like 1.5f //changing the access to public didn't help @Override //Overridden from LivingEntity, this function is only used in the jumpFromGround() function, used in the aiStep() function, used in the LivingEntity tick() function protected float getJumpPower() { //something is wrong with this function //for some reason I can't correctly access the fields and methods from the instanciated entity when I am in one of those overridden protected functions. this is very annoying LogUtils.getLogger().info(String.valueOf(this.jumpMultiplier))) //will print 0f return this.jumpMultiplier * super.getJumpPower(); } //The code above does not operate properly. Written as is, the entity will not jump, and adding debug logs shows that when executing the code, the value of this.jumpMultiplier is 0f //in contrast, it will be the correct value when done here: @Override public void tick() { super.tick(); //inherited LivingEntity logic //Custom logic LogUtils.getLogger().info(String.valueOf(this.jumpMultiplier))) //will print 1.5f } } My actual code is slightly different, as the jumpMuliplier is stored in another object (so I am calling "this.legModule.getJumpPower()" instead of the float), but even using a simple float exactly like in the code above didn't help. When running my usual code, the object I try to use is found to be null instead, leading to a crash from a nullPointerException. Here is the stacktrace of said crash: The full code can be viewed here. I have found a workaround in the case of jump strength, but have already found the same problem for another parameter I want to do, and I do not understand why the code is behaving as such, and I would very much like to be able to override those methods as intended - they seemed to work just fine like that for vanilla mobs... Any clues as to what may be happening here?
    • Please delete post. Had not noticed the newest edition for 1.20.6 which resolves the issue.
    • https://paste.ee/p/GTgAV Here's my debug log, I'm on 1.18.2 with forge 40.2.4 and I just want to get it to work!! I cant find any mod names in the error part and I would like some help from the pros!! I have 203 mods at the moment.
  • Topics

×
×
  • Create New...

Important Information

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