Adam Reece
Assigned
Reported
Comments
This issue is actually more complicated in that it really applies to ANY sound produced in Minecraft. This is because all the sound you hear is radius based, meaning no matter what is between you and the origin of the sound (be it air or 3 metre thick iron) you will hear the sound exactly the same because you're in the correct radius. It's only more noticeable for thunder because of the high radius it has. This same issue could also apply to for example hearing hostile mobs in caves very clearly, even though there could be a metre or two of solid rock between you both. There is no form of attenuation other than distance amplitude loss.
While reducing the radius could fix this I don't believe this would be a ideal. Partly because thunder is ruddy loud and can be heard for miles in our reality (so if anything the radius should be increased), but also because if I'm at Y10 (or lower) I should be able to hear thunder if there is a clear shaft to the sky where the sound would easily reach me without obstructions.
Sound audibility should ideally be dependant on what lies between you and the origin of the sound rather than radius and amplitude alone. I've noticed some modern games, particularly those using FMOD (which Minecraft does not), do account for obstructions when calculating sound attenuation pretty well. Perhaps a feature for a future major release.
Edit: What could also go really well with such a major sound update is distance based delay. For example, sound travels at ~343 metres/second. If a lightning strike is 343 metres away then you should see the visual effect immediately but not hear it for a whole second. Probably not that difficult to calculate this in Minecraft considering each cube seems to be roughly 1 cubic metre anyway. (FYI this is a little tip on knowing how far away a storm could be IRL.) Minecraft of course was never designed with realistic physics in mind. 🙂
I think it was a mod doing it (Optifine), or perhaps all the version switching I do. Just started up and it's on my desired +50%.
Ah I forgot about the brightness setting. For some reason mine keeps putting itself on +100% (even though I don't want it there).
Added 5 screenshots in snapshot 14w30c. I've only tested this on single-player, but as for a long time now single-player uses the same code base and such as multi-player (of which the issue originated at including crossing over to single-player later), this should be sufficient.
The first two show a visual scene difference between just rain and a thunderstorm. The main point is the sky scene DOES correctly switch to thunderstorm, of which is the primary way to recognize a thunderstorm against just some rain. Though the land scene doesn't appear to get much darker, it does just a little.
The next three show a technical representation of the ambient light level through all 3 weather conditions, up to light level 15. These clearly show the light level correctly drop from 15 to 12 and 10 for just rain and a thunderstorm respectively. These are also taken at exactly noon.
In my opinion a slightly lower light level (perhaps 8) would be more suited to the wide difference visible in the sky. The land doesn't really appear to get as dark as the sky, which doesn't look brilliant (the land glowing a bit?). However from an issue perspective, this is resolved.
I guess this can be marked as resolved then. 🙂
With that many entities there is a good chance your CPU is too busy to give enough attention to the code that delivers stuff to the GPU, which would mean your GPU is idle whilst waiting for this data to arrive. Remember that all those entities have to be processed with physics, A.I., and stuff like that ... every frame. This will ramp up the CPU time consumption, particularly as it's all run on one thread.
I'd definitely try again with none or nearly no entities to confirm (or de-confirm) this is a rendering bug. I'd suspect it isn't though. You could use something like SysInternals Process Explorer to monitor the consumption of CPU and GPU time to further verify this. (providing you're running Windows)
Oh, and update your Java 😉 Apparently 1.8 isn't supported, but certainly get the latest build of Java 1.7.
Did you try in 14w30c? A bunch of the new rendering glitches got repaired.
Confirming as fixed in 14w30c.
That happens because you're in very shallow water, and is intended. Try again in something deeper.
Added two screenshots of my view at the bottom of a deep ocean, one with night vision.
Bad issue description, not enough detail. Please include your GPU brand, model, and drivers.
Also worth updating your very out of date Java 1.7_25. Version 1.8_11 is out now.
That just looks like chunks haven't finished being created in a brand new world. Give it a minute and it'll be fine. (your lack of description doesn't help us know if this world is new or not)
I use FOV 80, probably why I saw it happen pretty frequently then.
Java 1.7 has been very healthy with Minecraft for some time now. I seem to remember reading support for Java 1.6 has pretty much finished here, so definitely update to 1.8_11 (or whatever the current build is).
I get this too.
Oddly I had a rather annoying chat with AMD about bad performance with OpenGL games, especially Minecraft. Their support team blamed the games for their bad and unoptimized code, though my much older (and slower) nVidia based GPU rendered Minecraft around 10x faster! AMD even said I had to update OpenGL myself...
Now that snapshot 14w30b is making use of vertex buffer objects and a more modern version of OpenGL this would highly suggest AMD have something significantly wrong with their OpenGL implementation in their drivers.
Old GPU: Gigabyte GeForce GTX 560 Ti overclocked edition
New GPU: Sapphire AMD Vapor-X R9 280X overclocked edition
I still have the email chain available.
@Bob: I see you're running Java 1.6 there. It's very advisable you upgrade to 1.8 (or 1.7) as there were some useful graphics performance improvements in Java 1.7. Would also be worth you dropping your chunk distance to 16 and try with VBO both on/off. Your GeForce 9800 GTX+ is also 6 years old now and even pre-dates Minecraft, so I wouldn't expect very grand frame rates from that. I didn't experience very grand frame rates with GeForce 8800 GT – even with two of them in SLI.
I would say this issue may still be valid as it happens on my much more modern GPU (less than 1 year old), should I post a fresh issue on that?
Same, though mine happen just by the angle I'm looking – if I rotate usually slightly it's a gamble as to whether chunks draw or not.
I've not been able to reproduce this on 1.7.9. I've definitely had it on previous 1.7.x versions though.
I agree but apparently this works as intended.
I can't say how thunder would sound underground as I've never been deep underground while a thunderstorm is roaring on the surface. (Perhaps a current/former mining industry professional could share their experience of this, if they have it.) I would definitely expect the sound to be attenuated strongly though. All the high pitch frequencies would not likely travel through the thick rock leaving just the deep bassy notes perhaps highly reverberated according to the size and shape of the cavity you're in.
That's all likely too realistic for Minecraft anyway. Some basic attenuation functionality of all sounds based on blocks between you and the sound source should be a given no matter if you're surface or subterranean though.