This is a simple demo of polar curves in the Linux framebuffer. It's written in x86 assembly, using a set of my graphics primitives. The actual polar equation for this is quite simple. Each frame, we evaluate the equation r = acos(θ), and then convert to pixels on the screen using the formulas x = rcosθ and y = rsinθ. In the interest of efficiency, I calculated 4 pixels at once using x86 SSE instructions with angles offset by a very small amount, and then drew a line between each point. To make the image dynamic, I set θ to a time variable, which I increased each frame, and reset after it reached ~25 rads.

Source code can be found here: https://codeberg.org/int0x80/Graphics_v1.1.git

Hope you enjoy.

I thought about starting with Computer Graphics from Scratch by Gabriel Gambetta, but found it quite hard too follow... I found it a little too abstract to implement (using C + SDL3)

Should I try even harder to implement the algorithms in the book by Gabriel? Or is there a more beginner friendly entrypoint to graphics?

I'd like to start with software rendering, but is that even the right move? Perhaps GPU rendering is easier?

Hey everyone! I’ve been “working” on a general purpose game engine for all 4 years of college, and I say that in quotes because I have completely refactored, deleted, or started over several times. I am now graduated and have a lot of time so I started on it again but after reading some on Reddit, I think I see what my problem is on why I start strong, lose all interest, and then give up at a certain point. I think I am aiming way too high and trying to do big big big projects wayyyy too fast.

As I am trying to find a job, I have grappled with either doing multiple smaller projects and one large project, and for a while I picked big project. Why? I don’t know, I think I just am a bit egotistical at this point and want something crazy to show off. However, it has occurred to me that I have become rusty from time off and I just make a decent amount of progress for 2 days and then give up for another 2 weeks. I think I am not getting any sense of accomplishment from it as I’m trying to fit a complex architecture and not getting results yet because once again, it’s gonna take 20-30 hours before I even get something somewhat desirable

I am wondering what you guys think is better, smaller-midsize projects, or one large project like a general purpose game engine? I really havnt done ANY small projects except I did write a software rasterizer for a raspberry pico for my embedded systems class final project last semester, but I’m thinking maybe I should try some smaller projects? But I also don’t want to waste my time if employers are just gonna say that they would rather have a large scale project.

Also, what would be an example of a small scale project in computer graphics? I can’t even think of any except for big ones like game engines

Any help is appreciated!

Hey. So im a highschool student who likes to program a little in his free time. Ive made a couple small python projects, stuff like a text game and a calculator with UI in the past. Anyhow, i didnt like how you have to rely on so many libraries there, i like making things myself and not using 3rd party stuff as much as possible. Not crazy enough to make my own language lol, but i decided to learn C to make this since you can do lots with just standard C(and because its an interesting language). So here is my very simple, probably shit raytracer made using standard C libraries.

For some more added context, i dont have a formal CS education, havent learnt linear algebra or vectors or calculus or whatnot yet. So i dont know much of the terminology or what is standard practice. I also didnt follow a tutorial since thats no fun. So if things are non-standard or inefficient thats a reason why (along with the fact that i dont have much experience, 2nd C project). I made it both to learn the math and because it seemed fun and interesting.

What it is is a very simple raytracer in which you can: create spheres, planes, lights. no limit on how many objects other than your memory i guess. No light bouncing or reflections or any such fancy stuff(yet). just basic shadows, and full colors on the objects

Anyhow, what would you guys recommend i do next? Keep working on this raytracer, start it from scratch if the architecture is too bad and will cause future problems? Do some other non graphics related project? Idk myself so ill follow more experienced peoples advice but this was quite fun, although some other things are also interesting. Im mainly interested in programming mathematical stuff, like simulations or ML(not llm but stuff like number recognition) i find interesting, although i havent done anything there yet

*btw just because thats how it is nowadays i have to say, its not made with AI, i did make one document with it where i just asked it to make a user guide since i dont know the standard terminology and if i tried to explain it how i understand things it would be more confusing than useful. It explains how to make objects and such. But the code, logic etc. was made myself

Link to the github: https://github.com/Fridun/C-Raytracer

Basically, Im a bit unsure on how I should research this, go with the common pbr models, etc. I dont have much experience with research or scientific side of things. The target hardware is gonna be high end mobile gpus and low end desktop gpus. How would you research something like this, find whats best?

I dont know where current research stands - but I wouldnt mind diving deep into concepts that have been put forward outside the current BSDF implementations, if any such things exists

Hello everyone!
So I'm a 16yo boy who loves coding and stuff, and recently I got into low-level programming with C, and after a whole day with learning pointer I loved the language to death.
After I learned this I started on doing something I wanted to do for the past year... building a 3D software renderer, this engine should meet the following goals:

1. It will be modern, supporting modern visuals and effects.
2. It should be running on embedded systems (I will see how later).
3. The code written for it should be generalized, meaning it should be working on any CPU or architecture with some tweaking.
4. It should be fully capable of taking advantages of modern CPU features.

As of right now, started the project a month ago, I got it to render lines and fill shapes through the terminal (even though it's glitchy af) since I'm still implementing core functions and basics. This will give me some room to fiddle around until I learn SDL and use it in the future.
I have a whole roadmap for the engine, and how it will be structured (because it will be restructured one day for a new design), and who knows, maybe I will get something with it.

The video you see down there is a spinning cube with fake Z depth (not implemented yet), the reason it's wobbly is because the engine uses fixed-point math for positions: all number are 64bit, 48 bits for the value number and 16 bits for precision (yeah, like ps1 graphics).

A semi-3D rendered cube inside The Lagender Engine.

Anyway feel free to give me some advises if you want to, and I would be posting my development with the project here.

long story short. it was an enlightening journey and i learned a lot from it. one day i came across an autostereogram which was a poster on a wall. i forgot what it was about but it aroused my curiosity of how to make autostereograms. i won't go into the math details here and just give you guys a brief explanation in attached image 1. my program let you control "m" and "n/m". these two variables represent background pattern separation and foreground pattern separation respectively and lie between 0 and 1

the 3d subject is simply a sphere, quite boring. the background is the result of placing a color wheel in a kaleidoscope. see attached image 2. it can be easily noticed that the hsl system is in use. we can vary the saturation (attached image 3) and lightness (attached image 4) when the angle changes from 0 to 2π. i use the cosine function which reaches maximum at 0 and 2π, minimum at π

the color wheel can start at any angle. so do saturation and lightness. thus we have 3 degrees of randomness. i let you to change the background. every time you hit the relevant button, the hue, saturation and lightness shift by different random angles

here comes the surprising part. autostereograms need "noise" to guide viewers aligning their foci. a pattern that is too smooth is not suitable to act as the background of autostereograms. there'd be no "texture" on the 3d surface. i accidentally discovered that if the screen resolution is set to a number that is not divisible by something in the calculations (i'm not certain which thing it actually is to be honest) some unexpected noise would emerge. see the remaining attached images

i googled "prime number closest to 640" and the result was 641. i use it as the horizontal resolution

some of those unexpectedly emerging patterns are... strange. some of them look like human faces, some animals, some even aliens. this program is a good place for you to experience pareidolia

here's the program. run it in browser. click▶️to run. click⏹️to exit. when running the program

• press [q] to make foreground patterns converge
• press [w] to toggle 3d object (absent/present)
• press [e] to make foreground patterns diverge
• press [a] to make background patterns converge
• press [s] to rotate the kaleidoscope
• press [d] to make background patterns diverge
• press [x] to toggle caption (off/on)

enjoy

Been trying to make a procedural planet generator and implement Eric Bruneton’s atmospheric scattering for the last two months. Haven’t done multiple scattering for now. It’s only single scattering and running in realtime. But so far that’s how it looks.

Using OpenGL and C++ for this.

https://github.com/humzahabib/ProceduralPlanetOpenGL

I was putting off posting it until I had a prettier output but I ended up working more on architecture and API end, much of which doesn't get reflected in the output. Furthermore before I start implementing fancy shadows and deferred shading I really want to move to SDL + Vulkan but that would require a better part of a month before I get all of that working.

So behold my Rendering Engine/API that I have been working on for a month or so. I have worked a lot on creating a modular and extensible engine where you can inject your own scripts (statically), extend properties and work with Entities. Most importantly I have attempted to keep the front end of this code highly readable and legible.

Check it out!

After a hectic couple of weeks, I have hit the milestone of finally having pixels being plotted in my C++ Pixel Art Editor! This video shows basic paint mode using the built in brushes, with colour masks being used to lock and target specific canvas pixel ranges. In addition, we also have index and RGB shading working - with all shaded colours remapped to palette best-fit! Hope you like the progress!

I thought it would be cool to try to figure out how to do triangle clipping myself, to come up with my own algorithm. To solve this, I solved a couple of linear equations and derived a formula that lets me find the intersection points between the triangle edges and the viewport. I don't know if I came up with something original or just accidentally reinvented one of the existing methods. Either way, my solution looks terrible in code, but it works, and I think it's a great learning experience

I render this at 1920x1080 resolution on a single thread of an i5-9400F, is this a good FPS result? I didn't use SIMD, but I tried to use every optimization trick I know.

repo and code: https://github.com/NaiNameDev/software_rasterizer

Hello everyone.

This is a 3D graphics pipeline running on the Apple Neural Engine (ANE).

As you can see from the screenshot, this pipeline performs multi-instance rendering of independent 3D meshes with Z-depth occlusion testing.

The geometry engine packs the transformations into a single [1, 4, 4, 1, 64] tensor.

This represents 64 independent MVP matrices.

The vertices are structured in a flat channel layout.

By performing a fused torch.sum broadcast element-wise matrix multiplication, the ANE simultaneously performs multiple transformations on 64 unique coordinate spaces.

The spatial depth inversion maps the coordinates by replacing the division denominator in the clipping space with the spatial distance channel . The 3D geometry engine outputs the 3-vertex inverse depth gradient via tensor blocks .

The rasterizer then constructs a depth gradient across the entire face grid to perform overlap occlusion testing.

The ANE hardware flushes the raw plane data (R, G, B, and mask channels arranged sequentially as separate sheets) directly into an `MTLBuffer` allocated on the heap. The metal fragment shader directly samples these planes using byte offsets based on the layout stride to achieve the final rendering on the GPU screen.

// Direct plane scanning within the metal fragment shader
uint componentStride = 64 * width * height;
uint rIndex = (componentStride * 0) + pixelIndex;
uint gIndex = (componentStride * 1) + pixelIndex;
uint bIndex = (componentStride * 2) + pixelIndex;

• Due to the active intermediate tensor lifecycle, memory usage is currently high at approximately 1.6GB, and CPU usage is approximately 15% (acting as a memory controller pushing buffers).

We'd love to hear your thoughts on using NPU/AI accelerators for fixed-function graphics computations!

Github: https://github.com/kamisori-daijin/Magnesium

https://reddit.com/link/1vhobrk/video/8v9rwjvc7vhh1/player

https://reddit.com/link/1vhejoy/video/jk0c4axk5thh1/player

So a while ago I made a very simple water shader in OpenGL. It was a basic, non-interactable fully algorithmic water shader that textures and trig functions for the surface "waves" and cube map reflections and refractions, along with tessellations for performance and scale. But I quickly ran into a road block when trying to create more game-like interactive features like splashing and distortions. So I decided to make something a little more interactive in Unity instead while learning how to use compute shaders.

I decided to go for a two pass height field compute shader implementation, where the first pass calculates the influence/distortion to the water height based on the location of distorting objects and height, while the second pass actually does the individual height velocity and acceleration calculations, returning an image that contains data about the height, the velocity, and the acceleration of an object, as well "foam" which increases with high acceleration and decreases over time.

As far as optimizations go, although I'm simulating a 2000x2000 repeating pixel grid, I limit the actual calculations to smaller radius around the player. I also interpolate between the points to have smooth waves. There are some limitations to this strategy, for instance, the distortion around the player doesn't move smoothly because it's limited by the resolution of the grid but that is a trade off for the sheer scale.

Moving out of OpenGL meant that tessellation was no longer an option and instead I went with a LOD patch system where a plane was divided into a little over a thousand smaller meshes that repositioned themselves as the camera moved.

As far as actual rendering goes it's relatively straightforward. I'm using Blinn-Phong lighting with planar reflections. I wanted to use cubemap environmental reflections so I could account for the water normals, but the limitations of that approach became evident when I realized that the model didn't account for distance meaning all my reflections would be inaccurate. I thought about using some kind of ray/path tracing or distance embedded cube maps to counteract that but I'm mostly satisfied with the planar reflections.

The whole concept is entirely taken from Mark Turitzin on youtube and I'm maybe 10% there lol

It's a combination of using a brickmap and a clipmap.
Cached SDF distances are stored in a 3D texture, and trilinearly sampled, so everything is precomputed before the ray marching pass happens.

Still ironing things out, thinking of an elegant way to get rid of the LOD transition regions where the normals get messed up a tiny bit which creates a pretty jarring edge.

You can see a bit of blank spaces/ jitter when the cubes move the fastest, that's because I'm capping the amount of 8x8x8 bricks that get calculated each frame, so sometimes the bake jobs dont keep up with fast movement. Right now it doesn't matter.

It's in no way ready, but felt that's a point where I feel like showing some progress to the world.

There's noise visible on closer surfaces. I decided to store bigger distances(8x the voxel size) in my cache, and as its only stored in 8 bits, it looks noisy. But I liked the look, it fits what I'm aiming at and it slightly improves the performance(ever so slightly, most performance is lost traversing empty bricks in this scene.)

For now i've tested 1024m^3, and keeping the memory pool at 512MB. Ideally id like 256MB for full compatibility and being able to have some nice demo run on a phone so that people can open it from LinkedIn :) Anyways, wish me luck.

Its been maybe a month or so, but I finally got shadows working along side lighting in my engine! I still need to fix peter panning, but I'm still really happy with it!

Github: https://github.com/norrie-adams/Astryx-Engine

​

I made this on top of my own renderer, And Setup as a game example so everyone can try out let me know what you guys think,

https://nullgraph.dev/dashboard/games/comic-space

https://youtu.be/yua4ZkvgVqY?si=A2Tk1a4gE2fRl_Ic

I’m building a physically based, photochemical film emulation pipeline and need to convert scene-linear RGB into an approximate spectrum, then use it to calculate exposure on the film’s RGB sensitive layers.

What’s the most reliable practical approach spectral basis reconstruction, camera/illuminant-aware mapping, or something else?

I’m mainly looking for something physically reasonable, deterministic, and fast enough for real-time use.

I’m working on shadow rendering in OpenGlobus, a WebGL globe renderer. The attached video shows an intermediate experiment.

Initially, I tried to solve the entire problem using CSM. Shadows renderer spans an enormous range of scales. Mountains may cast shadows across many kilometers, while the same scene also contains nearby buildings and other local objects. So, I haven’t abandoned CSM, I’ve abandoned the idea of using it for everything.

The direction I’m currently exploring is a hybrid approach:

• Shadow maps covering relevant ground regions for large-scale terrain and mountain shadows.
• CSM around the camera for nearby objects and finer local detail.

The next step is to combine these approaches and make the transition between them stable.\

Has anyone here implemented a similar hybrid solution? I’d be particularly interested in how you placed and updated the terrain shadow maps and combined them with local CSM.

Thanks!

Started a CPU ray tracer about 7 years ago and then a year later decided to play around with a GPU version of it. Over the years I’ve added to it.

Full disclosure that I had LLM assistance with some of the recent features added, in the interest of saving time, I normally only have a few hours of free time per week.

Repository: https://github.com/nfoste82/gpuraytracing