Jump to content

[1.15.2] Rendering transparent texture problem


Yanny7

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

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

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