SakeTami
balintshaders
balintshaders

patreon


VPT rewrite start

Hey! Welcome to my patreon page. It's been a while since I've released any meaningful updated to VanillaPuddingTart (apart from basically version bumps). The main reason for this was that I couldn't go any further with the current approach.

The way the shader was originally written basically threw away all of the rendering work done by the game and instead used a fully path traced approach. This is unideal because

So I thought the best way to continue was to stop working on it entirely for almost 9 months and do other stuff (like a shader editor website here) and then start working on implementing a much better solution.

I'll explain the technical details of the actual solution later in the post, so if you don't care about that or don't have the programming/graphics experience for it, you can skip it easily.

The current shader is way too early in development to share, but I put an example image of a stray being affected by the surrounding light sources below (something I couldn't do with the old system) and I also attached a video of a dynamic system with some redstone to this post. A couple of notes on them, first, the noise is a side effect of the technology I use to do the lights, reducing it will come later once I have something that's worth to reduce. Secondly, on the image I replaced the texture of a redstone lamp with a fully red image just for the sake of the demonstration. Currently light colors are dependent on the texture of the blocks. I might keep it this way for simplicity and compatibility with already existing texture packs. Thirdly, I'm using HardTop's 64x vanillaccurate resourcepack in these images, you can find that here. More on what this takes right after the image.

Anyways, here's the picture:

There were two reasons for why it took this long to get to this point, for one I was waiting for new versions hoping Mojang would add some extra stuff I could utilize to make my life easier, this was largely fruitless (damn you Mojang for leaving a feature half baked). The other one was developing the technologies and tools (both for myself and the eventual users) I need to finish this. This also funnily included me having to finally write a personal page (find that here) because I wanted to put my tools somewhere.

Anyways, resourcepacks:

The problem with using raw resourcepacks is that for technical reasons I need access to the atlas (the large texture minecraft jams every other texture into), in fact I need three of them for optifine compatibility, and those aren't even assembled by the game by default. To solve this I do the same thing I had to do for VPT 1, I create my own atlas (if you ever tried that shader, go into the generated pack and look for assets/minecraft/textures/effect/atlas.png and you'll see what I'm talking about). The issue with that approach was having to ask users to download multiple things and run a terminal application. I since realized that this was a huge mistake because it turns a lot of people away from trying the pack. And until I am able to pester people into providing a third type of resourcepack alongside the already cumbersome two I am out of luck. 

Instead I decided to write a page on my new site that does the conversion. This generates a new(ish) zip that acts like a resourcepack and is meant to be loaded on top of the shader. Here's a small preview of the site:

And think that's it for this. I intend these posts to act like devlogs sans a youtube channel. If you are interested in some technical aspects, then read further, otherwise see you at the next post.

Technical aspects

The main idea behind the shader is the same as the previous one. I need a way to store the blocks in the world somewhere so that I can later use that information for path tracing. The difference between VPT 1 and the new version is how much of the screen I use for this. The original shader threw everything on screen away and replaced it with the block storage, this is why entities behaved like they do in the original image, them being on screen made the shader interpret them as block data.

The aim of the new version was to keep at least some data for the screen. Originally I implemented this into what became Minificent by basically checkerboarding the image, I'd use every odd pixel for data storage and the rest would go toward the original game. This had one major caveat, I had to know how large the screen is, but not all parts of the pipeline had this data accessible to them. This lead to a rather inelegant solution where I locked the shader behind my editor and required users to enter their screen resolutions.

Recently I got around this by basically assuming the screen is a certain small resolution (1024x705 because this was the smallest resolution with at least 1% market share on the Steam hardware survey) and then discarding everything but the top left pixels of each "meta-pixel". The result is that I sacrifice some of the view distance (from 60 blocks in all directions I went down to 45) for ease of use. This is not as big of a deal tho, since if you are tech-savy enough (or I make a tool for it) you can just change it to suit your actual resolution better.

Here's an image of what the game looks like without any post processing (the random pixels get removed in post):

In post then I remove the random pixels by averaging neighbours out (this is basically invisible since pixels are tiny on modern displays) and then I do the path tracing.

That's about it for now. See ya!


More Creators