I figured it would be something like that. I wonder if that'll ever get backported? We got the shader stuff, but we apparently aren't getting custom item textures (Which is the main thing, right up there with shaders, that I was looking forward to. I've got so many ideas, and they're just not possible without either that or making a mod!).
I'm guessing the system lets you make a variable that you can insert a bunch of IDs into, and you can use in place of an ID to act on all listed ones? That sounds like it would reduce a lot of tedium.
I thought that image with the staticky aurora would have been enough, but I have at least one more example of thin stuff.
I'll leave it as the first image here.
You know, I keep making a lot of assumptions with this shader pack. I actually thought you did have some kind of system, since prismarine blocks were glowing, but then I just... assumed it was something else.
That's a vignette? Is that what all the shader packs are doing? It looks like the light is being applied just in front of your face, and it always annoyed me. Most shader packs also have horrible light distribution, where a single held torch can potentially light up things 100+ blocks away, with SEUS being the most prominent example I can think of. Just look at a distant anything with and without a torch held.
I like Optifine's implementation because they're real (If clientside and not caring about occlusion) lights, so they are at the right radius, have the appropriate visual effects, and just fit nicer with the game. It also doesn't have that issue where the light moves if you're in third-person.
I don't know... I mean, I've dealt without it in vanilla for ages, why would it be any worse now?
You are talking about how one wall is arbitrarily darker than the other, right? Because that just doesn't make sense.
It's not a white line, it's a full-blown gap. You can see that when it goes down to the cliff.
...Huh? How is that the block alias system? All water has the appropriate effects, it's just that they are temporarily removed whenever the liquid block updates. The same goes for lava, and probably any other fluids if you've accounted for any. This is the sort of thing I'm talking about.
That 'OLD_LIGHTMAP' option is separate from the 'Vanilla Lightmap' option, right? Because I've recently created a resource pack that restores the pure-white, non-flickering light from the alpha/beta period.
If you're going to do shadow stuff, I'm sure you'll make it a configurable option (And maybe off by default?). I personally feel that shadows like this don't really fit with Minecraft's aesthetic, and the lack of ingame interaction (Thing like mobs not burning up with light shining through a cave entrance directly onto them) does a lot to take you out of it. Well, me out of it. I know loads of people like shadows and are willing to look past that, but I personally... don't really like them too much.
I was extremely excited when they were first announced, and thought they looked awesome. They still do, but over time I've gained a deeper appreciation for more vanilla gameplay, opting to enhance and enrich the core game rather than replace or add such wild things as writing dimensions or mining the Earth from orbital satellites, it just kinda feels wrong. Basically, if it can be done with the vanilla game, I'd rather enhance that and work around the limitation than remove them entirely. It's why I'm not using mods like Project Red or Railcraft; sure, they offer neat enhancements, but Project Red goes too far and makes the vanilla redstone mechanics pretty much useless, while Railcraft seems to have so much stuff in it that gets in the way of the core concept of enhancing rails and minecarts.
As far as I know, the block alias system exists in HD_U_D7, though I could be wrong. Anyway, in shaders I have access to a variable called "mc_Entity.x", which returns the numeric ID of the block that's currently being rendered. So if it returns 2, then I know that the block that the current vertex belongs to is grass. The problem with this is that for an effect like wind, you have to check for everything that has wind effects. Tall grass, double tall grass, 2 different flowers, 2 different mushrooms, and 4 different crops. It's not exactly the most performant check in the world, especially if every vertex in the world has to do it every frame. The other problem is that it doesn't work for modded blocks, since their IDs are saved with the world, and not constant. Optifine's block alias system solves both of these problems by allowing me to specify a list of blocks that I want to be "mapped" to a given ID (see block.properties). In the case of wind, all of the blocks I just mentioned will "trick" mc_Entity.x into returning 31. This allows me to check only one ID to see if it has wind effects or not, which is much better on performance. Recently, I took this a step farther and mapped every block that had ANY effect to its standard ID + 10000. That way, I only have to check once to see if the ID is above 10000, and then figure out which effect to apply. Since most blocks in the world don't have any effects, this will also improve performance, since they'll all just do one check and then stop. This is what the ID_FIX config option is for, it removes the greater than 10000 check. In the next version it'll also manually check for all the IDs I've added mappings for.
The static-y mob in that screenshot is experiencing a problem called z-fighting. This occurs when two or more faces are exactly the same distance away from the camera, and due to floating point rounding errors, some pixels think the first one is in front, and others think the second one is in front. Whichever one wins is the one that actually gets rendered, and it looks awful when adjacent pixels disagree on which one should be the winner. I don't think my shaders could cause that in this case, since I don't modify vertex positions of entities. Most likely whatever mob that is isn't enabling back-face culling, which means that both the front and back faces of those horns attempt to render when only one of them is supposed to. And yes, the front and back sides of a face are two separate polygons (technically 4, since you can only "draw" triangles, and it takes two of them to make a square). Which mod is that mob from? It's most likely on their end, but I'll test it anyway to see if I can figure out anything. Also, which mod are the auroras from? They probably should be more colorful than that, which leads me to believe that I'm applying way too much fog to them (which might be fixable on my end)
My system for held lights is pretty simple. Step 1: check if the block in your hand emits light. This is a single variable provided by optifine, so anything that works with its dynamic lights will pass this check. Step 2: compare it against a list of blocks that I've specified colored light for. If it matches one of them, then use that as the color. If it doesn't, use the default color. The brightness (and radius) of the light is always proportional to the brightness returned by that first variable I tested to see if it emits light at all. In the case of torches and other things that flicker, I also add a small random number to its brightness. There's some extra logic for checking the offhand, but it still uses the color/brightness of whichever hand has the highest light value. Again, light level is controlled entirely by optifine. It's just the color that I modify.
Vignette makes the edges of your screen darker. I don't personally like the effect, but I make held lights darker towards the edge of your screen in a similar way just because it helps reduce the "circle that follows you" effect. I call it vignette because I don't have a better word for it, and it's pretty similar to the traditional vignette effect, just for held lights and nothing else. Like I said though, it'll be configurable in the next version.
I know of the 100+ block torches problem, and that was the first thing I changed when I was still learning about shaders by modifying other people's shader packs. I think it was chocapic's in this case. Mine have a hard limit to how far they can go, though it's definitely farther than vanilla lights. Should I reduce it a bit? Also, the fact that it changes position in 3rd person is quite funny, and I didn't know about that until now. I guess if it's that big of a deal I can stop disabling optifine's version and add a note to mine saying that having both enabled at the same time isn't recommended.
Vanilla actually DOES have different block shadings on different faces, even underground. They just don't track the sun, and they're much subtler than mine. Specifically, the top face has a multiplier of 1, the north and south faces have a multiplier of 0.8, east and west are 0.6, and the bottom is 0.5. Mine range from 0.25 to 1, depending on how similar its normal vector is to the sun or moon.
If that's an entire gap, then the vertex positions are incorrect, and I don't control that.
When still water (ID 9) gets a block update, it converts itself into flowing water (ID 8) and schedules an update for itself 8 ticks in the future. This is the same update scheduling mechanic that repeaters use to delay signals. When the flowing water is "informed" that its 8 ticks are up, it checks all the blocks around it to figure out where it should flow. If it finds a valid direction, it will flow that way, creating more flowing water and scheduling more updates in the process. If it determines that it can't flow anywhere, then it simply reverts to still water again. Meanwhile, I set flowing water and still water to both return 9 using the alias system, so I only have to check for one of them to see if it's water. If optifine returns 8 instead because it doesn't have support for the alias system, then it won't show any of my effects because it's technically a different block even if it normally has the same texture. The same applies for lava (using IDs 10 and 11), and all other modded fluids using whatever ID they've been assigned by forge.
I handle lighting with semi-hardcoded colors for block light and skylight. Blocklight gets yellower if you stand away from any artificial light for a while, and skylight gets darker at night, and redder at sunset. VANILLA_LIGHTMAP disables this effect and checks the vanilla light colors instead. OLD_LIGHTMAP on the other hand does my standard calculations, but also ADDS on top of it whatever vanilla says the darkest color is (light level 0 for both block light and sky light). Since this is usually black, it doesn't usually make a difference, but if you have night vision then vanilla will return a much brighter color. This is how I handle night vision if you're using old optifine versions that don't support the uniform for it.
The problem with configurable shadows is that simply telling optifine that you *might* use them (which you have to do even if they're disabled) will still make optifine calculate depth masks for them, which requires rendering the world twice instead of once (from the perspective of the sun). If I do release them, they'll still be configurable anyway for people who don't like them, but they won't be in the main pack because of how laggy they'd be even when disabled. Personally I don't particularly like shadows that much either, and they cause too much lag for me personally to use in survival, but I enjoyed figuring out how to do it, and I'm happy with how they look for creative purposes. I figure that if other people DO like them, then I might as well release them. Just not in the main pack.
After much delay, new versions are finally released! Main version updated to V1.11.0, modded version updated to V1.1.0, and a new lite version is now available too. The shadows version I mentioned before isn't released yet, but I haven't forgotten about it either. Change logs:
For all versions:
Fixed star rendering
New feature: Can now remove biome coloring on sugar cane (disabled by default)
Reduced block shading underground slightly
Vignette for held lights is now configurable
No longer disabling optifine's native dynamic lights. Do note that it it still not recommended to use both at the same time!
Additional changes for the main version:
Ender sky effects now apply to end portals too
Ported cross-processing from modded version
Ported wet dirt from modded version
Ported new block alias system from the modded version. Once again, if you notice that tallgrass no longer waves or that water no longer refracts, you'll need to enable ID_FIX to revert to the old system!
Better glass more accurately reflects reality. still not flawless when there are other transparent things in front of or behind it though.
Possibly improved enchantment glow rendering. Still doesn't work with held items, but it should work slightly better with other mobs/players now.
Modded: Fixed sea level being at y52 instead of y63. I changed that for my own use because I was using biome bundle at the time (which has a lower sea level than vanilla), and forgot to change it back to normal when I released it.
QOL and modded: Revamped noise algorithms for water refraction/reflection and ice scattering. Both now use new noise functions, water now takes sky access and rain strength into account, and ice scattering now has LOD.
QOL and modded: Tweaked sun reflections a bit
QOL: Fixed clouds not having volumetric effects behind transparent objects, which caused z-fighting issues in some cases
, but you listed that under 'Additional changes for the main version', while it does appear to be in the modded one.
However, the End Portals look glitchy, almost like water without 'ID Fix' turned on.
It also seems that fishing rod lines, and any mod that uses them, aren't rendered.
I've shown all those problems in the attached screenshot.
This was likely an unavoidable side effect of removing the fog code, but I figure I'd let you know that the Nether's fog no longer brightens/darkens randomly in the modded edition.
Sorry I didn't get back to you sooner; I guess I just didn't. Anyway, those mods you wanted to test!
, but you listed that under 'Additional changes for the main version', while it does appear to be in the modded one.
However, the End Portals look glitchy, almost like water without 'ID Fix' turned on.
It also seems that fishing rod lines, and any mod that uses them, aren't rendered.
I've shown all those problems in the attached screenshot.
This was likely an unavoidable side effect of removing the fog code, but I figure I'd let you know that the Nether's fog no longer brightens/darkens randomly in the modded edition.
Sorry I didn't get back to you sooner; I guess I just didn't. Anyway, those mods you wanted to test!
I first figured out how to apply the effect to end portals while working on the modded version. As such, it was there to begin with. That's why it only appears in the change log for the standard version.
Dammit. Getting end portals to work properly was a hack to begin with. Basically, they re-render 16 times, and if I applied the space effect to them each time, it would be 16x brighter than it should be. I *could* reduce brightness by 16x on the portals to counter this, but it's unbelievably laggy to re-apply the effect 16 times for every pixel. My solution to this was to sample the depth mask as it was rendering, and compare it to the depth of the portal itself. If it found there was already something at the same depth, it would skip all effects. Remember the old black ripples on water? Those were caused by me reading and writing to the same buffers. And I'm doing the same here, just with depth buffers instead of color buffers. That's why it looks completely broken. I'll test it in 1.7, but I'm not sure I can do anything about it. I might just report this to optifine instead, requesting that they overwrite the end portal render completely when shaders are enabled to only use one square instead of 16 on top of each other.
Not sure which program even handles fishing rod lines, though that might be related to the fact that "lines" in general have issues when shaders are enabled. The same thing happens with the chunk grid provided by chicken chunks, or the vanilla one that was added in 1.10 with F3+G.
The nether should still have fog in the modded version, but you're correct that it doesn't randomly get brighter/darker. The reason for this is that the nether doesn't have a "sky", so I can't apply that color behind everything. In the standard version this isn't a problem, because all the transparent stuff renders separately from the opaque stuff. Therefore I can get in the middle of that and apply the brightened fog color to everywhere that doesn't have terrain, and then render transparent stuff on top of it. In the modded and lite versions though, everything renders in more or less the same way, so if I tried to do it there, it wouldn't show up at all behind anything transparent. So I chose to remove that feature entirely in the modded and lite versions instead. Funnily enough though, the ender space background doesn't have this issue because while the end doesn't have a "basic" sky either, it DOES have a "textured" sky, which normally renders the static texture. As such, I overwrite this in the modded and lite versions instead of doing it the way I did in the standard version. This does mean that it's constantly being calculated regardless of weather or not you're actually looking at the sky, but that's the only way it works at all. Plus, the terrain in the end is simpler anyway, and there are fewer effects in the end than the overworld, so overall framerate is about the same.
I'll test both of those mods to see what I can find.
-------------------------------- Testing has been done. --------------------------------
End portals didn't render at all with the original shaders mod, and with optifine HD_U_D7 and D8, they rendered exactly as they're suposed to without any visual artifacts. Since I can't reproduce it, I'll report it to optifine instead.
Fishing rod lines have been reproduced, and it is the same bug as the chunk grid thing. Not much I can do about that sadly.
The sheep from improving minecraft are z-fighting for me even with shaders disabled, so that's on their end.
Dynamic surroundings auroras I wasn't able to test properly. In 1.7, auroras didn't render at all, and in 1.10 they rendered as a solid gray color whenever shaders were even enabled (even the internal shaders, which don't do anything). As such, there's not much debugging I can do there either.
How do i disable to lighting of my character being affected or enable waving leaves? Sorry if this comes off rude.
Not sure what you mean by lighting of your character, but my pack doesn't have waving leaves because I've never found an implementation of them that looks at all realistic. For waving grass, it's a pretty simple system. There's always one fixed anchor point below it (the ground), so the only part that can move is the top. With leaves though, there's no guarantee which parts of it will be supported and which parts won't. As such, you can't make it dynamically stay still when supported on one side, which looks really bad when using them for decoration. Plus, realistically the entire tree should be swaying, and each tree should be mostly independent of the other trees around it. This is completely impossible to do with shaders because A: there's no way of knowing where its anchor point on the ground is, and B: there's no way of knowing which tree any particular leaf even belongs to. This is especially the case in dense forests, where trees overlap.
That's right! It's time for another BIG update, because today's the day I finally implemented some REAL clouds! Not just in the overworld either; the end now has its own set of dark, ominous, void clouds as well! But wait, there's more! I've also added a brand new starry background for the night sky in the overworld! Complete with a new, randomly generated galaxy every single night! But it doesn't stop there! Call now, and you'll also get all of these features as well:
All versions: Removed hacky end portal code, as optifine has now kindly implemented a proper fix for it in HD_U_B9. However, since that version is still in beta, end portal effects have been temporarily disabled by default until it's officially released and back-ported to all supported MC versions.
All versions: XP orbs now cycle through the entire color spectrum instead of just yellow and green (configurable). Coincidentally, this has also fixed a few bugs with circular shadows as well. And speaking of which:
Lite and modded: Ported circular entity shadows from main version.
QOL and modded: Improved detection of which hand is currently rendering. It's still not perfect when rapidly rotating your camera while eating/drinking, but at least half of your hand won't think something different from the other half anymore. As such, the COMPAT17 option has been removed. And speaking of hands:
Lite and modded: Ported hand sway from main version.
Lite and modded: Nightvision fix (also known as OLD_LIGHTMAP) is now disabled by default, since the version of optifine required for nightvision to work properly has been out of beta for quite a while now.
All versions: Generic code improvements and bug fixes, as usual.
It's cool to see some stuff come back, and the night sky looks pretty great.
However, I don't think it works like this.
By 'real' clouds, I assume you don't mean full-blown, 3D volumetric clouds, right? I also kinda hope we can have an option for more Minecraft-y clouds; it was kinda cool how they were visible from... I don't know how far, and how they fit in with the rest of the cube world.
It's cool to see some stuff come back, and the night sky looks pretty great.
However, I don't think it works like this.
By 'real' clouds, I assume you don't mean full-blown, 3D volumetric clouds, right? I also kinda hope we can have an option for more Minecraft-y clouds; it was kinda cool how they were visible from... I don't know how far, and how they fit in with the rest of the cube world.
They still have the same fake volumetric effects that have been there for a while now. Basically, any time some terrain is sufficiently close to the cloud level, clouds are calculated for the position of that terrain instead of the projected position of the cloud plane, and then overlaid on top of said terrain. Additionally, any time your camera position is sufficiently close to the cloud level, clouds get calculated a second time for the position of your camera, and the resulting color is overlaid onto the entire screen. This means I only have to calculate cloud colors twice, and the second time doesn't even need to be re-calculated for every pixel, so it's faster as well. I'd say it's a good mix of semi-volumetric-ness and performance. Clouds also calculate normal vectors so that the side facing the sun is more illuminated than the side facing away. This also gives the illusion that they have some depth to them. They still use the same visibility logic as the old ones, though they can be seen from farther away since I increased the default cloud height from 128 to 256. This was kind of necessary since they're much larger than the old ones too.
I call them "real" clouds because they look far more realistic than the old square ones did. The old clouds were kind of a rushed feature used as a test to make sure all the logic for rendering them was correct. I never planned on keeping them that way forever, and I believe that was even mentioned in the change log. Also keep in mind that the default MC clouds work as expected in the modded and lite versions. I guess if it's that big of a deal though, I could add a config option for them anyway. EDIT: Done in V1.13.1.
I hate to be rude, but I don't think you noticed the issue I tried to point out in my post:
The fact that stars are visible on/through the moon.
There's also the interesting fact that, since the stars are now moving faster than the moon towards the horizon, the moon must be orbiting the planet in the same direction as the planet rotates, and the only reason the moon appears to move in the sky at all is because the planet rotates faster than the moon orbits it.
I hate to be rude, but I don't think you noticed the issue I tried to point out in my post:
The fact that stars are visible on/through the moon.
There's also the interesting fact that, since the stars are now moving faster than the moon towards the horizon, the moon must be orbiting the planet in the same direction as the planet rotates, and the only reason the moon appears to move in the sky at all is because the planet rotates faster than the moon orbits it.
The sun and moon use additive blending when rendering, which means that they simply brighten colors behind them instead of overwriting them. That's on mojang's end. Even if I managed to convince optifine to fix that, it would break nearly every resource pack in existance (including the default textures) because the texture that the moon uses has a black background instead of a transparent one (as does the sun). This is why some shader packs simply disable the sun and moon, and render them manually. This can sometimes work for the sun, but the moon has quite a lot more detail to it. Not only does it have an endless number of craters on its surface, it also has a different phase every day. I've yet to see a shader pack which actually bothers with either of those things. The only thing I could possibly do at this point would be to disable star rendering near the moon; but since the moon doesn't even have the same shape in every resource pack, I'd have to take a "better safe than sorry" approach and make them fade out at a fairly large radius around it. I could try that, but I'm not sure how good it would look to have a fairly large area in the sky with absolutely no stars in it.
I tried to make the stars rotate at the same speed as the sun/moon, but it's technically not a rotation at all. I'm actually using the same transformation as the ender nebulae (or at least a very similar one) to draw them, so they're technically just sliding in one direction along a curved path. As such, some parts of it will get distorted more than others, and therefore the stars will appear to move at different speeds in different places. If there's a real-world way that this could happen though, then I'd be happy to blame it on that instead
In the shader configuration menu, are you able to allow the player to input a float? That way people could configure it themselves to look right.
If you can't, then maybe close, medium, and far ranges for that?
If you can't do any of that, then it should still be pretty simple to instruct people how to adjust it in the files, right?
The shader configuration menu does not currently have support for text boxes, no. Floating point values can be used, but only as a list of values that the button will cycle through. Additionally, I can make specific values display as text when selected, so "close", "medium", and "far" is doable. It has also been requested before that optifine add support for sliders as well as buttons, but that's currently the oldest issue still open on his issue tracker, and I don't think it's actively being worked on, despite having the "todo" label. I definitely could add a comment telling people how to edit it though, it is just one number after all.
...We are talking about the fadeout radius around the moon, right?
EDIT: Done in V1.13.2:
All: Tweaked sunset colors again
All: Fancy stars/galaxies now fade out around the moon
QOL and modded: The sun/moon now fade out near the horizon when infinite oceans are enabled.
Modded: Fixed failure to compile when infinite oceans are disabled (whoops)
All: Standard bug fixes and improvements
Lite and modded: Changed versioning system to keep major versions consistent between editions. All future releases will match the major version of the QOL edition.
Just reporting that I think there may be a bug with bows casting dynamic light when in hand.
That's all I've found so far. Thank you so much for the shaders...they've quickly become my main. May I suggest adding Depth of Field? I've always enjoyed it and as far as I've seen so far, it's the only thing I've missed. Thanks again!
Just reporting that I think there may be a bug with bows casting dynamic light when in hand.
That's all I've found so far. Thank you so much for the shaders...they've quickly become my main. May I suggest adding Depth of Field? I've always enjoyed it and as far as I've seen so far, it's the only thing I've missed. Thanks again!
Dynamic light level is provided entirely by optifine. If bows are emitting light, then that's on their end. Additionally, I can't reproduce this on optifine 1.10.2_HD_U_D8. Which version are you using?
Also, could you provide some tips on getting your shaders to play nicely with the mod Streams? Streams provides a readout on what to replace in a log.
Shader configuration: if you wish to use shaders with custom water blocks including Streams river blocks, edit your shader's gbuffers_water.vsh file to replace the line:
if (mc_Entity.x == 8 || mc_Entity.x == 9) {
with the following line:
if (mc_Entity.x == 8 || mc_Entity.x == 9 || mc_Entity.x == 298 || mc_Entity.x == 732 || mc_Entity.x == 733 || mc_Entity.x == 750 || mc_Entity.x == 751 || mc_Entity.x == 752 || mc_Entity.x == 753 || mc_Entity.x == 754 || mc_Entity.x == 1380 || mc_Entity.x == 1381 || mc_Entity.x == 1382 || mc_Entity.x == 1383 || mc_Entity.x == 1384 || mc_Entity.x == 1385 || mc_Entity.x == 1387 || mc_Entity.x == 1388 || mc_Entity.x == 1490 || mc_Entity.x == 1509 || mc_Entity.x == 1510 || mc_Entity.x == 1511 || mc_Entity.x == 1512 || mc_Entity.x == 1513 || mc_Entity.x == 1514 || mc_Entity.x == 1515 || mc_Entity.x == 1516 || mc_Entity.x == 1517 || mc_Entity.x == 1518 || mc_Entity.x == 1519 || mc_Entity.x == 1520 || mc_Entity.x == 1521 || mc_Entity.x == 1522 || mc_Entity.x == 1523 || mc_Entity.x == 1524 || mc_Entity.x == 1525) {
Note that these ids will change with every new combination of loaded mods.
That is what the log tells me to replace in gbuffers_water.vsh. I've attempted to do so and my edited version of your gbuffers_water.vsh looks like this now.
Either I erred somewhere (which is most likely the culprit) or your code is set up in a way that may not support said mod. If I could get any advice or feedback, I'd greatly appreciate it. Thanks!
P.S. Sorry about the formatting in the second pasted code. I just noticed that it didn't include line breaks.
As far as I know, the block alias system exists in HD_U_D7, though I could be wrong. Anyway, in shaders I have access to a variable called "mc_Entity.x", which returns the numeric ID of the block that's currently being rendered. So if it returns 2, then I know that the block that the current vertex belongs to is grass. The problem with this is that for an effect like wind, you have to check for everything that has wind effects. Tall grass, double tall grass, 2 different flowers, 2 different mushrooms, and 4 different crops. It's not exactly the most performant check in the world, especially if every vertex in the world has to do it every frame. The other problem is that it doesn't work for modded blocks, since their IDs are saved with the world, and not constant. Optifine's block alias system solves both of these problems by allowing me to specify a list of blocks that I want to be "mapped" to a given ID (see block.properties). In the case of wind, all of the blocks I just mentioned will "trick" mc_Entity.x into returning 31. This allows me to check only one ID to see if it has wind effects or not, which is much better on performance. Recently, I took this a step farther and mapped every block that had ANY effect to its standard ID + 10000. That way, I only have to check once to see if the ID is above 10000, and then figure out which effect to apply. Since most blocks in the world don't have any effects, this will also improve performance, since they'll all just do one check and then stop. This is what the ID_FIX config option is for, it removes the greater than 10000 check. In the next version it'll also manually check for all the IDs I've added mappings for.
The static-y mob in that screenshot is experiencing a problem called z-fighting. This occurs when two or more faces are exactly the same distance away from the camera, and due to floating point rounding errors, some pixels think the first one is in front, and others think the second one is in front. Whichever one wins is the one that actually gets rendered, and it looks awful when adjacent pixels disagree on which one should be the winner. I don't think my shaders could cause that in this case, since I don't modify vertex positions of entities. Most likely whatever mob that is isn't enabling back-face culling, which means that both the front and back faces of those horns attempt to render when only one of them is supposed to. And yes, the front and back sides of a face are two separate polygons (technically 4, since you can only "draw" triangles, and it takes two of them to make a square). Which mod is that mob from? It's most likely on their end, but I'll test it anyway to see if I can figure out anything. Also, which mod are the auroras from? They probably should be more colorful than that, which leads me to believe that I'm applying way too much fog to them (which might be fixable on my end)
My system for held lights is pretty simple. Step 1: check if the block in your hand emits light. This is a single variable provided by optifine, so anything that works with its dynamic lights will pass this check. Step 2: compare it against a list of blocks that I've specified colored light for. If it matches one of them, then use that as the color. If it doesn't, use the default color. The brightness (and radius) of the light is always proportional to the brightness returned by that first variable I tested to see if it emits light at all. In the case of torches and other things that flicker, I also add a small random number to its brightness. There's some extra logic for checking the offhand, but it still uses the color/brightness of whichever hand has the highest light value. Again, light level is controlled entirely by optifine. It's just the color that I modify.
Vignette makes the edges of your screen darker. I don't personally like the effect, but I make held lights darker towards the edge of your screen in a similar way just because it helps reduce the "circle that follows you" effect. I call it vignette because I don't have a better word for it, and it's pretty similar to the traditional vignette effect, just for held lights and nothing else. Like I said though, it'll be configurable in the next version.
I know of the 100+ block torches problem, and that was the first thing I changed when I was still learning about shaders by modifying other people's shader packs. I think it was chocapic's in this case. Mine have a hard limit to how far they can go, though it's definitely farther than vanilla lights. Should I reduce it a bit? Also, the fact that it changes position in 3rd person is quite funny, and I didn't know about that until now. I guess if it's that big of a deal I can stop disabling optifine's version and add a note to mine saying that having both enabled at the same time isn't recommended.
Vanilla actually DOES have different block shadings on different faces, even underground. They just don't track the sun, and they're much subtler than mine. Specifically, the top face has a multiplier of 1, the north and south faces have a multiplier of 0.8, east and west are 0.6, and the bottom is 0.5. Mine range from 0.25 to 1, depending on how similar its normal vector is to the sun or moon.
If that's an entire gap, then the vertex positions are incorrect, and I don't control that.
When still water (ID 9) gets a block update, it converts itself into flowing water (ID 8) and schedules an update for itself 8 ticks in the future. This is the same update scheduling mechanic that repeaters use to delay signals. When the flowing water is "informed" that its 8 ticks are up, it checks all the blocks around it to figure out where it should flow. If it finds a valid direction, it will flow that way, creating more flowing water and scheduling more updates in the process. If it determines that it can't flow anywhere, then it simply reverts to still water again. Meanwhile, I set flowing water and still water to both return 9 using the alias system, so I only have to check for one of them to see if it's water. If optifine returns 8 instead because it doesn't have support for the alias system, then it won't show any of my effects because it's technically a different block even if it normally has the same texture. The same applies for lava (using IDs 10 and 11), and all other modded fluids using whatever ID they've been assigned by forge.
I handle lighting with semi-hardcoded colors for block light and skylight. Blocklight gets yellower if you stand away from any artificial light for a while, and skylight gets darker at night, and redder at sunset. VANILLA_LIGHTMAP disables this effect and checks the vanilla light colors instead. OLD_LIGHTMAP on the other hand does my standard calculations, but also ADDS on top of it whatever vanilla says the darkest color is (light level 0 for both block light and sky light). Since this is usually black, it doesn't usually make a difference, but if you have night vision then vanilla will return a much brighter color. This is how I handle night vision if you're using old optifine versions that don't support the uniform for it.
The problem with configurable shadows is that simply telling optifine that you *might* use them (which you have to do even if they're disabled) will still make optifine calculate depth masks for them, which requires rendering the world twice instead of once (from the perspective of the sun). If I do release them, they'll still be configurable anyway for people who don't like them, but they won't be in the main pack because of how laggy they'd be even when disabled. Personally I don't particularly like shadows that much either, and they cause too much lag for me personally to use in survival, but I enjoyed figuring out how to do it, and I'm happy with how they look for creative purposes. I figure that if other people DO like them, then I might as well release them. Just not in the main pack.
I made my own shader pack, by the way.
After much delay, new versions are finally released! Main version updated to V1.11.0, modded version updated to V1.1.0, and a new lite version is now available too. The shadows version I mentioned before isn't released yet, but I haven't forgotten about it either. Change logs:
For all versions:
Additional changes for the main version:
I made my own shader pack, by the way.
New versions released:
I made my own shader pack, by the way.
You say that the
, but you listed that under 'Additional changes for the main version', while it does appear to be in the modded one.
However, the End Portals look glitchy, almost like water without 'ID Fix' turned on.
It also seems that fishing rod lines, and any mod that uses them, aren't rendered.
I've shown all those problems in the attached screenshot.
This was likely an unavoidable side effect of removing the fog code, but I figure I'd let you know that the Nether's fog no longer brightens/darkens randomly in the modded edition.
Sorry I didn't get back to you sooner; I guess I just didn't. Anyway, those mods you wanted to test!
For the aurora, it's in the Dynamic Surroundings mod, and those sheep were from the Improving Minecraft mod.
I do appreciate you continuing to work on this.
I first figured out how to apply the effect to end portals while working on the modded version. As such, it was there to begin with. That's why it only appears in the change log for the standard version.
Dammit. Getting end portals to work properly was a hack to begin with. Basically, they re-render 16 times, and if I applied the space effect to them each time, it would be 16x brighter than it should be. I *could* reduce brightness by 16x on the portals to counter this, but it's unbelievably laggy to re-apply the effect 16 times for every pixel. My solution to this was to sample the depth mask as it was rendering, and compare it to the depth of the portal itself. If it found there was already something at the same depth, it would skip all effects. Remember the old black ripples on water? Those were caused by me reading and writing to the same buffers. And I'm doing the same here, just with depth buffers instead of color buffers. That's why it looks completely broken. I'll test it in 1.7, but I'm not sure I can do anything about it. I might just report this to optifine instead, requesting that they overwrite the end portal render completely when shaders are enabled to only use one square instead of 16 on top of each other.
Not sure which program even handles fishing rod lines, though that might be related to the fact that "lines" in general have issues when shaders are enabled. The same thing happens with the chunk grid provided by chicken chunks, or the vanilla one that was added in 1.10 with F3+G.
The nether should still have fog in the modded version, but you're correct that it doesn't randomly get brighter/darker. The reason for this is that the nether doesn't have a "sky", so I can't apply that color behind everything. In the standard version this isn't a problem, because all the transparent stuff renders separately from the opaque stuff. Therefore I can get in the middle of that and apply the brightened fog color to everywhere that doesn't have terrain, and then render transparent stuff on top of it. In the modded and lite versions though, everything renders in more or less the same way, so if I tried to do it there, it wouldn't show up at all behind anything transparent. So I chose to remove that feature entirely in the modded and lite versions instead. Funnily enough though, the ender space background doesn't have this issue because while the end doesn't have a "basic" sky either, it DOES have a "textured" sky, which normally renders the static texture. As such, I overwrite this in the modded and lite versions instead of doing it the way I did in the standard version. This does mean that it's constantly being calculated regardless of weather or not you're actually looking at the sky, but that's the only way it works at all. Plus, the terrain in the end is simpler anyway, and there are fewer effects in the end than the overworld, so overall framerate is about the same.
I'll test both of those mods to see what I can find.
-------------------------------- Testing has been done. --------------------------------
End portals didn't render at all with the original shaders mod, and with optifine HD_U_D7 and D8, they rendered exactly as they're suposed to without any visual artifacts. Since I can't reproduce it, I'll report it to optifine instead.
Fishing rod lines have been reproduced, and it is the same bug as the chunk grid thing. Not much I can do about that sadly.
The sheep from improving minecraft are z-fighting for me even with shaders disabled, so that's on their end.
Dynamic surroundings auroras I wasn't able to test properly. In 1.7, auroras didn't render at all, and in 1.10 they rendered as a solid gray color whenever shaders were even enabled (even the internal shaders, which don't do anything). As such, there's not much debugging I can do there either.
I made my own shader pack, by the way.
YOOOOOOOOOOOO This Shaderpack is amazing.
Glad you like it
I made my own shader pack, by the way.
How do i disable to lighting of my character being affected or enable waving leaves? Sorry if this comes off rude.
Not sure what you mean by lighting of your character, but my pack doesn't have waving leaves because I've never found an implementation of them that looks at all realistic. For waving grass, it's a pretty simple system. There's always one fixed anchor point below it (the ground), so the only part that can move is the top. With leaves though, there's no guarantee which parts of it will be supported and which parts won't. As such, you can't make it dynamically stay still when supported on one side, which looks really bad when using them for decoration. Plus, realistically the entire tree should be swaying, and each tree should be mostly independent of the other trees around it. This is completely impossible to do with shaders because A: there's no way of knowing where its anchor point on the ground is, and B: there's no way of knowing which tree any particular leaf even belongs to. This is especially the case in dense forests, where trees overlap.
I made my own shader pack, by the way.
GUESS. WHAT. DAY. IT. IS!
That's right! It's time for another BIG update, because today's the day I finally implemented some REAL clouds! Not just in the overworld either; the end now has its own set of dark, ominous, void clouds as well! But wait, there's more! I've also added a brand new starry background for the night sky in the overworld! Complete with a new, randomly generated galaxy every single night! But it doesn't stop there! Call now, and you'll also get all of these features as well:
I made my own shader pack, by the way.
It's cool to see some stuff come back, and the night sky looks pretty great.
However, I don't think it works like this.
By 'real' clouds, I assume you don't mean full-blown, 3D volumetric clouds, right? I also kinda hope we can have an option for more Minecraft-y clouds; it was kinda cool how they were visible from... I don't know how far, and how they fit in with the rest of the cube world.
They still have the same fake volumetric effects that have been there for a while now. Basically, any time some terrain is sufficiently close to the cloud level, clouds are calculated for the position of that terrain instead of the projected position of the cloud plane, and then overlaid on top of said terrain. Additionally, any time your camera position is sufficiently close to the cloud level, clouds get calculated a second time for the position of your camera, and the resulting color is overlaid onto the entire screen. This means I only have to calculate cloud colors twice, and the second time doesn't even need to be re-calculated for every pixel, so it's faster as well. I'd say it's a good mix of semi-volumetric-ness and performance. Clouds also calculate normal vectors so that the side facing the sun is more illuminated than the side facing away. This also gives the illusion that they have some depth to them. They still use the same visibility logic as the old ones, though they can be seen from farther away since I increased the default cloud height from 128 to 256. This was kind of necessary since they're much larger than the old ones too.
I call them "real" clouds because they look far more realistic than the old square ones did. The old clouds were kind of a rushed feature used as a test to make sure all the logic for rendering them was correct. I never planned on keeping them that way forever, and I believe that was even mentioned in the change log. Also keep in mind that the default MC clouds work as expected in the modded and lite versions. I guess if it's that big of a deal though, I could add a config option for them anyway. EDIT: Done in V1.13.1.
I made my own shader pack, by the way.
I hate to be rude, but I don't think you noticed the issue I tried to point out in my post:
The fact that stars are visible on/through the moon.
There's also the interesting fact that, since the stars are now moving faster than the moon towards the horizon, the moon must be orbiting the planet in the same direction as the planet rotates, and the only reason the moon appears to move in the sky at all is because the planet rotates faster than the moon orbits it.
The sun and moon use additive blending when rendering, which means that they simply brighten colors behind them instead of overwriting them. That's on mojang's end. Even if I managed to convince optifine to fix that, it would break nearly every resource pack in existance (including the default textures) because the texture that the moon uses has a black background instead of a transparent one (as does the sun). This is why some shader packs simply disable the sun and moon, and render them manually. This can sometimes work for the sun, but the moon has quite a lot more detail to it. Not only does it have an endless number of craters on its surface, it also has a different phase every day. I've yet to see a shader pack which actually bothers with either of those things. The only thing I could possibly do at this point would be to disable star rendering near the moon; but since the moon doesn't even have the same shape in every resource pack, I'd have to take a "better safe than sorry" approach and make them fade out at a fairly large radius around it. I could try that, but I'm not sure how good it would look to have a fairly large area in the sky with absolutely no stars in it.
I tried to make the stars rotate at the same speed as the sun/moon, but it's technically not a rotation at all. I'm actually using the same transformation as the ender nebulae (or at least a very similar one) to draw them, so they're technically just sliding in one direction along a curved path. As such, some parts of it will get distorted more than others, and therefore the stars will appear to move at different speeds in different places. If there's a real-world way that this could happen though, then I'd be happy to blame it on that instead
I made my own shader pack, by the way.
In the shader configuration menu, are you able to allow the player to input a float? That way people could configure it themselves to look right.
If you can't, then maybe close, medium, and far ranges for that?
If you can't do any of that, then it should still be pretty simple to instruct people how to adjust it in the files, right?
The shader configuration menu does not currently have support for text boxes, no. Floating point values can be used, but only as a list of values that the button will cycle through. Additionally, I can make specific values display as text when selected, so "close", "medium", and "far" is doable. It has also been requested before that optifine add support for sliders as well as buttons, but that's currently the oldest issue still open on his issue tracker, and I don't think it's actively being worked on, despite having the "todo" label. I definitely could add a comment telling people how to edit it though, it is just one number after all.
...We are talking about the fadeout radius around the moon, right?
EDIT: Done in V1.13.2:
I made my own shader pack, by the way.
Just reporting that I think there may be a bug with bows casting dynamic light when in hand.
That's all I've found so far. Thank you so much for the shaders...they've quickly become my main. May I suggest adding Depth of Field? I've always enjoyed it and as far as I've seen so far, it's the only thing I've missed. Thanks again!
Dynamic light level is provided entirely by optifine. If bows are emitting light, then that's on their end. Additionally, I can't reproduce this on optifine 1.10.2_HD_U_D8. Which version are you using?
I could give DOF a try, I guess.
I made my own shader pack, by the way.
I'm using 1.11.2 HD U B9. Thanks for the reply. I'll try to report it on Optifine's end.
Also, could you provide some tips on getting your shaders to play nicely with the mod Streams? Streams provides a readout on what to replace in a log.
Shader configuration: if you wish to use shaders with custom water blocks including Streams river blocks, edit your shader's gbuffers_water.vsh file to replace the line:
if (mc_Entity.x == 8 || mc_Entity.x == 9) {
with the following line:
if (mc_Entity.x == 8 || mc_Entity.x == 9 || mc_Entity.x == 298 || mc_Entity.x == 732 || mc_Entity.x == 733 || mc_Entity.x == 750 || mc_Entity.x == 751 || mc_Entity.x == 752 || mc_Entity.x == 753 || mc_Entity.x == 754 || mc_Entity.x == 1380 || mc_Entity.x == 1381 || mc_Entity.x == 1382 || mc_Entity.x == 1383 || mc_Entity.x == 1384 || mc_Entity.x == 1385 || mc_Entity.x == 1387 || mc_Entity.x == 1388 || mc_Entity.x == 1490 || mc_Entity.x == 1509 || mc_Entity.x == 1510 || mc_Entity.x == 1511 || mc_Entity.x == 1512 || mc_Entity.x == 1513 || mc_Entity.x == 1514 || mc_Entity.x == 1515 || mc_Entity.x == 1516 || mc_Entity.x == 1517 || mc_Entity.x == 1518 || mc_Entity.x == 1519 || mc_Entity.x == 1520 || mc_Entity.x == 1521 || mc_Entity.x == 1522 || mc_Entity.x == 1523 || mc_Entity.x == 1524 || mc_Entity.x == 1525) {
Note that these ids will change with every new combination of loaded mods.
That is what the log tells me to replace in gbuffers_water.vsh. I've attempted to do so and my edited version of your gbuffers_water.vsh looks like this now.
#endif #endif
#ifdef ID_FIX if (mc_Entity.x == 8 || mc_Entity.x == 9 || mc_Entity.x == 298 || mc_Entity.x == 732 || mc_Entity.x == 733 || mc_Entity.x == 750 || mc_Entity.x == 751 || mc_Entity.x == 752 || mc_Entity.x == 753 || mc_Entity.x == 754 || mc_Entity.x == 1380 || mc_Entity.x == 1381 || mc_Entity.x == 1382 || mc_Entity.x == 1383 || mc_Entity.x == 1384 || mc_Entity.x == 1385 || mc_Entity.x == 1387 || mc_Entity.x == 1388 || mc_Entity.x == 1490 || mc_Entity.x == 1509 || mc_Entity.x == 1510 || mc_Entity.x == 1511 || mc_Entity.x == 1512 || mc_Entity.x == 1513 || mc_Entity.x == 1514 || mc_Entity.x == 1515 || mc_Entity.x == 1516 || mc_Entity.x == 1517 || mc_Entity.x == 1518 || mc_Entity.x == 1519 || mc_Entity.x == 1520 || mc_Entity.x == 1521 || mc_Entity.x == 1522 || mc_Entity.x == 1523 || mc_Entity.x == 1524 || mc_Entity.x == 1525) mcentity = 1.1; //water #else if (id == 9) mcentity = 1.1; //water #endif #ifdef ID_FIX else if (id == 95 || id == 160) mcentity = 2.1; //stained glass #else else if (id == 95) mcentity = 2.1; //stained glass #endif else if (id == 79) mcentity = 3.1; //ice else mcentity = 0.1;
#ifndef ID_FIX } else mcentity = 0.1; #endif
Either I erred somewhere (which is most likely the culprit) or your code is set up in a way that may not support said mod. If I could get any advice or feedback, I'd greatly appreciate it. Thanks!
P.S. Sorry about the formatting in the second pasted code. I just noticed that it didn't include line breaks.