Chunks do not render behind the player in F5. Perhaps culling should calculate from camera POV instead of presuming head position.

This effect can also be caused by sleeping in a bed. I created a separate ticket for it here - MC-63185 - because they are separate issues but likely with the same cause.

Beaten to the punch again. I can confirm

I can also confirm!

Confirmed.

Under request of Dinnerbone, this issue has been separated. MC-63020 will be used to track the render issue in first person, while this issue will be used to track the render issue with F5.

Confirming as fixed in 14w30c.

This is sorta happening in 14w32b again...

Reopened from comment here and MC-66895

I am putting tons of comments, observations and screenshots into MC-63020 for a reproducible example of overculling that sounds like what is being described here, which is viewable both in first person (normal, and even tighter FOV's) and in third person views.

It sounds as though MC-63020's goal is "make sure culling works per a single viewpoint and defined FOV" while the goal of this ticket is "make sure the single viewpoint discussed in MC-63020 moves out of your head appropriately in third person mode".

I also notice that culling is not recalculated when you press F5 to move that viewpoint, until you also move the mouse (and relative angle-of-view with it) which is a bug or part of a bug in it's own right.

1.8pre-1 confirmd

Relates to MC-63025

confirmed pre3

Confirmed in the release. (1.8)

Cannot reproduce.

There is however a bug with the occlusion that is not really trivial to fix.

This ticket might need to be merged with that.

Perhaps you are misunderstanding the bug? It is different from the original purpose of this report. The bug is that, after pressing F5, the calculation for which chunks should be rendered does not happen until the mouse is moved.
Steps to reproduce:
1. Look into the distance and stop moving the mouse
2. Press F5
3. Move the mouse and notice that the chunks suddenly render

Affects 1.8.1-pre1.

edit: Also affects changing the Field of View.

@redstonehelper, does this mean you have found an instance where the following occurs?

1. find a well chosen position to stand at

2. do something to change your FOV that involves not moving the mouse

3. Directly view culling errors as a result (eg, chunks not viewable due to new FOV)

and then the all important step 4:

4. upon moving the mouse, the culling errors go away, or chunks begin to be visible again .. respecting the new FOV.

I have never encountered this described test situation so I would love to see an example.

In my analyses so far with this bug up to 1.8 release, part of the base problem (both here and MC-63020) is that the culling algorithm absolutely ignores any offset of the camera position to outside of the player's head, and any changes to FOV under any circumstances. The culling algo does appear to respect direction that the camera faces, though often that consideration is only updated after a mouse move.

Lemme know if you can offer a way to repro this claim red, this is a bug I love digging at and learning more about. <3

• - Happ

Are we talking about the same bug here? I find it to be very easy to reproduce: http://gfycat.com/UnfortunateMisguidedAustraliankelpie

@redstonehelper Thank you sir, that did answer my question. :3

Affects 1.8.1-pre2.

edit: System details from a forced crash report:

-- System Details --
Details:
	Minecraft Version: 1.8.1-pre2
	Operating System: Mac OS X (x86_64) version 10.6.8
	Java Version: 1.6.0_65, Apple Inc.
	Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Apple Inc.
	Memory: 104811960 bytes (99 MB) / 285286400 bytes (272 MB) up to 1060372480 bytes (1011 MB)
	JVM Flags: 5 total; -Xmx1G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M
	IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
	Launched Version: 1.8.1-pre2
	LWJGL: 2.9.2
	OpenGL: ATI Radeon HD 4850 OpenGL Engine GL version 2.1 ATI-1.6.36, ATI Technologies Inc.
	GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because ARB_framebuffer_object is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.

	Using VBOs: No
	Is Modded: Probably not. Jar signature remains and client brand is untouched.
	Type: Client (map_client.txt)
	Resource Packs: []
	Current Language: English (US)
	Profiler Position: N/A (disabled)

Still happening in 1.8

Added a screenshot for it happening in 1.8.1pre2 (specifically the "look behind you without hitting the mouse" part of the bug).

Still in 1.8.1-pre3.

Found it!

Stupid bug! DEAD NOW!~

It's behaving!

Still not fixed. http://prntscr.com/53r96s http://prntscr.com/53r9ff http://prntscr.com/53r9z9

N, your issue is MC-63020

Scratch that. Can still reproduce in 1.8.1-pre4

You sure? Check my third screenshot

Fully reproducible in 1.8.1-pre4.

Please add a way to reproduce. World seed + exact tp locations (including angles) where it is reproducable all the time.

@Grum: as of 1.8.1-pre4 AFAICT the reproducibility of this bug is still 100% identical to that of MC-63020, so I'll repeat the test case I posted on that ticket to here.

Here is a world save (superflat with a simple mineshaft dug in it to find amenable coordinates): https://docs.google.com/file/d/0B57wgZSp2XofSXc4V1BLc1c5aU0

When you load that, player will be at exactly the correct position and rotation to reproduce bug MC-63020. To instead reproduce this one (MC-63070) you need only press F5 without touching the mouse.

In behind-the-head view, incorrect culling happens precisely as it does in MC-63020, as game's culling math assumes camera is still inside players head instead of translated to a point behind it.

If you go into selfie-view while being careful not to touch the mouse, then the culling math still does not yet change. Whatever chunks MC-63020 left missing, are still missing. but, as soon as you touch the mouse in any way, that is when culling algo decides to notice that the view has somehow updated and all the chunks behind you snap back into place.

It sounds like the initial culling issue in MC-63020 may be challenging for you to fix, but at least registering F5 as an update on the same level as a mousemove would cover what we are reporting in MC-63070. shrugs

Good luck sir,

• - Happ

@Happ MacDonald

selfie-view

^really

It is a view which offers absolutely zero utility not already covered by third-person view aside from insinuating the avatar's personal portraiture into the scene.

This view has zero uses aside from taking selfies.

Selfie-view.

http://i.imgur.com/dE352bg.gif

Was fixed in 1.8.1-pre4 but came back in pre5 D:

happens in 1.8.1 (release)

confirmed 1.8.2-pre1

^{I think my comment was removed due to a rollback.}
Anyway, after testing once more, I can say that it is fixed (at least for me) in 1.8.2-pre6, possibly earlier.

I got an email with your first comment too, it read:

> Happ, the only two reasons as to why you think it can still be reproduced is 1, your Java is outdated, and 2, your graphics card dates back to 2009.
> I, on the other hand, am running Java 1.8.0_31, and my graphics drivers have been updated to Catalyst 14.12.

This ticket does require some clarification.

The issue I initially discovered where view does not recalculate direction when F5 is pressed to transition from "behind the head" to "selfie" mode I can confirm has been resolved. I kind of forgot that was one of the ingredients too, lol. ;3

However direction is only part of the issue driving MC-63070 and differentiating it from it's brother MC-63020.

Still in the line of fire is that culling calculations are performed from the player's head coordinates instead of the camera coordinates. That leaves MC-63020 with the business of overculling even at those coordinates, and kind of makes the bug MC-63020 an easy way to test if MC-63070 is fixed or not (and vice versa, as it happens).

Here are some screenshots continuing to demonstrate the behavior in 1.8.6-pre6, with Java 1.8.0_31 64 bit, on a completely different computer with a newer video card (GTX 650 Titanium). First is in behind the head view, second in selfie view. http://imgur.com/a/Kbneq

Now if you were to march your character's face over to the corner of the cave where I've placed the camera in these shots, then all of the chunks would be visible just fine. In fact, here is a screenshot of just that, too: http://i.imgur.com/R7L3SBf.png

Sonic, if you think this isn't reproducing for you, I would appreciate it if you could try out my testcase here, and possibly get some screenshots: https://docs.google.com/file/d/0B57wgZSp2XofSXc4V1BLc1c5aU0

Load that world as singleplayer, and don't let the crosshairs move or move your feet as it finishes loading in. If you can see the sky near the right side of your screen, then you are already reproducing MC-63020.

Now turn around with your mouse but don't move your feet, so that you can get a good look at the small hallway you are in. Face your character squarely toward the end of the hallway you are in (as though your character were in time-out, or something. Bad Steve! lol) and then press F5. If it appears as though your 1x1x2 end of the hallway is floating in the sky, then you have successfully reproduced MC-63070. If not, then at least try moving the mouse about until you are certain the camera is at the opposite end of the hallway from you, similar to my screenshots.

As of 1.8.6_pre6, I confirm that carefully not moving the mouse as you press F5 brings you to a selfie-view where you now can see the hallway behind your face, this means that the game re-calculates the direction of view on keypress, but location of view is still borked because if you turn 180 without moving your feet you'll see that chunk disappear once more while your face smiles to the camera as though it's proud to be floating in the sky instead of it's physical location which is underground. 😛

If you do move your feet, you'll find the MC-63070 bits easy to reproduce again by just making certain that the center of your character is in the 1x1 square meter at the end of the hallway (Block -9 83 16) while your camera is at (or near) the other end of the hallway. The MC-63020 bits can be a lot pickier based on how close to the edge of the square you stand combined with exact angle your head is tilted, because only at the extremes do overculled chunks actually intersect your field of view.

So lemme know what you find, thanks for your input Sonic but I am definitely still repro'ing this for 1.8.2_pre6. :3

EDIT: fixed name of version: it's not "1.8.6_pre6" 😛

Seems fixed for me in 1.8.2-pre6.

Ymus have you tried my test case mentioned in last comment? I'd love to see a screenshot of it working, basically for anyone. I believe this is a game logic issue and thus should be pretty hard not to reproduce when the steps are followed. 😉

Seems fixed for me in 1.8.3.

Problem persists in 1.8.3.

Sonic, are you trying my test case world as I've recommended?

Yes.

Also, what's the operating system that you use? 64 or 32 bit? Just wondering.

All of my test platforms run Windows 7 64 bit.

Can we get a screenshot of you in my testcase world, facing camera, camera positioned at far end of hallway like I did? I am basically convinced that it is impossible for Minecraft to render this scene any differently — regardless of OS or Java version or any niggling low level considerations — due to the raw game logic culling from the perspective of the player's head even though the camera is physically elsewhere in space.

If you could demonstrate with a screenshot that the same scene gives you different results then that should add volumes to what we know about this bug.

Thanks for your help, Sonic! :3

OK. I'll get to that later. I just have to run some errands.

BTW, make sure that your graphics driver is updated to the latest version: http://support.amd.com/en-us/download/desktop?os=Windows+7+-+64

Ok, Happ.

I've managed to reproduce MC-63070 and MC-63020.

MC-63070 confirmed 15w31a

Confirmed for 15w31a.

How I can reproduce the bug (example):
1. Change your FOV settings while logged in a world. (From Normal to 30, for example)
2. Close the menu (go back to the game)
3. Open the menu again, then change back your FOV (E.g: to Normal)

When you go back to the game, the chunks render again if you move your mouse...

Confirmed 15w40b

Be advised, the variant of this bug that I am primarily reporting on because it's the easiest for me to reproduce (EG: the third-person variant of MC-63020) may not stem from precisely the same cause that the variant Dobypeti is reporting on. :3

Confirmed for 15w43c when changing FOV as Dobypeti said. Only chunks which aren't visible in the changed FOV (30) are not initially rendered. But: don't forget to move your mouse after changing the FOV to 30, or else the chunks will still stay rendered.

Confirmed for 15w44a

Mods: may I be set to reporter on this ticket so that I can keep affected versions up2date? 🙂

@unknown: The original reporter is still active - we can do it if they agree.

@@unknown: What do you think?

@redstonehelper I don't know if @Mateusz Niedrowski is still active here, no comments since initial report.

Confirmed 15w44b

Fair enough, considering ticket abandoned. You're the reporter now.

Confirmed for 15w45a

@unknown I completely forgot about this report, but as long as it's working towards solving the issue I don't have any problems with that.

Thank you 🙂

Confirmed for 15w47a and 15w47c

Seems to be fixed in 1.9-pre2, can somebody confirm this?

Perhaps one variant of the chunk not rendering has been fixed, but the variant I have been testing has not.

Check back to this comment for my testcase: https://bugs.mojang.com/browse/MC-63070?focusedCommentId=208071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208071

Sorry, just to be clear half of what was described in that testcase has been fixed. It used to be that culling math did not update until you moved the mouse. They fixed that bit.

The bit that still remains to be fixed in MC-63070 in particular is that any "outside of head" view still culls from the perspective of the head, instead of culling from the perspective of the camera.

That leaves sibling MC-63020 with the unique position of "wherever the culling is calculated from, it is possible, and easier with wider field of view, for some of the chunks you should normally be able to see to be culled". Folks have shown several examples above, most of which I cannot make easily reproducible, but the example I can make reproducible is listed above. Stand in a closed-in space right at the edge of the chunk the space is in, tilt head as close to 45 degrees horizontally as you can, and you can see around corners into culled areas.

Please update the description so it is up to date for 1.9-pre2.

Here we go, let us know if this description sounds better? :3

Reminder of why this ancient bug is important to try to fix.

Primarily, it can be used to cheat. Sort of a poor-person's X-ray mod to peek into hidden caves and dungeons or to spy on other players from a hidden vantage point. Also it ruins my ability to take certain kinds of screenshots.

Also/also, it ruins YOUR ability, as a game developer to do very many different kinds of cinematic elements.

Suggestion: if it is (potentially) too computationally expensive to re-calculate culling from a flighty, mouse-driven camera location then alternately consider calculating culling from the entire sphere representing the potential positions of the camera? that won't have to recalculate unless/until the player moves either, and by roughly the same delta.

Plus, you could have a fix for most of MC-63020 if you swap out point eye position for a ~1m^3 sphere around eye position for free. 😃

Mojang should make it so chunks will render everytime we press F5

Opening the world safe in https://docs.google.com/file/d/0B57wgZSp2XofSXc4V1BLc1c5aU0 crashes the game in the newest version...

I could report the crash but that should happen automatically right @mods?