Raytracing advice

[rich1051414]

I am currently working on a mod which requires me to check if a block is currently visible to a player. Grabbing a collection of blocks within this area is not a performance issue, however, checking if each block within it is visible or not is. This check is done on an area of 16x16x16 so it needs to be optimized. Is there a list that forge keeps, for rendering purposes, that I could use to speed this process up? If not, does anyone have an idea of a trick to make the check faster?

[Kokkie]

Call Block.shouldRenderSide(...) or something like that

[TheMasterGabriel]

What method did you try for checking if each block is within the player's view?

[rich1051414]

1 hour ago, TheMasterGabriel said:

What method did you try for checking if each block is within the player's view?

I raytraced from the block back to the player head, and then back to the players feet, to see if I ran into another block, manually. Seemed like the most direct way to the solution, but it is still expensive. I was hoping minecraft kept a list of non-skipped or skipped blocks, but it appears to only care if blocks are directly obstructed instead of not visible by foreground blocks not touching it. 
At the moment, I have simply delayed my lookup to twice a second to minimize performance impact, maybe I will think of something later.

Edited February 21, 2017 by rich1051414

[TheMasterGabriel]

When rendering the world, entities and basically everything, Minecraft uses a thing called a Frustum, which is basically just the camera. The Frustum helps the game determine whether or not it should bother rendering stuff because it can, given an AABB or set of coords, determine if they are within the render scope of the viewing entity (player in most cases). TileEntities use this to check whether or not they should be rendered. You may be able to use it to your advantage if you need to check if a certain block is visible to the player. I haven't really played around with Frustums and the render engine much, but try something like this where you are calling your code (and if I'm wrong hopefully someone with more experience can correct me, or destroy me, both tend to happen from time to time):

 

- Create a new instance of Frustum

- Set its position to the position of the player (see lines 1268-1273 of net.minecraft.client.renderer.EntityRenderer)

- Check if your block visible with this method inside Frustum:

public boolean isBoundingBoxInFrustum(AxisAlignedBB p_78546_1_)

where the passed parameter is the offset AABB of the specific block you are looking for. I think for your case you can construct one via:

public AxisAlignedBB(BlockPos pos)

 

This does require you to know the BlockPos of your block when determining if it is within view of the player, but it looks like you already know that seeing you tried your ray trace method.

Of course, this entire method is speculation on my part. I'm not sure how the performance differs, or if this is even a remotely good way of doing this.

 

EDIT:

Never mind, I just tested it and I don't think it works. It only seems to care if the player is not directly looking at it, ignoring blocks placed between it and the player. Your ray trace method might be the best option after all. Looking at how vanilla mobs determine if entities are within their view, it looks like they raytrace as well. See World.rayTraceBlocks:

public RayTraceResult rayTraceBlocks(Vec3d vec31, Vec3d vec32, boolean stopOnLiquid, boolean ignoreBlockWithoutBoundingBox, boolean returnLastUncollidableBlock)

 

SECOND EDIT:

Also for reliability, you might have to take into account the player's FOV, which is client-side. Not sure if rayTraceBlocks takes that into account, but I doubt it.

 

Also, you might be able to adapt qCraft's block observation code, which you can see here. I think it uses ray tracing as well, however.

Edited February 21, 2017 by TheMasterGabriel
I'm dumb