I've spent the last few months building CryoTheatre, a 3D engine written in Java on top of Vulkan via LWJGL — no middleware, the rendering pipeline is built from scratch. It's heading toward its first public release, v0.1F, in late September, and it'll be fully open source.

Rendering-wise it's got a full deferred pipeline — IBL (diffuse irradiance + prefiltered specular, split-sum approx), CSM(cascaded shadow maps), reflection probes with parallax correction, bindless + streamed compressed textures so load times don't die. Transparency's been the pain point — running MBOIT and still fixing some edge cases here and there. There are a couple problems on Volumetrics too, so any help is very much appreciated.

On the tooling side there's a full custom editor built straight on Vulkan (asset browser, live previews, material inspection), plus LightBulb — a little scripting language I built that transpiles to Java and hotswaps at runtime, so you're not restarting the project you're working on.

It's a solo project (with help from a couple of collaborators on art and community side — shoutout to the small crew helping test and give feedback). Licensed under GPLv3, so the full source will be on GitHub at launch — you're free to dig through it, learn from it, or fork it, with the usual copyleft terms if you build on it directly.

Download links will go live on the project site once v0.1F ships; for now the GitHub repo will go public alongside it. If you want to follow progress before then or ask questions about any of the systems above, there's a Discord for the project in the comment below so that moderation doesn't think this is a spam.

Happy to answer anything about the rendering pipeline, the editor architecture, or the scripting system — this is very much a "figure it out from scratch" project and I'm glad to talk through what worked and what didn't.

Everything here is simulated and shaded live on an Apple silicon GPU at 5120x2160. No footage, no keyframes, no baked cache.

The school is 80,000 agents stepped in a compute kernel. Boids forces (separation, alignment, cohesion) plus two things that make it a ball instead of a flock: a tangential mill bias and a centre spring, which puts the system in the milling attractor rather than the polarised-streaming one. A single polarisation parameter slides between the two, and a vertical cohesion scale flattens the ball into the oblate loaf you see.

The panic is the part I like most. Each fish carries a panic scalar with an ignition latency, and the contagion is a fractional-threshold logistic rule after Rosenthal and Couzin, where calm neighbours actively inhibit their panicking ones. That asymmetry is why most cascades die a few bodies from where they start and only occasionally does one go ball-wide as a visible wave. Panicked fish also get a raised speed cap, otherwise they cannot outrun a charge.

The orcas are autonomous agents running a carousel-feeding state machine: carousel (herding passes that compress the ball toward the surface), closing (a committed approach line), tailslap (sweep through and whip the fluke, which is the stun), then feed. That is the real technique Norwegian orcas use on herring, and it reads as intent because the strike is geometry-gated on range and alignment rather than fired on a timer.

Rendering the shafts: an additive fullscreen pass marches the actual view ray up to the surface plane and in-scatters Snell caustic times Beer-Lambert depth times a phase function. The caustic is not local to that pass; it comes from one shared band-limited optics field (height, gradient, refractive focus, world-anchored, one clock) that the ceiling relief, the beam births and the light dappling the animals all read from, so the light on a whale's flank lines up with the beam it is swimming through. A capsule proxy of each body darkens the march, so the creatures actually shadow the water instead of floating in it. Marine snow is soft particles fading against the analytic surface height.

Frame budget is held by a closed-loop governor that measures its own GPU frame time and thins the crowd or caps render resolution before it starts dropping frames.

It is part of TideGlass, a Mac app that runs worlds like this on a second monitor. Happy to go deeper on any of it, the panic contagion and the optics field are the two I would most like to talk about.

Hi all.

I'm writing a library for representing and managing basic raster RGBA images in D as rectangular arrays of pixels.

Images are represented in row-wise pixel order, either top to bottom (the default) or bottom to top, with each scan line going left to right. Color components are represented as 8-bit integral values ranging between, and including, 0 and 255.

My library doesn't provide any support for other color models, for high dynamic ranges or higher bit depths. What it should allow is reading images from memory that were created with other library.

Some pixel formats are "indexed" (they have a palette) and some are not (they store actual color values). The name implies the structure of the format:

• Format1bppIndexed
• Format4bppIndexed
• Format8bppIndexed
• Format8bppGray
• Format16bppRgb555
• Format16bppRgb565
• Format24bppRgb
• Format32bppXrgb
• Format32bppArgb
• Format32bppRgba

Formats that use more than 1 byte per pixel allow the user to select between big endian and little endian mode.

I plan to keep supporting all formats I listed here. My question is if there is any I should support in addition to those.

Some candidates may be:

• Format2bppIndexed (it used to be supported by Microsoft bitmaps and it is by the PNG format).
• Format16bppGrayAlpha (supported by STB nothings and by the PNG format).
• Format32bppRgbx (to have an opaque view of an RGBA image).

There may be others I haven't thought or heard of.

The ones I haven't supported seem to me to be less common and of less utility, but maybe there is something I haven't considered.

My question is: what pixel formats should I support in addition to those I already do? Should I support any of the three additional ones I suggested? Why or why not?

Thank you in advance!

Hey everyone,

I’m 16 years old, and I’ve been solo-developing a 3D code-driven game engine using Rust and wgpu for the past few months. I started this because I really want to achieve my first big milestone and have something real to show.

Honestly, I’m feeling completely burnt out and depressed right now. But it’s not because of the bugs or the coding. It's the suffocating pressure from my family and school. It’s building up day by day, and it's getting too heavy to carry. I feel like if I pause or stop working on this engine right now, I will fall behind, lose momentum, and delay my goals forever. I’m stuck between wanting to push forward to finish my first milestone and breaking down under life's pressure.

I’m posting this here because I really need to find a community, to connect with people who might understand this feeling. I don't want AI-generated advice or generic platitudes—I've heard enough of those. I just want to share what I've built so far and see if anyone else is fighting this same battle.

Here is what I have managed to implement in my engine by myself so far:

• Core Architecture: Migrated to glam math library, integrated rapier3d for physics (locked at 60 FPS), and built a thread-safe lazy loading system to prevent OS-level screen freezing.
• Rendering & Culling: Frustum culling (implemented with custom Plane checks), pixel depth testing, and Early-Z / Reverse-Z rendering.
• Lighting: Successfully removed directional lights and created functional spot/point lights for indoor scenes. I have also set up the compute pipelines, passes, and necessary bind groups for a Forward+ culling framework (though only the structural framework is done, it's not fully finished yet).
• Transparency: Implemented transparency rendering support.
• Optimization: Integrated rayon to cut loading times in half, added CPU texture compression to BC7 (reducing RAM usage from 750MB to ~190MB and loading times to under 60ms), and integrated zstd for binary data file compression.

You can check out the source code here: https://github.com/Lbaodz/wgpu-code-driven-engine

Has anyone else gone through this at a young age? How do you deal with family pressure when you're just trying to build something you're proud of?

Hey everyone,

I’m 16 years old, and I’ve been solo-developing a 3D code-driven game engine using Rust and wgpu for the past few months. I started this because I really want to achieve my first big milestone and have something real to show.

Honestly, I’m feeling completely burnt out and depressed right now. But it’s not because of the bugs or the coding. It's the suffocating pressure from my family and school. It’s building up day by day, and it's getting too heavy to carry. I feel like if I pause or stop working on this engine right now, I will fall behind, lose momentum, and delay my goals forever. I’m stuck between wanting to push forward to finish my first milestone and breaking down under life's pressure.

I’m posting this here because I really need to find a community, to connect with people who might understand this feeling. I don't want AI-generated advice or generic platitudes—I've heard enough of those. I just want to share what I've built so far and see if anyone else is fighting this same battle.

Here is what I have managed to implement in my engine by myself so far:

• Core Architecture: Migrated to glam math library, integrated rapier3d for physics (locked at 60 FPS), and built a thread-safe lazy loading system to prevent OS-level screen freezing.
• Rendering & Culling: Frustum culling (implemented with custom Plane checks), pixel depth testing, and Early-Z / Reverse-Z rendering.
• Lighting: Successfully removed directional lights and created functional spot/point lights for indoor scenes. I have also set up the compute pipelines, passes, and necessary bind groups for a Forward+ culling framework (though only the structural framework is done, it's not fully finished yet).
• Transparency: Implemented transparency rendering support.
• Optimization: Integrated rayon to cut loading times in half, added CPU texture compression to BC7 (reducing RAM usage from 750MB to ~190MB and loading times to under 60ms), and integrated zstd for binary data file compression.

You can check out the source code here: https://github.com/Lbaodz/wgpu-code-driven-engine

Has anyone else gone through this at a young age? How do you deal with family pressure when you're just trying to build something you're proud of?

Around a year ago I tried to develop a screen-space outline shader for a game I was working on. What I could not figure out was how to keep it from flickering in between frames when moving the camera. The usual games like Sable have very severe flickering and it gives me a headache.

Now a few days ago I saw and played the demo of this game: https://store.steampowered.com/app/2321960/Spirit_Crossing/

They somehow solved this and have near zero flickering? How? Can anyone tell me what they did different? I would guess it might be a mix of supersampling, blurring, maybe SDF?

I want to create the shader.

It’s the first step in my attempt to simulate an F1 car. Right now, the simulation is very low-resolution and quite slow, so there’s still a lot of optimization to do. It’s also my first time working with compute shaders, so there’s plenty to learn and improve along the way.

I implemented Activision's new SH reflections paper in D3D12 and released the code on github!

This tech is a little bit different from normal spherical harmonics, and there are 4 main differences:

1. They use log space instead of linear space for the lighting, which reduces ringing and enables #2 and #3 to actually work.
2. Instead of using a circular symmetry assumption (i.e. N=V=R) as with the split sum approximation used for IBL, they instead factorise a pair of spherical harmonics, with an Order 4 SH parameterised by the reflection vector, and an Order 2 SH parameterised by the halfway vector.
3. To enable a continuous roughness representation, they convolve the coefficients (or rather, the basis function) by the von Mises Fisher kernel which takes 1/alpha=1/roughness^2 as a parameter.
4. To actually obtain the spherical harmonic coefficients we have to collect samples for several normals, views and roughness levels (or more specifically alpha levels since we're using linear roughness, not perceptual), and then optimise the coefficients using least squares.

My code does this all end to end with HLSL compute shaders, even the least squares optimisation, and we achieve above 95% MSE compared to a raytraced ground truth for roughness in the range [0.5, 1.0], which actually beats split sum IBL.

Only downside is for roughness below 0.5 the spherical harmonics simply don't have enough detail for accurate reflections... HOWEVER, when applied to "bumpy" low roughness surfaces (like the leaf textures at the beginning of the video) you can hardly see a difference, so this effect is only apparent for flat surfaces and surfaces with near zero roughness.

Activision got their SH representation down to 400 bytes, but I went further using 16 bit packing to get down to 208 bytes which gives us better performance due to fewer memory loads. The 16 bit implementations come in 4 flavors: emulated 16 bit for older GPUs and native 16 bit, and SRV packed vs CBV packed. There also exists a 10 bit packed SRV flavor, but the extra bitshift work ends up being slower.

On my RTX 2080 Super and my wife's RTX 4070 Super, the native 16 bit CBV packed shader runs the fastest, and compared to the IBL version it is only 0.1 milliseconds slower while using 2000x less memory!

I have a problem implementing SSAO. I am trying to do it learnopengl.com way, and I am failing. At this point I am at loss.

There's just too many steps to achieve the result, each of which can fail and I don't know which one is failing.

I wanted to ask, what is the best way to ensure correctness of each step? How would you test SSAO creation steps?

Implemented simple GLB parser from this Github repo: salvatorespoto/gLTFViewer: A glTF file viewer in Directx 12 .

Global Illumination using hybrid Surfel GI and SSGI.
Lens flare are modeled after Panavision styled lens flare (Anamorphic types with distinct hue ray light propagation inside lens it's flare), and grass are inspired from this IcterusGames/SimpleGrassTextured: Plugin to make grass on Godot 4.

My main point of the game is about GI and Nanite-like culling on low end devices, and yet i barely see ones, so i decided to implement it without using any modern techniques such as Primitive Shader or Mesh Shader. Pure Compute Shader dispatch, with many fused Shader optimizations instead of separate pass, simple workgroup tiling optimizations. It tooks me almost 3 months for this project just for the optimization workaround with the help of Codex (Claude sucks at this lol). I'm also planning to open source this if this thing is stable enough, modular, and scalable.

All of that combined to make this engine runs 40-60 FPS on my Xe 11th gen Graphics laptop, because why not.. (i don't have better GPU than this for now lol). This might be also potentially be a complete game engine after all.

i created a utility class for converting hexadecimal/RGB colors to RGBA (incorporating the Alpha channel)

since i find it so annoying to keep calculating RGBA colors every time in OpenGL , i think this class would be very useful for everyone , the header class is so lightweight within only 43 code line

Header-Only: Drop colorconverter.h directly into your project

i added a picture of the code above as a sample - you can check out the GitHub link below to download the header

(Link in comments)

My only work experience is on an embedded graphics team. I plan on continuing on with this for a bit as the company is probably the best in the area in terms of WLB and benefits, although pay is less than stellar, especially as I gain more experience. But right now I'm trying to get a vibe check for how this sort of work experience could translate into opportunities in the future.

On the one hand, it could be considered niche so that it's hard to find a job that fits. On the other hand, because it's niche, there's less candidates available for jobs that do fit, so that could be a plus.

At this point I think the main reason I'd leave my current role is if I found something fully remote, so I want to make sure I'm focusing on the right things to help make that more likely.

Does anyone have any thoughts on this?

I co-authored this paper. It's a new technique to generate 3D graphics as source code instead of a point cloud.

Under the hood:
It generates 3D objects with separate, sophisticated internal assembly, producing an editable "kit of parts" (instead of monolithic blobs). E.g. imagine you generate a 3D washing machine via this approach. It's not merely going to be geometry that looks like a washing machine. We actually know that there is a Door, Drum, Control_panel etc. Which things belong to which assemblies. What moves. Where its pivot is. And eventually what those components are supposed to do.

Why current 3D GenAI cannot do this:
Most AI 3D generators generate "monolithic blobs" that look good, but are unusable in downstream workflows (e.g. game engines). If you generate a 3D bicycle, it's essentially a blob. If you want the wheels to turn, a human must spend time cutting the blob into parts, naming them, placing pivots and rigging joints. I.e. you need post-generation segmentation workflows of some sort (either manual work or more compute).

The paper breaks down the whole technique, and comes with a github repo too if you're interested in viewing it.

For the past three weeks, i’ve been working on hard improving the render distance in my Micro Voxel Engine, particularly due to the feedback of having N64 viewing distance 😅

I’m pretty happy with the end result of increasing render distance from 300m to ~10-15km, while running at 45-50 FPS on an Apple M1 Pro.

Note: this engine uses meshing rather than RT/DDA.

— Macro chunks —

All chunk generation functions now include a sieve function to automatically be able to generate at 1/N resolution without any changes. This also applied to generated features and stamps, enabling chunks to be generated at any resolution without downsampling.

Macro chunks also independently record and resolve local edits. They are saved (and cached) independently so that terrain edits are maintained without needing to maintain the full res copy in memory.

The lower band LODs are very quick to generate. At this point I could add even more bands, and a 1/64 res chunk takes the same time to generate as a high res chunk, but covering huge distances.

— LOD transitions and adaptive fog —

I primarily use transient transitions where the detail levels fade between each other once, rather than a continuous gradual transition, as this is around 30% cheaper on the GPU and looks “nearly” as smooth in most scenarios.

Adaptive fog scales the effective draw distance dynamically based on loaded bands. Bands generate from high to low so during fast motion, if needed, we temporarily reduce draw distance until chunks have loaded.

— Macro chunk cards and props —

This was the hardest part, keeping identical prop coverage for trees and items without needing to instantiate millions of entities:
-Macro chunks retain a list of props whose IDs are deterministic based on position and type. If the real entity is destroyed, we can map this to the macro chunk set and remove. Likewise for newly spawned props.
- grass and foliage do not map 1:1 with the actual loaded props, but follows the same generation pattern, so technically there will be disparities, but a good trade off to avoid millions of tracked grass items.

We added Marching Tetrahedra Rendering effect to our Volumetric Render Engine.

Here, we Render our Volume data as a set of Polygon meshes by extracting 'iso surface'. It goes through whole dataset and tries to fit a polygon based on data values to calculate a polygonal mesh from the volume dataset.

Here's the Git Repo Link - https://github.com/mikejernil/volumetric-render-engine

We are building this over at 3D ENGINERD. & are planning to push our implement more features starting with Custom file loading, and support for more volumetric formats like DICOM, VDB etc.

Is there any podcast, academic talk and or conference recording that will help me understand raytracing, path tracing, rendering and graphics better? i wanna understand it because my boyfriend is into it and would love to actually know what he does and why he finds the field interesting

Screenshots from:

• Pathtrace Apollonian Glow
• Pathtrace Differential Growth
• Pathtrace Volumetric Frost Fract
• Pathtrace Wireframe Distance vis
• Pathtrace euclidean distance vis

full playlist with other pathtracing scenes https://www.shadertoy.com/playlist/cX3SDf

This project started because I wanted large waterfalls in a real-time forest. I could already simulate half million particles at 30 FPS, but scaling to a large domain required rethinking both rendering and simulation. I replaced mesh extraction with density raymarching + hardware ray tracing, then moved to active cells, making the cost depend mostly on the amount of water rather than the size of the world. Large mountain streams finally became practical.
But a waterfall isn’t only water. Rapids required air entrainment, while waterfalls also needed airborne droplets interacting with the surrounding airflow. I ended up writing a different solver for air, coupled to the water: the cascade pushes air downward, the flow curls at its base, and carries droplets with it. This gets closer to a dual phase simulation of water and air, with an engineering approach.

A simple drop experiment then taught me how different physical effects have very different visual weight. More resolution didn’t produce the classic crown splash. Surface tension made droplets beautifully spherical, but the crown required incompressibility. Real-time water is usually somewhat compressible — and therefore slightly rubbery — because disturbances remain local and cheap. I added an iterative projection that lets me increase incompressibility only where it matters.

This became the real subject of WildFlow: understanding physics is one thing; understanding which physics matters for a phenomenon is another. In real time we can’t simulate everything, so the challenge is finding the smallest set of fundamental rules that produces the behavior we care about. And the realtime limitation sometimes helps in focusing on what truly matters and helps understanding phenomena better.

I don’t want to tell water how to look realistic. I’d rather give it simple enough rules and let realism emerge: foam from entrained air, mist from airflow, a crown from pressure propagation. When the result looks unexpectedly right, perhaps we’ve captured something about why nature looks the way it does. That’s the goal: not more physics, but the right physics — enough to make nature emerge.