better clouds

i’ve done what i’ve wanted to do for this project for now! i’ve polished up my devlogs, and gonna ship the project now.

here’s a screenshot where i tried to make the clouds look realistic (they’re not supposed to look realistic, so this is very cursed)

Published 1.14.0 release!

• I renamed “Tint” -> “Top Color”, “Bottom Tint” -> “Bottom Color”, “Bottom Transition Range” -> “Color Transition End”
• also renamed the options keys too, with a migration thing that migrates the old options keys to the new ones

ok ima take a break from this project for now! next up, probably a config system rewrite? i want to implement like discord roles thing, where:

• you start with a base config
• given a certain condition (e.g. dimension = minecraft:overworld), certain properties of the config are modified
• and repeat until you get dynamic clouds with your own defined conditions!

or i might not do that idk it sounds kinda complicated

• added a bottom tint option that basically lets you create a gradient on your clouds
• i’m getting quite familiar with shaders and graphics code! this is one of my main goals for the project, and i’m glad it’s working out well!
• also fixed a bunch of bugs

basic description of the bottom tint algorithm:

• vertex shader: tint interpolation progress = (y level of the cloud vertex) / (transition range percentage * cloud height range)
• fragment shader: color = lerp(bottomColor, topColor, tintInterpProgress)

by default, the effect is much more subtle than this, but it is still there

made the celestial body halo much bigger and more visible. i also added separate options for the sun and moon halo, and scaled the moon halo’s size based on the moon phase!

also the way I change the halo size is kinda cursed. i’m using qendolin’s superellipse formula, and i only kinda understand how it works.

// i still have no idea how this formula works but it seems to work fine
float superellipse = (
(1.0 + (1.0 / 3.0) * (pow(cos(2.0 * projAngle), 2.0))) * haloSize * (1.0 - abs(superellipseFalloff)) - 1.0
) * sign(-superellipseFalloff);

then i fit an exponential curve based on what halo size i wanted for which moon phase 💀

// larger value = smaller halo size
float haloSize = dayTime() < config.shaderPreset().sunsetEndTime ?
        2.05f - config.sunHaloSizeMultiplier :
        (float) (5 * Math.pow(0.06217, config.moonHaloSizeMultiplier * DimensionType.MOON_BRIGHTNESS_PER_PHASE[moonPhase.index()]));    // curve fit for ideal moon halo size based on phase

• updated to 26.2, and the blaze3d renderer I made works great on vulkan!

• the renderer was mostly done for weeks now, i just added neoforge back and that was mostly it.

• Iris was giving me problems as it hasn’t implemented reverse z yet. but i was able to fix that really easily because i kinda know what i’m doing now when touching graphics code! this woulda taken me forever if it were the first time i had to do this.

• also added longview support to 26.1.2 then declared it end of life

• Added option in config screen to choose the renderer,
• Also added back frustum culling (where clouds don’t render behind the camera)

Qendolin’s original algorithm for frustum culling was:

1. compute the bounding box of a section of clouds (clouds are generated in sections with a chunk-like system).
2. if the frustum of the camera (basically an object describing what part of the world the camera can see given a camera angle, position, and fov) can see the clouds, expand the bounding box with the next section of clouds
3. else, render all the sections of clouds we can see, and skip this section if we can’t see it

in other words: (original comment from the code)

        // This algorithm loops over chunks, which are in a line-by-line order.
        // When a visible chunk is found it's marked as a run start. The run continues until
        // the next non-visible chunk is found. At the end of a run the entire run is rendered as once.
        // This is possible due to the memory layout of the instance buffers.

I’m preparing for 26.2 release!

• I updated the mod to 26.2 pre-4, as well as YACL 3.9.4 which also just came out earlier today.
• NeoForge is also out but I’m too lazy to setup their custom repo for prerelease builds so I will fix NF support when 26.2 releases.
• I fixed a really annoying bug that was making the cloud ripple effect way larger in magnitude than it was supposed to be (I sampled WorldPosition instead of WorldPosition - originOffset)
• I added a hardcoded minimum brightness in the shader so that clouds will be just barely visible at nighttime.

Also GLSL operations are element-wise which is pretty cool! Like you can do max(color.rgb, vec3(0.15)) and each element of the color vector will be element-wise compared with 0.15, and the bigger one will be chosen. Really elegant solution for my minimum brightness operation.

the renderer looks good again! i added back the light gradient sampling, so the clouds actually turn orange during sunset and go dark at night time like they used to.

btw, I spent like 3 hours reading through https://open.gl/. it’s a great tutorial, and i applied pretty much all of the graphics concepts i learned to this project! i’m using blaze3d instead of opengl this time, but the concepts still apply.

how the algorithm works

based on the time of day, it samples a color from this texture, where the white part of the texture produces the bright fluffy daytime clouds, the dark part produces the dark nighttime clouds, and the remaining orange and light blue produce the amazing cloud colors shown in the image during sunset and sunrise!

i can’t explain the formula too much in detail, cuz i kinda just copied the math from the old code…

spent like 12h getting the blaze3d renderer to work. long story short, the opengl renderer is a mess and I’m doing pretty much a full rewrite to get it to work on blaze3d. it’s taking extremely long but i’m happy because i’m learning a lot about graphics. the core functionality kinda works but there are all sorts of bugs, and a bunch of features are missing. some of them i probably just won’t be adding back.

the old opengl renderer used a three shader setup:

• a coverage shader (establishes positions and colors of each cloud cube)
• a shading shader (recolors each cloud cube based on saturation, sunlight, and other properties)
• a depth shader (changes the transparency for each pixel based on how many cubes are overlapping)

…wait what, why do you need all that? i assume order-independent transparency? whatever, i’m not doing allat, hopefully a simple cube drawing will work and blaze3d can handle the transparency stuff

right now i have just one fragment shader and one vertex shader, basically the rendering setup possible.

hopefully i don’t need anything else, considering i’m literally drawing just cubes…

p.s. vulkan renderer so cool! performance is a lot better than opengl on my mac

p.p.s cool formula: gl_Position = ProjMat * ViewMat * vec4(pos, 1) (ball knowledge required)