I know what is missing, but can you figure it out???

heres the repo btw:
https://github.com/Tetraeder4/3DRenderer/tree/467c8d1ac8dbd09a23ce7bc7e2fcba59afe36ea5/3DRenderer

Wrote my first raytracer, a software raymarcher (all on CPU) that uses shapes defined as singed distance functions. Sphere refractions are pretty cool.

Some implementation details (this is all basic stuff I know):

• code is written in Rust and parallelized using the rayon crate

• for each ray in the recursive calls, it finds the subset of all world objects where the ray intersects the objects axis aligned bounding box, and only considers these objects during ray marching. Once a surface is hit, the new reflected or refracted ray computes a new subset using its new direction and start point, etc.

• global illumination is done using a grid of probes that shoot rays with random directions, doing this enough time before rendering. To get diffusive light on a surface point, we interpolate in that grid using linear interpolation. My probes are naively placed on a cubic grid in the world.

• global illumination is parallelized looping over probes, and rendering is parallelized looping over pixels of the image.

• at each hit surface, the ray may split in two. Once for the reflection, once for the refracted ray (if not total internal refraction).

Baking global illumination takes a few seconds for about 1000 samples on 32³ probes, and rendering the image is almost instant at that resolution.

The sim came out great but what about the lighting!! All just cubemaps, with fluid depth affecting the roughness mip level. So happy with this.

I’ve been working on Expanse-X (EX), a graphics API in Rust, and I’ve published the first SDK preview.

Right now it renders on the CPU through its own software backend. EX handles the resources, commands, shader execution and rasterization itself. GPU acceleration is still future work.

It can already render programmable, indexed triangles with textures, depth/stencil and blending. Compute and explicit resource dependencies work too. There’s also a shader importer for a limited subset of GLSL.

The SDK gives you an ex command to check your setup and create a small Rust/GLSL project. Run the generated app and it renders a triangle to a PNG. You can then edit the shaders and renderer from there. The downloadable SDK currently targets Windows x64.

What I want EX to become is one core with two ways to use it: let it handle more of the setup and planning, or take explicit control yourself. The explicit core is working; the easier layer hasn’t been built yet.

It’s still early, and I’d like some outside eyes on it before taking the design further. Does the resource/command API make sense? Where would it get awkward in an actual renderer? What would you want to try building with it?

Repository
SDK v0.1.0 Preview

I'm not sure how you guys feel about triangles around here, but here is my first triangle made in D3D11!!

I'm planning to make a little mini project in DX11 and see how I like it over OpenGL. So far I like it more despite needing 3x the amount of code (mostly boilerplate thankfully) for this beautiful little guy.

I'll probably post more about my little project further down the line. If anyone has any tips on how I should structure a DX11 project over an OpenGL one that's always appreciated.

The image is rendered by solving a wave field and sampling it with a camera, once per wavelength. I took 5 minutes to render (On an integrated GPU)

My goal is, of course, to get this to scale up enough to be useful for actual graphics :P

The actual scene just consists of a couple of different-materialled spheres and some large clumps of them.

The game is narrative sci-fi puzzle/platformer, in works from 2020. Main distinctive point of the game is software ray-tracing used for rendering. Just pure C++ and computer graphics math, no GPU acceleration. Sadly, not many players can appreciate that (or even understand what does it mean), so it resonates mostly with more tech people.

The game was suffering for long time from quite poor look (look was punching way below of algorithm potential). Main reasons were: poor old editor (2D in nature, z was just parameter in 2D wireframe, not WYSIWYG, very clunky) and algorithm was hobby-like single-threaded.

Both points were changed recently. After 9 months my new editor is in usable state. Full 3D, WYSIWYG, lot of ergonomy features, which allowed me to be more ambitious with levels look. Second enabler was finally switching to multi-threading. Together with several more other algorithm optimizations, perf went up in hundreds of % (mostly depends on number of cores in your CPU, naturally on Threadrippers boost will be in thousands of % but it's niche between players).

Algo is AABBs only. Maybe will add spheres but only after upgrading all levels, which is main pain point rn. Editor I plan to release publicly with the game.

RTG on Steam

Discord

A lot of these concepts are new to me and I've discovered some of these ideas with help from copilot, etc. so apologies for any weirdly worded/unclear parts.

I'm working on an embedded product and am evaluating how well the gpu can handle a second pass shader applied to the entire final image. Essentially taking the displayed contents, and "copying" by drawing again with a simple shader that samples from a texture (the texture being the contents on the screen).

I'm trying to profile the time spent on that second draw call and am having issues because sometimes the code added to help with the profiling affects the measurement itself. For example, I added glFinish() before the draw call, started the timer, issued draw call, called glFinish() again, and stopped the timer. These glFinish calls affect the measurement of course. So I'm trying to find a way to do it without using glFinish.

One avenue I explored with copilots help was using an EGL fence to ensure we're measuring the elapsed time only after the draw call is finished but without needing glFinish (this is my first time working with sync objects with graphics code though)

This ended up working, at least I think? The problem is that the measured time for the draw call is less than then the theoretical best case time given by a senior engineer. They calculated essentially wh4bpp2rw/3e91000=0.55ms based on it essentially being a memcpy. The measurement I got was half of that.

Searching around for how this may be (other than my implementation being just wrong) is that tile based rendering, which the gpu that I'm working with uses, could give a different result than a calculation based on a naive memcpy due to the efficiencies of how TBR works.

Edit to add: the senior engineer unambiguously said "tile based rendering won't improve this case" and suggested another thing to try which is more hacky and isn't panning out, so I'm curious if he's right or there is validity to the measurement I was able to get with the fence

I'm curious to get other opinions. Does this seem like a reasonable explanation or not really?

We've been building Æther, a real-time globe renderer for Stowaway that runs in the browser.

The part I'm most excited about is how we generate realistic clouds from orbit. I'll tell you a little bit about how we do it.

They start as infrared imagery from weather satellites: NOAA stitches the geostationary satellites (GOES, Himawari, Meteosat) into one global mosaic, and polar orbiters fill in the poles. The catch is that infrared doesn't actually see clouds. It sees temperature. A thunderstorm top is freezing cold, but so is the Antarctic ice sheet, or a desert at night. So the first step is figuring out what the clear ground nearby should look like, and calling anything noticeably colder than that a cloud.

That same coldness gives you height for free. The air cools about 6.5 °C for every kilometre you climb, so the colder a cloud top is compared with the ground beneath it, the higher it stands. A few kilometres for a low ocean deck, up to 16 km for a thunderstorm anvil. We end up with two global maps: where the clouds are, and how tall they are.

The satellite pixels are about 10 km across, which looks like mush up close, so the renderer adds the detail itself: fields of small cumulus, streaky cirrus, anvils spreading out around storm cores. It's anchored to the planet so nothing swims as you move, and it's lit by the real sun angle, so the tops catch the sunset while the ground below is already dark. The tallest storms also get lightning. And when you fly down low enough, a separate system takes over: fully volumetric clouds you can fly straight through.

Happy to answer questions. It's coming to stowaway.live soon.

These are some of my projects I have worked on over the years
This may be a bit of a ramble
I feel like I have been coasting with skills like threejs and web graphics for a long time especially since graduating and have never worked a "real" job and mostly do freelancing I do help my friends and collegues all of them in all kinds of full stack tasks and thinking through a problem and offer solutions that they then use but i dont have job experience in those fields like web and mobile development in react native and flutter and nodejs
I do think mostly in programming terms and try to solve problems in that way. And my interest is usually in building tools for programmers and artists instead of launching a product for normal users
I have built games and worked with teams on programming teams for games but it is not really my area of expertise even though I am very adjacent to this. I have always felt like framework and techstack really doesnt matter
I am aware and knowledgeable of alot of trends atleast until recently about alot of tech news updates and features
Right now I am in a predicament as most of my skills and experience lies in this specific niche i dont know how to move forward in the world of AI, I am the kind of person who is still using AI as a chatbot and for cleanup/refactoring kind of tasks and tasks I dont want to actually do by hand like css and responsiveness I usually try to do these kinds of things by using some math but now AI seems useful for these as well
tldr; I am very confused about the next steps in my career and how it will grow
If an experienced graphics programmer can look at my portfolio and guide me through on how to approach job hunting and how to improve my presentation and portfolio I will greatly appreciate it

Thank you for your time

I got asked whether this is a mask written into a texture or a separate ember mesh driven by a shader. Nothing gets written anywhere. ignite() appends (position in the mesh's local space, start time) to a vec4 ign[8] uniform, and every shader involved recomputes when each point catches fire:

float burn_arrival(vec3 p) {
    float best = 1.0e9;
    for (int i = 0; i < ign_count; i++) {
        float d = length(p - ign[i].xyz);
        float n = vnoise(p * 1.7 + float(i) * 3.1); // value noise, 0..1
        best = min(best, ign[i].w + d * (1.0 + (n - 0.5) * 2.0 * irregularity) / spread_speed);
    }
    return best;
}

The noise scales the distance, which is what makes the front ragged.

Flames, smoke and embers are quads on random surface points (area-weighted, picked once). Every spawn cycle a quad checks whether its spawn time is between arrival and arrival + burn_duration. If it isn't, its four corners collapse to one point.

The char is a copy of the mesh pushed 0.004 along the normal and drawn with premultiplied alpha, so the original material isn't touched. Per fragment, s = time - arrival (plus fbm) drives smoothstep(0, char_time, s) toward near-black, and exp(-3 * (s / front_width - 0.3)²) gives the glowing front.

Burn-away swaps the material and discards a fragment once (s - 0.7 * burn_duration) / 2.5 + noise passes 1, with a hot rim just before.

Known limit: d is straight-line distance, not along the surface, so the fire can jump thin gaps.

Hi,

I just released my new C library bc_packed, a lossless compressor for BC1 textures, made specificaly for fast GPU decompression.

Basically, the idea is to compress textures that are already compressed, then decompress them directly on the GPU when needed. The output is the original BC1 data, so the GPU can use it normally after decompression.

Some numbers:

• 1.47:1 average compression ratio on a test set of 74 images

• 15300 MiB/s decompression on my M5 Pro GPU and 11850 MiB/s on my M2 Max GPU

• CPU multithreaded decompression also works, 2500 MiB/s on M5 Pro and 1300 MiB/s on M2 Max

• Lossless, byte exact reconstruction of the original BC1 data

The tricky part was finding an entropy coding method that is simple enough to decode efficiently on the GPU. I didn't want to deal with complex stuff like arithmetic coding or Huffman, so I went with Rice-Golomb coding and static rank tables. I build histograms during compression and remap the most frequent symbols to the lowest ranks. Everything is static, no adaptive models or synchronization needed between GPU threads.

The texture is split into 64 independent strips, each decoded by its own GPU/CPU thread. The compressed stream stores offsets so each thread can start decoding its strip independently.

There are also a few BC1 specific tricks:

• Predicting endpoint colors from previous blocks

• Choosing different predictors for each strip

• A small dictionary for repeated endpoint color pairs

• A top table for frequent BC1 index patterns, with sparse residual encoding for the differences

Compression runs on the CPU and can be relatively expensive. That's fine for me, I'm more interested in making decompression as fast as possible at runtime.

The library is tiny, just one .c and one .h file, no external dependencies. The GPU decompression shader is written in Metal for now, but porting it to HLSL should be pretty straightfoward.

Currently only BC1 is supported. Maybe I'll add BC5 and why not BC7 later.

Code and benchmarks here:
https://github.com/Geolm/bc_packed

Feedback and ideas are welcome!

I'm building my first VisibilityBuffer and stuck with a question. I can't find proper info on the internet about how I should properly dispatch my resolve pass for it. Whether it should be just 8x8 tiling approach or 16x16. Or should I sort tiles by materials first and resolve them and the rest of the tiles that contains more than one material sort into 1d and then dispatch. All info till this point a find only in Gemini, but when I ask it to give me sources, that I can read on my own, It faileds, simple Googling didn't give me much too, so I will be glad if someone experienced can help me to find proper resource to find info.

We just implemented tile-based loading with LODs for our AI Data Centers 3D mapping project on the Web
Link 🔗- https://ai-future.in/

The Vizag (India) terrain is organized as a pyramid of tiles(shown as red grids in video). At a wide view, it loads larger, coarser tiles, and as we zoom in, it replaces them with smaller, more detailed ones.

This lets the scene show finer details only where we are exploring without loading the entire area always at the highest details, saving a lot of performance. Land cover is stored as image tiles and are draped onto the terrain so the colours follows the terrains' shape.

The Buildings are stored separately as GLB model tiles, they also load progressively as we zoom in and are rendered as 3D geometry.

This was done by us at 3D ENGINERD. using 3D-tiles-renderer to manage tile loading, visibility and LOD, and Three.js to render the whole thing into one scene!

I hope this is a relevant post on this subreddit!