I've been working on a 3D graphing calculator, and have run into a couple undesirable rendering effects.

 

The first is that where the graph should be visible behind itself, only from one side is that the case, as shown below.

This seems like there's some GlStateManager setting involved, but I don't know what that would be. Currently, my settings are those of the FastTESR, so I can't change GlStateManager settings without also switching to a normal TESR. Or I could set up my own batching system with the proper settings. If there's a way around this problem without doing either of those things, though, that would be great.

The second is that the graph will not be rendered if its block is not within the frustum, or at least sometimes it won't. At first, it would never render if the player couldn't see the block, but having returned the infinite bounding box from TileEntity#getRenderBoundingBox(), it's improved a little. Now it seems that if I look a large enough angle away, the block stops being rendered, as opposed to looking even slightly away. This is shown below, with a stone block for reference.

 

If someone could help with either of these issues, that would be fantastic.

 

FastTESR:

Spoiler

package graphingcalculator3d.client;

import graphingcalculator3d.common.gameplay.tile.TileGCCartesian;
import net.minecraft.client.renderer.BufferBuilder;
import net.minecraft.util.math.Vec3d;
import net.minecraftforge.client.model.animation.FastTESR;

public class MeshRender extends FastTESR<TileGCCartesian>
{
	Vec3d[][] vArray;
	boolean[][] disconnects;
	
	@Override
	public void renderTileEntityFast(TileGCCartesian te, double x, double y, double z, float partialTicks,
			int destroyStage, float partial, BufferBuilder buffer)
	{
		if (te.isErrored())
			return;
		if (!te.renderReady)
			return;
		vArray = te.getVertexArray();
		if (vArray == null)
			return;
		disconnects = te.disconnects;
		if (disconnects == null)
			return;
		int[] rgba = new int[]
		{ 100, 100, 100, 100 };
		int lightmap = 220;
		
		for (int j = 0; j + 1 < vArray.length; j++)
		{
			for (int k = 0; k + 1 < vArray[j].length; k++)
			{
				if (disconnects[j][k])
					continue;
				buffer.pos(x + 0.5 + vArray[j][k].x, y + 0.5 + vArray[j][k].y, z + 0.5 + vArray[j][k].z)
						.color(rgba[0], rgba[1], rgba[2], rgba[3]).tex(0, 0.05).lightmap(lightmap, lightmap).endVertex();
				buffer.pos(x + 0.5 + vArray[j + 1][k].x, y + 0.5 + vArray[j + 1][k].y, z + 0.5 + vArray[j + 1][k].z)
						.color(rgba[0], rgba[1], rgba[2], rgba[3]).tex(0, 0.05).lightmap(lightmap, lightmap).endVertex();
				buffer.pos(x + 0.5 + vArray[j + 1][k + 1].x, y + 0.5 + vArray[j + 1][k + 1].y, z + 0.5 + vArray[j + 1][k + 1].z)
						.color(rgba[0], rgba[1], rgba[2], rgba[3]).tex(0, 0.05).lightmap(lightmap, lightmap).endVertex();
				buffer.pos(x + 0.5 + vArray[j][k + 1].x, y + 0.5 + vArray[j][k + 1].y, z + 0.5 + vArray[j][k + 1].z)
						.color(rgba[0], rgba[1], rgba[2], rgba[3]).tex(0, 0.05).lightmap(lightmap, lightmap).endVertex();
			}
		}
	}
}

 

Bounding Box code:

Spoiler

	@SideOnly(Side.CLIENT)
	@Override
	public AxisAlignedBB getRenderBoundingBox()
	{
		return INFINITE_EXTENT_AABB;
	}

 

 

Edited November 14, 20195 yr by SerpentDagger

As some additional information, the "translucent" graph also eclipses blocks like stained glass and ice, as well as portions of the graph that have higher opacity.

Neither of these glitches is too awful, but with the rest of the mod shaping up to be pretty neat, I'd really like for them to be resolved.

 

Perhaps no one knows the root of the transparency issue, but I don't think this happens with ice and glass, so there must be some way of doing it. Might anyone be able to point me towards the code that renders blocks like this? I've looked around myself, of course, but the rendering devolves into a gigantic sprawling maze of work, and it's difficult to pinpoint anything in particular.

 

As for the only-renders-when-you're-looking-at-it thing, I may be wrong in thinking it, but that seems like something that should be really easy to fix if I just know what to do about it. If no one knows the solution to that, is there an open source mod that has the same system? Surely I'm not the only one with the situation of rendering something bigger than a block with a FastTESR.

There's TileEntitySpecialRenderer#isGlobalRenderer method. Minecraft uses that for rendering beacons, maybe it could help you with your issue with the rendering outside frustrum

Fabulous! That was it, the frustum check is now properly ignored. Thanks a bunch. Having played around with it for a while now, that was definitely the major issue of the two, so having it fixed is a huge improvement.

After scouring the rendering code, I found that the problem was because the vertices weren't sorted in relation to the player's view, and that I could return true from TileEntity#shouldRenderInPass() during pass #1 instead of pass #0 to opt-in to the vertex sorting. The transparency now works perfectly.