I'm getting the wrong lighting from the sun, this problem on any shader pack. if you know how to solve this problem plese help me!
Win10 x64
Fly out and load any parts of the world that would be casting those shadows. This is an issue with Optifine and how Minecraft culls geometry, there's nothing we, as in shader devs, can do to fix this on our end.
Actual texture filtering doesn't blur textures like that, rather it switches between mip levels depending on the distance from the camera, to prevent texels from becoming smaller than a pixel and causing flickering in the distance.
I do have a question, though: Will shaders now be more compatible with mods?
Also, that light jitter and that wavy water is nice.
Work is being done to Optifine to improve compatibility with mods, but there really isn't a way to have shaders be perfectly compatible with mods, simply because of how much control the game gives mods, at least from my experience writing mods under 1.7.10. You can quite literally mess with the state of the OpenGL pipeline, and touch things that shaders don't expect to be touched. On top of the fact that Optifine is just one giant hack when it comes to shader support.
In other words, I either need to file a feature request with Optifine to make this possible, or find a different shader pack that requires Forge (I have a vague memory that there are some, and I imagine they would be able to call the Minecraft methods to check for the appropriate conditions, though I could be wrong on one or both counts).
However, I'm also curious why the undersides of my chests seem wet when it's raining, as seen here: https://imgur.com/R4S6YeQ
No shader packs use Forge, unfortunately, so your only other option would be to request it in Optifine. Though if memory serves me correctly, there isn't much room left in the vertex format, so the best solution would be a true/false value, I'd say.
And the undersides of blocks is probably an oversight on Sonic Ether's part. You can very easily check if a pixel is pointing in a certain direction, so Sonic Ether could scale the wetness based on how much the pixel is pointing up.
I'm having the same problem, about a year later. My guess is that it's using something equivalent to "canSeeSky" instead of "isRainingAt", but searching the files, I haven't figured out where it is performing the comparison or function call to determine whether a block will get rain puddles (blocks under trees and in caves are dry even while it's raining, so I know it isn't just applying it to all blocks without some sort of check)
So, this is a limit with how Optifine currently works. Unfortunately, Optifine doesn't give us a variable for whether a block can see the sky, or whether a block is being rained on. The closest thing Optifine gives us, would be the lightmap coordinate for sky light.
Brief explanation, the way lighting works in Minecraft, is each position in the world has two light strengths: a block light strength, and a sky light strength. Block light is light emitted by blocks, such as torches, glowstone, furnaces, redstone lamps, etc. Sky light is light emitted by the sky/environment. Both light strengths are expressed as a whole number between 0 and 15 (16 total values). Minecraft then takes both light strengths, divides them by 16, then pairs them together to form an XY coordinate pair, with X corresponding to block light and Y corresponding to sky light. This coordinate pair is used to read a certain pixel from a special 16x16 texture, known as the lightmap. The lightmap is a 2-way gradient that basically acts as a function: for the given lighting conditions, what is the final lighting colour? This is how Minecraft's lighting is coloured, ie no sky light and little block light gives a reddish colour, no block light and little sky light gives a bluish colour, etc.
Now, both the lightmap itself, and this XY coordinate pair are given to the shader. The shader can use the XY coordinate pair to read the light strength values for both block (X) and sky (Y) light for any pixel on a block face. Though the shader doesn't treat these as strength values, more, distance values. How far the current pixel is from the nearest light source.
Puddles use the sky light, raised to some high power, ie `pow(skyLightValue, 10.0)`, to work out whether a block is visible to the sky or not. Unfortunately, only blocks which, well, block sky light can prevent visibility, which is why glass seems to let rain through. As it lets sky light through.
Hello all, I come bearing a request. Since recent updates for Minecraft and Windows 10, I've been able to run Minecraft a lot more smoothly without the help of Optifine. Recently, I tried to put together a list of client side mods to use while playing vanilla single player and on servers. Optifine crashed me every time i tried to load a world, be it a server, a Realm, or a personal single player save. I removed it immediately, and I was back up to where I used to be performance wise, back up in the 40-50 FPS range, even with other mods. The main reason I was using Optifine was for the built in shaders mod, since the standalone shaders mod doesn't have a 1.12 forge compatible version as far as I'm aware, but it does have a standalone one. Does any one know any other mods that allow shaders to work with forge, or know of a 1.12 version of the standalone shaders mod that works with forge? Thanks in advance.
Optifine is your only option for the majority of shader packs, as the majority of shader packs outright require Optifine, and will not work with the standalone shaders mod.
Hi, thanks so much! The tilt-shift effect is what I was looking for, as interesting as the rest of that mod is
And yes, I am using optifine, this just seemed like the correct thread to discuss shaders in a general sense.
Your shader works well and the comments were super helpful for figuring out how it works!
That said, it looks to me like the shader from that old mod made use of depth. I messed around a bit with MrY's DoF shader, and I got some fake-miniature effects from turning the hyperfocal distance way up. I guess this is moving away from tilt-shift and instead just making the focus behave a bit like everything is physically small... but maybe we shouldn't use the real world's compromises with a virtual camera?
It looks to me like the blur in this DoF shader isn't as good as yours though, unless I'm just pushing it too far.
You mentioned in your shader that it wouldn't be too hard to turn it into a DoF shader. Is that something you're interested in doing? It's ok if not, I should be able to plug the right things in. I just get the impression it'd take me a while longer. And, well, you might have a better idea of which variables could go crazy big/small (I've been using a hyperfocal distance of 10000 rather than the default 3).
Here you go! To get the effect you're looking for, turn Auto Adjust off, and play around with Fixed Focal Point, Strength and Macro Adjustment until you get something you like. The Fixed Focal Point is in blocks, and can go up to 64 blocks in increments of 4 through the settings menu.
The mod might have used depth, not sure, but that shader you linked seems to use real-world equations for the camera: something I'm not familiar with. Still, you can get a comparable result by messing around with the options in my pack.
I know it's a long shot but is there anyone around who knows enough about writing shaders to port the tilt-shift shader from this old mod? (Scroll to download and choose Final.fsh).
I think it needs proper settings added rather than taking the variables from the companion mod, and it needs a .vsh
Alternatively, anyone got a tip on where to go to figure this out? I've seen this wiki but it seems pretty bare.
Here you go. It isn't the same tilt shift effect from the mod, but is a tilt shift shader I just wrote in an hour or two. It has options for controlling the axis it uses, the strength, the amount of samples, and it also has a dispersion effect like more complete shaders tend to have. You could also modify it to be a full depth of field effect very easily, by just changing a single variable and replacing the code for that variable. I do recommend using Optifine instead of Karyonix's shaders mod, as otherwise you won't get the options system Optifine supports, but it should work with Karyonix's shaders mod.
As for the perspective features, that is much harder. You'd need to write custom transform and projection matrices, and completely override the default camera with a custom one. That has been done before (see the Acid Interstate videos by BruceKnowsHow, a lot of stuff in them requires custom matrices), but is outside my capabilities.
The second image makes it fairly clear that it's an integrated gpu, and the i5-4210u is a laptop cpu that runs at 1.7 GHz, so it technically doesn't meet the minimum requirements to run Minecraft, let alone shaders.
The 4210U actually has a 2.7GHz single-core boost frequency. The 1.7GHz is its idle frequency, it can boost up to 2.4GHz on all cores equally if it needs the extra power, and a single core can boost up to 2.7GHz (though this isn't that common). Furthermore, the 4210U is a more than adequate CPU for Minecraft.
Source: My laptop has a 4210U paired with a GeForce 840M, and ran vanilla Minecraft at 200-300 FPS. 1.7.10 with 200+ mods at 60-80 FPS in a fresh world, 30-60 in an end-game base.
Karyonix's shaders mod, but do keep in mind most modern shaders outright require Optifine, and will not work with any other version of the shaders mod.
Here's a dumb question - how is it that they're running out?
Yeah, I get it, wasted block IDs, but why is there a limit in the first place? Such a limit seems so arbitrary and unnecessary, but shedding some light on why it exists would make me feel differently.
Chunks are split into 16x16x16 segments. Each segment contains various arrays of byte data about that segment, with each index in the array corresponding to a physical location in the segment (so index 0 might indicate the bottom-most left block, 1 is one block over, etc). We only care about two of these arrays, the "Block" array and the "Add" array. Now the "Block" array contains 4096 bytes (16x16x16=4096=1 byte per block), where the "Add" array contains 2048 bytes (16x16x16=4096/2=2048=1 byte per 2 blocks=4 bits per block).
Numerical ID's for blocks are expressed as 12 bits, which is where the 4096 block ID limit for modded comes from. The first 8 bits are stored in the "Block" array, and the last 4 bits are stored in the "Add" array. When the game reads a given position in the segment, it reads the first 8 bits from the "Block" array, then reads the last 4 bits from the "Add" array, and shifts the 4 bits over to the left by 8 positions. Then it adds the two values together to get the final, full ID. Now the problem is, in vanilla, the "Add" array is somehow disabled. Mods activate it, but Mojang has yet to. So Mojang is still only using 8 bits to store the ID, which results in the 256 block ID limit the game has currently.
They could activate the "Add" array, which would raise the block ID limit to 4096 in vanilla, but 4096 is still pretty low: I ran out of block ID's with 280 or so mods in 1.7.10, when I could easily run 300+ mods on my system. So they're coming up with a new way of storing ID's, that keeps this current system in place, but extends off of it such that each individual ID is unique to the segment it's stored in. Under 1.13's system, chunk segments will also store a thing called an "ID palette", which maps textual ID's ("minecraft:stone") to numerical ID's (3). Because the palette is local to the chunk segment, it moves the 4096 block ID limit from the game itself to each individual chunk segment, which coincidentally each chunk segment can store at maximum 4096 unique blocks (16x16x16=4096), so it's impossible for a single chunk segment to run out of ID's. And that's where the whole "infinite ID" thing is coming from, under 1.13 the limit will be however many block instances an array in Java can store, which at minimum is around 2 billion or so, assuming arrays use signed 32-bit integers.
Asking for help with shaders but not specifying your graphics card is a little like asking a mechanic for help, but not specifying the brand, make and model of your car. What graphics card are you using?
Also, I urge you to give other shaders a go, as RudoPlays is a very outdated and, frankly, crap shader.
1
Fly out and load any parts of the world that would be casting those shadows. This is an issue with Optifine and how Minecraft culls geometry, there's nothing we, as in shader devs, can do to fix this on our end.
0
Actual texture filtering doesn't blur textures like that, rather it switches between mip levels depending on the distance from the camera, to prevent texels from becoming smaller than a pixel and causing flickering in the distance.
0
Work is being done to Optifine to improve compatibility with mods, but there really isn't a way to have shaders be perfectly compatible with mods, simply because of how much control the game gives mods, at least from my experience writing mods under 1.7.10. You can quite literally mess with the state of the OpenGL pipeline, and touch things that shaders don't expect to be touched. On top of the fact that Optifine is just one giant hack when it comes to shader support.
0
Try updating Optifine to the latest version.
0
Yep, we've been talking about it in the shaderLABs Discord. He's already got it in.
0
No shader packs use Forge, unfortunately, so your only other option would be to request it in Optifine. Though if memory serves me correctly, there isn't much room left in the vertex format, so the best solution would be a true/false value, I'd say.
And the undersides of blocks is probably an oversight on Sonic Ether's part. You can very easily check if a pixel is pointing in a certain direction, so Sonic Ether could scale the wetness based on how much the pixel is pointing up.
0
So, this is a limit with how Optifine currently works. Unfortunately, Optifine doesn't give us a variable for whether a block can see the sky, or whether a block is being rained on. The closest thing Optifine gives us, would be the lightmap coordinate for sky light.
Brief explanation, the way lighting works in Minecraft, is each position in the world has two light strengths: a block light strength, and a sky light strength. Block light is light emitted by blocks, such as torches, glowstone, furnaces, redstone lamps, etc. Sky light is light emitted by the sky/environment. Both light strengths are expressed as a whole number between 0 and 15 (16 total values). Minecraft then takes both light strengths, divides them by 16, then pairs them together to form an XY coordinate pair, with X corresponding to block light and Y corresponding to sky light. This coordinate pair is used to read a certain pixel from a special 16x16 texture, known as the lightmap. The lightmap is a 2-way gradient that basically acts as a function: for the given lighting conditions, what is the final lighting colour? This is how Minecraft's lighting is coloured, ie no sky light and little block light gives a reddish colour, no block light and little sky light gives a bluish colour, etc.
Now, both the lightmap itself, and this XY coordinate pair are given to the shader. The shader can use the XY coordinate pair to read the light strength values for both block (X) and sky (Y) light for any pixel on a block face. Though the shader doesn't treat these as strength values, more, distance values. How far the current pixel is from the nearest light source.
Puddles use the sky light, raised to some high power, ie `pow(skyLightValue, 10.0)`, to work out whether a block is visible to the sky or not. Unfortunately, only blocks which, well, block sky light can prevent visibility, which is why glass seems to let rain through. As it lets sky light through.
0
Optifine is your only option for the majority of shader packs, as the majority of shader packs outright require Optifine, and will not work with the standalone shaders mod.
0
Here you go! To get the effect you're looking for, turn Auto Adjust off, and play around with Fixed Focal Point, Strength and Macro Adjustment until you get something you like. The Fixed Focal Point is in blocks, and can go up to 64 blocks in increments of 4 through the settings menu.
The mod might have used depth, not sure, but that shader you linked seems to use real-world equations for the camera: something I'm not familiar with.
Still, you can get a comparable result by messing around with the options in my pack.
0
Here you go. It isn't the same tilt shift effect from the mod, but is a tilt shift shader I just wrote in an hour or two. It has options for controlling the axis it uses, the strength, the amount of samples, and it also has a dispersion effect like more complete shaders tend to have. You could also modify it to be a full depth of field effect very easily, by just changing a single variable and replacing the code for that variable. I do recommend using Optifine instead of Karyonix's shaders mod, as otherwise you won't get the options system Optifine supports, but it should work with Karyonix's shaders mod.
As for the perspective features, that is much harder. You'd need to write custom transform and projection matrices, and completely override the default camera with a custom one. That has been done before (see the Acid Interstate videos by BruceKnowsHow, a lot of stuff in them requires custom matrices), but is outside my capabilities.
0
The 4210U actually has a 2.7GHz single-core boost frequency. The 1.7GHz is its idle frequency, it can boost up to 2.4GHz on all cores equally if it needs the extra power, and a single core can boost up to 2.7GHz (though this isn't that common). Furthermore, the 4210U is a more than adequate CPU for Minecraft.
Source: My laptop has a 4210U paired with a GeForce 840M, and ran vanilla Minecraft at 200-300 FPS. 1.7.10 with 200+ mods at 60-80 FPS in a fresh world, 30-60 in an end-game base.
What specific laptop do you have?
0
If there isn't a Forge version available, then your only option is Optifine.
0
Karyonix's shaders mod, but do keep in mind most modern shaders outright require Optifine, and will not work with any other version of the shaders mod.
1
Because of how they saved the ID's on your storage. Here is the source for all this.
Chunks are split into 16x16x16 segments. Each segment contains various arrays of byte data about that segment, with each index in the array corresponding to a physical location in the segment (so index 0 might indicate the bottom-most left block, 1 is one block over, etc). We only care about two of these arrays, the "Block" array and the "Add" array. Now the "Block" array contains 4096 bytes (16x16x16=4096=1 byte per block), where the "Add" array contains 2048 bytes (16x16x16=4096/2=2048=1 byte per 2 blocks=4 bits per block).
Numerical ID's for blocks are expressed as 12 bits, which is where the 4096 block ID limit for modded comes from. The first 8 bits are stored in the "Block" array, and the last 4 bits are stored in the "Add" array. When the game reads a given position in the segment, it reads the first 8 bits from the "Block" array, then reads the last 4 bits from the "Add" array, and shifts the 4 bits over to the left by 8 positions. Then it adds the two values together to get the final, full ID. Now the problem is, in vanilla, the "Add" array is somehow disabled. Mods activate it, but Mojang has yet to. So Mojang is still only using 8 bits to store the ID, which results in the 256 block ID limit the game has currently.
They could activate the "Add" array, which would raise the block ID limit to 4096 in vanilla, but 4096 is still pretty low: I ran out of block ID's with 280 or so mods in 1.7.10, when I could easily run 300+ mods on my system. So they're coming up with a new way of storing ID's, that keeps this current system in place, but extends off of it such that each individual ID is unique to the segment it's stored in. Under 1.13's system, chunk segments will also store a thing called an "ID palette", which maps textual ID's ("minecraft:stone") to numerical ID's (3). Because the palette is local to the chunk segment, it moves the 4096 block ID limit from the game itself to each individual chunk segment, which coincidentally each chunk segment can store at maximum 4096 unique blocks (16x16x16=4096), so it's impossible for a single chunk segment to run out of ID's. And that's where the whole "infinite ID" thing is coming from, under 1.13 the limit will be however many block instances an array in Java can store, which at minimum is around 2 billion or so, assuming arrays use signed 32-bit integers.
0
Asking for help with shaders but not specifying your graphics card is a little like asking a mechanic for help, but not specifying the brand, make and model of your car. What graphics card are you using?
Also, I urge you to give other shaders a go, as RudoPlays is a very outdated and, frankly, crap shader.