Minecraft Forums

Due to minecraft forum's new requirement of owning a twitch account and the fact that I don't have any interest in doing that, I have decided to leave minecraft forums entirely. These shaders aren't going anywhere, but I won't be watching this thread anymore after my account becomes unusable on october 23'rd, 2017. As I type this, the only other contact method I have is through the shader labs discord (https://discord.gg/FMghhxk), so for the forseeable future that will be the recommended place to report bugs or request features. This also means I won't be replying to this topic anymore to announce new releases, but I've edited the download link in the main post to include ALL versions, past or future. If minecraft forums ever removes the twitch requirement (and doesn't replace it with an even worse requirement), I'll gladly come back, but right now the odds of that are pretty slim. I just hope that people can continue enjoying these shaders without me.

Only increase the amount of memory allocated if the game is actually running out of memory. If you look at the top right of the F3 menu, it should tell you how much memory is being used. Only give it more if that number is above 75% constantly. If it's less than 75% then you don't need to allocate more, and if it's less than 25% you'll actually gain performance by decreasing the amount of memory allocated. Beyond that, if you really do need to increase it, Herb_'s answer is correct.

If 95% of the memory you've allocated is unused, then you won't gain any performance by allocating more. If anything, performance will be worse that way. Memory is rarely ever the bottleneck when it comes to performance in minecraft. If it still says can't keep up, then it's most likely your CPU that's the bottleneck. In general, you want to allocate just a little bit more than what the server's actually using (try to keep it between 50% and 75% used). In vanilla, you rarely ever need more than 256-512 MB, and in your case you could probably get away with 128 MB without any issues. Only increase the amount of memory allocated if it's actually running out of memory (more than 75% is used constantly).

If you're flying in creative, you can hold down both crouch and fly (shift and space) at the same, and they'll cancel each other out so you don't move. That makes placing hoppers (and other inventories) much easier.

Sound physics is a client-side mod. Remove it from the server.

Guess not. V1.14.5 released.

• All: Separated underwater fog from regular fog
• All: Enabled optifine's old lighting setting by default, this replaces my hacky SHADE_FIX code.
• QOL and modded: Overhauled underwater fog colors
• QOL: Clouds and void clouds now render through end portals

Quote from Gregosteros»

I already have an idea. Stay tuned.

Any news yet? I'm ready to do another release, and if your idea works, I'd like to include it in said release.

Spawners cannot spawn directly next to each other, no. They can get quite close though, as seen in that video and others like it. has proven that the theoretical maximum number of spawners that can spawn within the activation range of a single player is 72.

It is not possible to obtain a spawner as an item in legit survival. They can be obtained via /give, but not by any other means. They can't even be pick-block'ed in creative. and have also shown ways of creating pig spawners in survival, but not as an item in your inventory.

Modifying the game to make them drop is doable, but not client-side. In other words, you could do this in singleplayer, but not as a multiplayer hack unless you also modified the server jar file. Nevertheless, if you wanted to do this for singleplayer use, you'd first have to know how to code in java, and use MCP to decompile minecraft's source code. If you don't know how to do either of those, you'll need to learn that first, as I won't be explaining them here. Once you do have that though, you'll just need to remove a few methods from net.minecraft.block.BlockMobSpawner. Specifically, remove getItemDropped(IBlockState, Random, int) and quantityDropped(Random), as those are the 2 methods that prevent spawners from dropping normally. Without them, spawners should drop just like any other item, as they now delegate to the super class. You can also remove getItem(World, BlockPos, IBlockState) to make pick-block work on it. It may also be worth while to remove getExpDrop(IBlockState, IBlockAccess, BlockPos, int), as otherwise it'll drop XP AND its normal item every time you break it, which could be used to gain infinite XP. It should also be noted that as you've predicted, it will only drop a pig spawner with these modifications. If you wanted to make it drop the correct mob, you'd need to write the tile entity to an NBTTagCompound, then set that compound on the item dropped when broken (in the breakBlock(World, BlockPos, IBlockState) method). See net.minecraft.block.BlockShulkerBox for more info on how to do that. If you do this, you'll also need to remove all code from dropBlockAsItemWithChance(World, BlockPos, IBlockState, float, int) WITHOUT removing the method itself, as otherwise it'll drop twice (once as normal, and once with the custom NBT tag). Disclaimer: All of these method names I got from 1.11.2 forge source code, so they may be slightly inaccurate for other versions, or plain old MCP (without forge).

EDIT: For some reason, posting a link to a youtube video embeds it instead. No idea why MCF is doing that.

Quote from eletric_outlet»

Thanks for the pack. I've encountered two problems so far, one that's kind of bad, and one that doesn't really matter. The one that kind of blows, is that whenever I stare directly at a vanilla skeleton, minecraft turns into a total blackscreen until I look away(this happened with other shaders I was testing too. Could it be a mod conflict?). The other issue has to do with hitbox outlining (F3 + B). I have it on all the time, for some reason I can't see item hitbox outlinings, but mostly everything else I can see the hitboxes (mobs, boats, and minecarts, etc). And, the hitboxes I can see have differently colors than white (not even an issue, but it's kind of strange).

Sorry if this is asking for too much, but can you edit out the effect of night vision + blindness too, where you literally can't see anything?

To clarify those claims, and try to give some more straight-forward answers: Blindness is indeed a fog effect. Specifically, minecraft changes the fog color to black, and massively reduces the distance at which it appears whenever you have the blindness effect. Shaders CAN remove this effect, simply because shaders have to no concept of fog; you have to implement it manually. The same goes for grass/foliage colors, and light levels; as both of those are specified by minecraft, and not native to OpenGL. Running a shader pack that does nothing but remove blindness also wouldn't be hard to run on any computer. The reason shaders have a bad reputation for being laggy is because a lot of popular packs add WAY more effects than just removing fog.

With all that said though, shaders are not the best way of doing this. The best way would be to disable those mobs giving blindness in their config file. If that isn't configurable, then I would suggest asking the mod developer to add a config option for it. This shader pack is only intended to be a temporary solution. The reason for this is that it isn't customizable. If a mod adds a biome with more fog than normal, this shader pack will break that effect and use vanilla fog densities instead. Additionally, shaders aren't compatible with some mods. Side effects of this range from blocks not rendering correctly to your game flat out crashing. Plus, if you want to use blindness for anything in the future, you won't be able to while running this shader pack.

Quote from Gregosteros»

Water does that in real life. (I have taken that photo last year at Campanile di San Marco)

Can you see the problem right now? You are right that your LOD prevents some flickering in the far distance. (which is also only visible when your camera moves) BUT: Water ripples shouldn't just magically stay at the same apparent magnitude and size when you fly away from a water surface.

Real life water tends to lose detail at extreme distances due to all the "pixels" being too close together to tell them apart. When you take a picture of it, they all average together. Shaders don't work like that, so you get flickering when you move your camera. I'm fully aware that water doesn't realistically have the same apparent magnitude/size regardless of distance, but for shaders that's a good way of ensuring that it never flickers at far distances, and never gets smeared out at close distances (since realistically, water has quite a lot of detail even on the scale of centimeters). If you have a better way to avoid both of those problems, let me know, but a constant scaling factor simply does not achieve that; and I think it looks even worse than LODs at everything except medium distances.

Quote from Gregosteros»

Wow, thank you

There is one huge thing that bothers me about your shader: Why did you introduce distance based LOD for the water noise map? Doesn't make sense and looks super unrealistic.

I just had the fun of reintroducing your waterNoiseLOD function in composite1:

	vec2 waterNoiseLOD(vec2 coord, float distance) {
		coord *= 3;
		return waterNoise(coord);
	}

Although this is just a proof of concept test, try it out! You might want to adopt a similar change.

Another one: If you disable Improved Fog, underwater fog will also disappear. I can imagine that this might require larger changes to your codebase but you know the code better than me. I just had a short glimpse in order to find your water render routines.

I use distance-based LODs for water because sun reflections get really pixellated at large distances otherwise (which is common with infinite oceans). This was an intentional design change that was implemented in V1.4.0. To be completely realistic, you'd need to sum up the light being reflected off of every point in the area enclosed by one pixel, and that would be much more expensive computationally, since it would need to do additional noise calculations for all of those points. LODs are simpler, faster, easier to implement, and I don't think they look that unrealistic.

I can probably separate water fog from regular fog. I'll add that to my todo list for the next version.

Quote from Gregosteros»

Bug report: (QOL edition)

Disabling the Improved Fog setting (going from the default settings) results in an invalid codepath.

Compiler spits out this: (snip)

If you disable Infinite Oceans, too, it works again.

I somehow know why I stayed with pure low-level imperative languages all the time. But still, I must dive into shaders someday... What you guys can create solely with shaders is magnificent

Fixed in V1.14.4:

• QOL: Fixed failure to compile when fog was disabled
• All: End portals that are in the end now show the overworld
• All: Moved ambient and block config screens out of the misc. page and into the main page.

If you're interested in learning GLSL, making modifications to existing shader packs is a good place to start. I even have a readme file in my own shaders that explains where various effects are handled. If you're familiar with C-family languages, GLSL should be fairly straight-forward to read. If you have any issues with it, you can always ask me for help here on the forum thread, or in a PM. I'm always happy to help get new people get interested in shaders

Quote from DarianStephens»

I know you can manipulate the position of vertexes, but I don't know if you can make that 2d map something you can actually pull out to look/actually be 3d. Maybe you could do something like a bumpmap, to at least give the illusion of 3d?

I know you've said multiple times that creating geometry in shaders almost isn't worth it, and would be better as a dedicated mod.

The End island image is cool, but it's also very inaccurate for 1.7.10, what with the pillars being randomly placed, the portal being semi-randomly placed only after the dragon dies, and no iron bars on the pillars (Though HEE does add them). Of course, you could never make it totally accurate without a mod which takes a screenshot of the island every so often or something.

*sigh*, the see-through Nether and End portal dream may become reality some day, huh?

I still think void clouds would look cool, and make the portal even more ominous/foreboding.

Woah... I just closed the game, and I forgot that I WASN'T in the End, and was just looking through the portal. I think it's safe to say that looking through the portal now feels like looking into the End!

Oh, and regardless of what you do with the End portal, I don't feel that we should be able to see the End island through the portal when it's IN the End...

The ender island image doesn't have any vertexes to manipulate. Instead, every "position" on the surface of the end portal is "mapped" to a pixel in the image, and the color of that pixel simply overrides the color of the portal at that position. Bump mapping just makes some pixels brighter or darker with a noise pattern, so I don't see how that's useful here. Parallax occlusion mapping might work, though I've never done it before and I just don't think it's worth the effort in this case.

You can't create geometry through shaders. Minecraft tells the GPU what to render, and shaders tell it how to render it. Shaders can change the position of any vertex, and the color of any pixel, but it can't create new geometry out of thin air. Also, no vertex or pixel knows what the data of any other vertex or pixel is, so you can't pick-and-choose which one you're actually modifying. Instead, it basically just throws one at you and you have to decide how to handle it yourself with no knowledge of how any other vertex/pixel will be handled. This is why trying to create "fake" geometry is so impractical. If you wanted to draw 10 lines on the screen just using shaders, every pixel has no better option than to check all 10 of those lines to see if any of them intersect with it. I could go on for hours talking about the ways in which you can simplify problems like this to something that shaders can deal with, but for this specific case, I don't know any "good" methods of actually rendering a 3D version of the end island (or the overworld) through a portal.

The end island image can be found under /shaders/textures/end_island.png. You can replace that with any other screenshot you want, and it should work just fine without any code changes. The only restriction is that the image you choose must be square, and have a transparent background.

Fully see-through portals are impossible, as the end isn't loaded on the client while you're in the overworld, and vise versa. Same for the nether. That would be pretty cool though.

I'll try void clouds then, as I quite like the idea of having them there too.

I guess that means it's working as intended then

Right now I think I'll probably end up going with a "spherical world" image for the overworld to use while you're in the end. It'll be fixed at daytime, and have a solid background color. If void clouds work out, I might add overworld clouds there as well.

Quote from DarianStephens»

So... With the 16x portal fix enabled, the portals just turn invisible. I don't know why or how, but that's what happens.

Plus, my console is getting spammed with:

GL error 0x0500: Invalid enum at pre-final

. That's not related to the portal thing (I think), it's just going constantly.

Perhaps for the overworld, a generic 'continent' and clouds? As if you're looking at it from space. Maybe you could get some inspiration from the way the 'Starminer' mod does it?

That mod MIGHT actually get biome coordinates from the Overworld to generate its map, but I'm not sure. At the very least, the map seems to be generated in code, as I can't find any assets relating to it, but did find class files with related names.

Just for fun, you might even be able to have the 'Overworld' shown in the actual End dimension, heh. Totally just for fun, though. It's not like that would be awesome or anything, baka.