Ruben Osorio

Hola again graphics peeps! 😊 I found myself with enough bits and pieces related to text rendering to warrant a write-up. So here it is! 😱 osor.io/text Spiced up with direct vector rendering, sub-pixel anti-aliasing, run-time atlas packing, temporal accumulation, and more! I hope you enjoy it! 🧡

Video is still not Bluesky's forte eh? Here's a screenshot! 🙃

Hola again graphics peeps! 😊 I found myself with enough bits and pieces related to text rendering to warrant a write-up. So here it is! 😱 osor.io/text Spiced up with direct vector rendering, sub-pixel anti-aliasing, run-time atlas packing, temporal accumulation, and more! I hope you enjoy it! 🧡

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

If you need the correct index per-thread, as you do when you're going to write the samples to the buffer, there's some more wave-ops involved, since you also need to calculate the local offset for each thread on the wave. WaveReadLaneFirst/WavePrefixCountBits sorts you out, here is how it'd look:

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

Paying my respects with a video rendering 10% of the pixels each frame (hacking this in just now so turning all denoising and TAA off, no reprojection of "empty" pixels either 😜). (Prepare for the bsky video butchering though)

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

And because this approach ends up compacting the list of pixels per-draw, it responds really well to scenes with heavy dithering into the visibility buffer. Some of the other tile-based approaches I tried struggled with this, since they'd need to dispatch multiple resolve tiles per tile on-screen.

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

I *really* like the flexibility of this approach while keeping the resolve waves full. With this you can do software VRS easily, both spatially and temporally, which is super cool! You can just write any logic to decide how the visibility buffer values map to a sample to resolve.

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

This can include a lot of data like per-draw transforms, tinting, material stuff, and notoriously also including the bindless texture indices. Nice not to need any of that NonUniformResourceIndex uglyness.

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

The resolve is dispatched per-shader, not per-draw, so it's still a very manageable amount of dispatch indirect calls. As in, a single one for all your variations of standard, anisotropic, whatever... so there isn't a ton of concerns about empty dispatch indirect arguments.

Tried a few ways to resolve a visibility buffer as a nightly adventure a few days ago 😄 So far my favourite I could come up with is collecting lists of pixels per shader, internally sorted per draw, then a dispatch indirect per shader scalarizing on the draw index. Plus it can have cute bugs! 🙃 🧵

To collect the lists, I first count how many pixels each draw and shader want, then allocate space in a big buffer for each shader, then allocate space for each draw within the chunk allocated for their shader. Then repeat the same logic but writing the pixels to the buffer with the right offset.

Spent a wee bit implementing some 🫰 rich-ish 🫰 text with support for *bold* and _italic_ annotations plus some cheeky line wrapping. Here's the beginning of a possible future post running through it 📄 Also "Look ma, no textures!" Just tracing them rays agaist them beziers ❤️

🪦 for the 720p video. Bluesky was destroying the small/timeline version of it otherwise. Let's see how a 1440p one shows? 🤔

Hola graphics people! ❤️ I've been meaning to do some write-ups that are hopefully useful, so this first one is about my approach to Order-Independent Transparency. osor.io/OIT 🙌Super excited to finally release this!🙌 I hope you enjoy it!

⌨️🙌 Hall Effect on an Alice layout! 🙌⌨️ Seems like hall effect/magnetic keyboards have become all the rage but I was sad that there was no options I could find for my favourite layout. So... here we are making a PCB and writing some firmware 😄 🧵🧵🧵

I made it compatible with the Maja V2 case I already loved, but I'm now getting pretty tempted to design a 3D-printable case so I can have more of these 😅 These SLS prints look very nice. My current keyboard now looks... exactly as it did before! But with different guts 😁

⌨️🙌 Hall Effect on an Alice layout! 🙌⌨️ Seems like hall effect/magnetic keyboards have become all the rage but I was sad that there was no options I could find for my favourite layout. So... here we are making a PCB and writing some firmware 😄 🧵🧵🧵

🎮❄️Late Christmas project post!❄️🎮 A controller with hall-effect sensors, custom firmware, PCB and case. With a funky layout too 🙃 Been playing fighting games with this since and I've been really enjoying it! Here's some pics 🖼️

A good example of this is if you have a key pressed fully, the moment you start releasing it you can send a "release", without it waiting to reach the fully depressed state. Similar to what Wooting does on keyboards that they call "Rapid Trigger" (wooting.io/rapid-trigger)

🎮❄️Late Christmas project post!❄️🎮 A controller with hall-effect sensors, custom firmware, PCB and case. With a funky layout too 🙃 Been playing fighting games with this since and I've been really enjoying it! Here's some pics 🖼️

With the hall-effect sensors you can get an analogue value of how much each key is pressed, the right thumb button is bound to what it would be an "up" direction on a joystick for example, with it sending values between 0 and 1 depending on how far pressed it is. This has another really neat usage.