Stone Bricks, Stone, Ores, shield,...

Hey,   
First, a few Important Things for 2021:

You probably have noticed, I have paused the billing cycle for the last few months, and I'm planning to pause it more often in the future.

Why?  Mainly because my content has changed quite a bit in the last ~year.
(Reminder for those who can't read:  You only get charged at the end of the month, so you can always cancel your pledge if you are not interested in what I've created this month - I have charge-up-front disabled for that reason).  
R17 was quite different and took way too long to finish. I also started a few other projects (survival textures, shader programming). In 2020 I tried to remove myself from the normal Minecraft Community as much as possible. We made good progress in this regards and I found a lot of new talented people who are genuinely interested in rendering/3D graphics. (I'll soon add a lot of new awesome Community-Screenshots to the Gallery).

What I've been working on:

1. Textures:

I worked on a few survival-compatible textures ("non-photorealistic").
I used a lot of 3x3 ctm variations - in total I added about 400 new files,
I hope performance impact is not too big.
The main goal was: finishing all stone-stuff. That's done now.
I also finally added a bit of "depth"/POM   (since PTGI HRR now supports POM)

Here are the new textures:

• stone
• all ores (I put the ore in the cracks of the stone. Quite tricky with all the ctm variations)
• cobblestone + mossy cobblestone + slabs/stairs/walls
• stone bricks, mossy stone bricks, cracked-stone bricks + slabs/stairs/walls
• chiseled stone bricks
• smooth stone slabs / regular smooth stone blocks
• also: shield texture
• also: sharpened a few other 256x textures like bricks and oak logs

2. My progress on learning 3d graphics programming:

I looked into how to render all kinds of 360° or even VR images with minecraft shaders.
I coded a basic voxel-raytracer with raytraced lighting/shadows.
I learned how 3D transformations and conversions between different spaces/coordinate systems works in detail/from scratch.
I also finally looked into voxelization, which allows us to interact with and see the blocks in the minecraft map.

For those of you who are interested, here is a somewhat educational summary: 

Camera Projections:

With a raytraced camera-system it's fairly easy to get different projections: Instead of shooting the rays through a rectangle (=screen), we manipulate the ray-direction by mapping all the screen pixel coordinates to a sphere (or a cylinder, or a cube, or any other shape that we can clearly define mathematically). 

Here are the modes that I added (in the shader-settings you can switch between modes and adjust values):

• Equirectangular Projection:  The pixel coordinates get mapped onto a sphere - the rays shoot into all directions and create a 360° panorama. The screen's x,y axes get "wrapped" around the sphere and become it's lateral and longitudinal axes. Similar to how we "unwrap" our world-globe to create a rectangular 2D image. The top and bottom parts of the screen get stretched (the poles on a world-map get stretched too)
  
• Fisheye Projection:   Basically, we simulate how lightrays would hit the camera's sensor with a fisheye-lens in real life. In my shader I can easily create a perfect "angular fish-eye" with perfectly even radial distortion, which means that objects will have the same width(radially!) on screen no matter where they are. They only get distorted on one axis (along the circle)  I added two modes:  Full 360° in one single Fisheye (adjustable FOV and scale factor/zoom)   and 2x 180° (front and back).
  
• Cube-Map:   6 quadratic Tiles (for all 6 faces of a cube). Every Tile is a quadratic screen with a regular camera-projection.   Top, Bottom, Left, Right, Front, Back   ==  full 360°.
  
• Stereographic Projection (VR/Virtual Reality):
  Just splits the screen in half and on both sides you have the same scene rendered from a slightly offset camera-position (Left and Right eye). Haven't implemented it in the shader yet but I think it's really fascinating that thanks to voxelization we can render the entire scene from any arbitrary 3D point in the scene. Basically we could code a "free-cam" shader. Or we could even render the entire minecraft-map seen from above! (e.g: a top-down shooter game). We have the 3D coordinates of all the blocks so we can do anything with it, as long as we can express it mathematically.

Voxelization:

Usually you cannot create 360° images with minecraft shaders because we don't have any 3D information of what's going on behind the player. You can only use the blocks/geometry that's on-screen.   I looked into voxelization which is necessary for proper world-space ray/pathtracing. Basically we exploit the shadow map for this. The entire scene is rendered a 2nd time from the sun's perspective which means that it has access to the entire scene-geometry. From this we can extract individual triangles and with it's surface normal we can get the block's world-space position, even if the block is behind the player. from these coordinates we can then calculate a storage position in the shadow map which we can later access and check if there is a block at this pixel/location.

As far as I know, this exploit has been discovered by Sonic Ether a few years ago. Only because of it we can have all these new shader features like world-space ray/pathtracing. 

Voxel-Raytracing:

Intersecting every single minecraft block (= "voxel") would be insanely slow.

To speed this up, there are algorithms (e.g. Amantides & Woo) that just interect one single cube and then reuse the calculated values to move through the cube-grid (because all cubes are the same).

Each time the ray is entering a new voxel/cube, the algorithm checks the shadow map storage if there is a block at this particular voxel, or if it is air. If it is air, it checks the next block.... - until it finds a solid block. 

There are also many techniques to further accelerate this voxel-traversal algorithm (eg. Octree structures). These algorithms do not traverse every single block but first check large "chunks" of blocks. If there is no solid block in a large chunk, it just skips all the tiny blocks and goes to the next large chunk.

This helps with large spaces with only air in it.  In my current test shaders, I only use the most basic algorithm. I might look into octrees but I fear that they may decrease FPS too much in non-empty areas - probably not worth it - at least not in minecraft.

Passing light source positions through the shadow map:

In PTGI, with pathtracing, you don't need to know the location of the light sources because a pathtracer is "blind". We shoot rays into random directions, until we hit a light source.
But if we want to add simple raytraced shadows, we first need the position of the light source before we even shoot the ray. I tried to solve this problem by using a "light-chunk system" - it works but is very in-efficient.

The idea:   I split the map into 4x4 light-chunks (you can adjust it in the settings). Every light-chunk can hold one light source so you must place them at least 3 blocks apart. This would never work good in a "gameplay-shader" but that's not my goal at all.

I store the light's 3D voxel coordinates in the shadow map, but use a fixed location (e.g: somewhere at the corners of the shadow map).  When accessing this data I iterate over these pixels and render the light sources from the positions stored in these pixels. Not great but this way we can finally place blocks AND light sources to play around with raytraced shadows. And that's pretty much the only goal/use of this shader so far. 

I think this new shader is actually somewhat fun to play around with - if you are interested in this kind of stuff.  The Map I used for the screenshots is the old "Broville" map, really great to test the lighting.

Future plans for the shader? I'll add colored lightsources & blocks, raytraced reflections, raytraced glass refractions - just like in the previous test-shaders. These things could be easily implemented without introducting any sort of noise that would require a denoiser.  
I certainly will look into soft shadows and other "stochastic" features in the future.

Next Textures?    I'd like to create more "non-photorealistc" survival textures. The creation process is faster and not as frustrating.