The recent stipplings and partitionings reminded me of this demo from about 2 years ago. In short, it's a Hilbert curve where the iteration level varies by the colour value. I wanted to make some small changes, but I ended up rewriting it completely. The shader approach seemed needlessly heavy and redundant for something that works more naturally on a CPU. But mostly it was just a fun exercise in looking at the same problem from a different angle.

The first picture shows the original idea. With the new idea, I wanted to get rid of the slanted lines; the result doesn't feel any better to me, but I guess it's interesting in its own way.

I came across this halftoning idea sometime last week. While the idea was relatively easy to understand and fun to implement, I've spent quite a lot of time trying to make the result look nice.

In each row, the image is split into bins containing roughly the same sum of lightness value. This is nice to implement when the number of lines/bins is a power of 2, so we can recurse with a binary split. Thus the line density varies by average lightness. The problem is that density is considered along the x-axis. If things change a lot between rows, the lines get slanted, so they appear more dense. Here I've included some averaging between neighbouring rows to make thing a bit smoother.

I'm also including a fun glitch from the early tests. The line-density system includes the set of point coordinates and the graph structure (which point is connected to which). What happened here is my generic graph generator that simply finds the nearest neighbours of each point. So in the light areas that are compressed horizontally, the nearest neighbours were left and right.

As GLEW is unmaintained, uses GLX by default and the EGL part is unfinished, the best would be if projects would migrate to GLAD.

I've migrated PrusaSlicer to GLAD today.

https://github.com/prusa3d/PrusaSlicer/pull/14440

PrusaSlicer already used GLAD, the question is why it used GLEW then?

Yes!

I got the barebones of C + OpenGL + GLTF :)
Now I can start cooking remake of one of my childhood games.

Model: Sora - > meshy. ai

Minimum spanning tree of a dithered image, 4096 vertices. Model: Swetlana

haven't really used this account much but heres a game engine i've been working on for around a month using opengl and C

Is it me or are all four of these doing basically the same thing?

»Freier Linux-Treiber für Nvidia-GPU unterstützt OpenGL zukünftig via Vulkan:
Bei neueren GeForce-GPUs werden Linux-Distributionen für OpenGL-Anwendungen einen Treiber nutzen, der die eigentliche Arbeit einem Vulkan-Treiber übergibt.«

Spannend und deren technischen Umsetzung liest sich für mich als Laie in diesem Bereich spannend an. Wann kommt Linux populär auf den Grafik-Desktop-PC? ;)

https://www.heise.de/news/Freier-Linux-Treiber-fuer-Nvidia-GPU-unterstuetzt-OpenGL-zukuenftig-via-Vulkan-10314023.html

Freier #Linux -Treiber für #Nvidia-GPU unterstützt #OpenGL zukünftig via Vulkan | c't Magazin https://www.heise.de/news/Freier-Linux-Treiber-fuer-Nvidia-GPU-unterstuetzt-OpenGL-zukuenftig-via-Vulkan-10314023.html #LinuxKernel

Freier Linux-Treiber für Nvidia-GPU unterstützt OpenGL zukünftig via Vulkan

Bei neueren GeForce-GPUs werden Linux-Distributionen für OpenGL-Anwendungen einen Treiber nutzen, der die eigentliche Arbeit einem Vulkan-Treiber übergibt.

https://www.heise.de/news/Freier-Linux-Treiber-fuer-Nvidia-GPU-unterstuetzt-OpenGL-zukuenftig-via-Vulkan-10314023.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon

Como ya sabéis desde hace unos años Vulkan se ha convertido en la API gráfica que mejor aprovecha nuestras tarjetas gráficas en Linux. Antes de Vulkan se usaba OpenGL.

A partir de Mesa 25.1 se abandona el driver libre de OpenGL por Zink. La idea de esta tecnología es ejecutar OpenGL en el driver libre de Vulkan NVK. Funciona como una capa de traducción de código OpenGL a Vulkan.

https://www.collabora.com/news-and-blog/news-and-events/goodbye-nouveau-gl-hello-zink.html

Mesa 25.1 will default to Zink+NVK instead of the old Nouveau OpenGL driver for NVIDIA on Linux https://www.gamingonlinux.com/2025/03/mesa-25-1-will-default-to-zink-nvk-instead-of-the-old-nouveau-opengl-driver-for-nvidia-on-linux/

It's been a while since I last showed the progress on my #audio waveform viewer here. The waveform display widget itself is slowly reaching quality levels I'm happy with - switching from software rendering to #OpenGL has really worked wonders for both the speed and the quality of the waveform rendering.

Now I just gotta write the rest of the app around it...

Another fun Wonderbly moment - we briefly deployed a version of the #OpenGL renderer that used a headshot of one of the founders as the basic texture to a QA cluster, so we could get some screengrabs to use for my upcoming presentation of the GL based scene renderer.

OF COURSE, the QA team ordered some proof books from that cluster in the ten minute interval we were pissing about with it, so "cosmic Nick Marsh" actually exists in a handful of hardcopy #books #MurphysLaw , I wish I had one.

Okay so notice how the lighting is different in the corner piece?

The story of #JimClark and #SiliconGraphics Inc. #SGI was the pioneering company that essentially created modern 3D graphics, along with the #OpenGL standard.

https://www.abortretry.fail/p/the-rise-and-fall-of-silicon-graphics

A lone red tetrahedron on a dark blue background. Left: C-Program using OpenGL 3.3 (340 loc), Right: PC-Scheme using BGI Graphics on #Pocket386 (~200 loc + ~200 loc matrix lib).

OK, I cheated for #2. I sorted the faces by depth by hand.

#PCScheme #Geneva #OpenGL #BGI #dos
#retrocomputing