Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[1.15.2] Rendering transparent texture problem


Yanny7
 Share

Recommended Posts

Hi I have problem with rendering transparent texture - I am using water texture, but it renders almost black. Any ideas how to do it right?

 

matrixStack.push();

RenderSystem.enableBlend();
RenderSystem.color4f(1.0F, 1.0F, 1.0F, 1.0f);
RenderSystem.defaultBlendFunc();
RenderSystem.disableTexture();

IVertexBuilder vertexBuilder = renderTypeBuffer.getBuffer(RenderType.entityTranslucentCull(WATER));
MatrixStack.Entry matrix = matrixStack.getLast();
Matrix4f matrix4f = matrix.getPositionMatrix();
Matrix3f matrix3f = matrix.getNormalMatrix();

func_229132_a_(tileEntityIn, vertexBuilder, matrix4f, matrix3f, 0, v, 1, 0, off + 1/32f, overlayUV, lightmapUV);
func_229132_a_(tileEntityIn, vertexBuilder, matrix4f, matrix3f, 1, v, 1, 1, off + 1/32f, overlayUV, lightmapUV);
func_229132_a_(tileEntityIn, vertexBuilder, matrix4f, matrix3f, 1, v, 0, 1, off, overlayUV, lightmapUV);
func_229132_a_(tileEntityIn, vertexBuilder, matrix4f, matrix3f, 0, v, 0, 0, off, overlayUV, lightmapUV);

matrixStack.pop();

private static void func_229132_a_(TileEntity tileEntity, IVertexBuilder vertexBuilder, Matrix4f matrix4f, Matrix3f matrix3f,
                                   float x, float y, float z, float u, float v, int overlayUV, int lightmapUV) {
    int color = Objects.requireNonNull(tileEntity.getWorld()).getBiome(tileEntity.getPos()).getWaterColor();
    float r = (color & 0xff0000) >> 16;
    float g = (color & 0xff00) >> 8;
    float b = (color & 0xff);
    vertexBuilder.pos(matrix4f, x, y, z).color(r / 16f, g / 16f, b / 16f, 1.0f)
            .tex(u, v).overlay(overlayUV).lightmap(lightmapUV).normal(matrix3f, 0.0F, 1.0F, 0.0F).endVertex();
}
Edited by Yanny7
Link to comment
Share on other sites

Update your mappings and post your full code please

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

404. Is your repo public?

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

Link to comment
Share on other sites

Pretty sure this is where it is going wrong:

IVertexBuilder vertexBuilder = renderTypeBuffer.getBuffer(RenderType.entityTranslucentCull(WATER));

This will return an ITEM style vertex buffer. But then when you add your vertex:

 

vertexBuilder.pos(matrix4f, x, y, z).color(r / 16f, g / 16f, b / 16f, 1.0f)
            .tex(u, v).overlay(overlayUV).lightmap(lightmapUV).normal(matrix3f, 0.0F, 1.0F, 0.0F).endVertex();

This is in BLOCK style. The difference is at the end, ITEM style doesn't have .overlay() element. So you are then pushing extra bytes to the buffer which is moving everything along meaning you are writing the value of your lightmapUV over where it is expecting the normal values. And this is messing up the lighting calculations. These functions just push directly to a byte buffer in the background so their order and what is used is important.

 

How to fix: 

Best option is probably to call vertexBuilder.vertex(...) and this will sort out what bits need to go where in the buffer depending on the buffer type. 

Otherwise if you are always going to render to an ITEM buffer, just remove the .overlay(overlayUV) section.

 

 

A few other comments:

 

Don't do this in the function to build your vertex:

int color = Objects.requireNonNull(tileEntity.getWorld()).getBiome(tileEntity.getPos()).getWaterColor();

Do it somewhere before, and pass it along. Vertex functions should be very fast, as they tend to get called thousands of times every frame. And this function is doing a lot of lookups in the background to get the same value every time. (And I am assuming this is actually a copy of a minecraft function, but they are often written quite badly)

 

This stuff is likely doing nothing:

RenderSystem.enableBlend();
RenderSystem.color4f(1.0F, 1.0F, 1.0F, 1.0f);
RenderSystem.defaultBlendFunc();
RenderSystem.disableTexture();

I can't totally tell the context you are in, but the way that minecraft renders the GUI and world are slightly different.

 

If you are rendering something in the world, it works like this:

Stage 1: Minecraft will call all the objects to build one (or groups of) giant vertex buffers (Minecraft uses QUADS as the render type, so it doesn't need an index and vertex buffer like most 3D stuff).

- It is actually groups of vertex buffers, so you have your normal types "solid", "cutout", "translucent", you can find them all on the RenderType object.

- IRenderTypeBuffer is often passed to render functions, this is the object that contains all these giant buffers. When you call: .getBuffer(RenderType.translucent()); You are just gaining access to the giant buffer of that type. 

- You then add your vertices to the end of the buffer, and this gets passed along to all the other objects that will do the same.

- Each of these buffers have different setups for the pre and post calls to OpenGL, as well as vertex formats. So be careful with the order that is used when creating your vertex, in the builder (It depends on the sort of buffer you are using).. You can just call the .vertex() function on the builder and it puts them in the correct order for you.

 

Stage 2: Rendering

- After collecting all the vertices from the objects, the .finish() function is called which does the actual rendering. (Put a breakpoint in your render function and look at the call stack).

- Each buffer type has an "enter" and "exit" function that is declared (can't remember exactly where). 

- The process is simple: Call the "enter" function which sets up the GL options, blend, alpha etc.  Push the vertex buffer to graphics card. Call the exit function, which resets all the GL options used.

- This works because Minecraft only uses one texture. But it does have some drawbacks: because they just use one buffer you need to transform vertices on the CPU before adding them to the buffer, this is why MatrixStack is passed around everywhere (But as they are such low poly models this probably isn't much of an issue).  Also, they use QUADS, with quads the OpenGL driver has to convert them to triangles before pushing them to the card, so this will be happening every frame. However, again such low poly models that it probably doesn't really matter.

 

So hopefully you can see, that when you call "RenderSystem" methods you are just setting the OpenGL options directly, which will then get overridden during the later render phase, and might not get turned off for the rending of other buffers.

 

Worth noting that the GUI render is slightly different, here you can actually do direct drawing, using a Tessellator object and its .finish() call. And in that situation you do need to use "RenderSystem" to setup your options. This is because GUI's need to use a lot more textures, every dialog is typically it's own texture.

 

  • Like 1
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.

Guest
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.

 Share



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • Thanks everybody! I managed to fix it. I just had some missing attributes in my OilFluid class
    • W10 Pro. Android 11 on my S20+(or is it 12 already?). My two other computers are running on W10 home, all behind G-Data security suite, and a Fritz. I'm supposed to use Linux, no? I hate making things compatible, and Linux has limited access to some games I love, so...Mac is even worth I guess? I'm buying servers btw. It's not I couldn't set one up for Linux, but I lack the skills in online security, and I'm paranoid. So not a good combo I guess?
    • Yeah, the whole registry process can be quite confusing and daunting for how MC is working nowadays, but once you get the grasp of it, it actually saves a whole lot of effort, and quantity of code. I'd spend 3 days+ to actually figure I had to apply the getter(.get())[<-- is this even named getter?], to any of the .class references, because stupid Eclipse refused to de-obfuscate the source of problems. It was just making stupid a** auto fix suggestions, that didn't help at all. Google found the answer quite often though. And don't even get me started when I was trying to implement the Oil to world generation. I was literally tearing my hair out for days. But don't give up. We're not the only ones dealing with the reinvention of MC code wheel. I mean I get it. There's always room for improvements. But a wheel is just a wheel, right?
    • Thank you everybody, I have figured out the cause. I was accidentally passing in the constructor for the Fluids instead of the RegistryObject. I changed: super(new ForgeFlowingFluid.Properties( OilFluid.Source::new, OilFluid.Flowing::new, to: super(new ForgeFlowingFluid.Properties( ModFluids.OIL, ModFluids.FLOWING_OIL, And now the fluid actually works! But it doesn't spread though, I think I'd be able to figured it out from now. Thanks a lot Luis_ST and Cratthorax!
    • Because I was used to doing it like that in the past. Also, a block is very sparse in code quantity. Also, also, I would use the blocks to check against blocks of same type at lower levels, to mark as an indicator to what can be found digging deeper into the ground. Doing that with anything but the same object type is just unnecessarily bloating code. However, I had to use creative ways to get something working. What I did was rendering my block and its voxel shape invisible, make it nonsolid and notBlockMovement, then apply the randomTick() method, and using this: worldIn.destroyBlock(pos, true);...which basically drops the item after the blocks gets randomly destroyed. The good thing about that is, with the new DataPack function, I can do all that stuff with a single block object, and then just use instances of other block registers and their properties. I can also customize the loot tables for any of them, but don't need an actual block.class for any of them. Given how I have more then 60 ore blocks in my old mod, that is a really great thing about newer MC versions. The final solution was actually found in vanilla Block.AIR, after messing around with various methods, none of them doing what was easily done in the past MC versions with onBlockAdded(), and dropBlockAsItem(). I'll just leave the block code, and register code here for reference, which should give you a picture of the many things I was trying without success:
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.