@natpbs To you for reading it!

@MikkoMononen Really cool! I've been taking a look at the repo just now and it definitely sparks joy 😄

I did GPU cause that's where my brain lives 24/7. It does look like you have a good path to allow the flexibility of CPU/GPU and direct/atlas.

Great job, I see it picking up quite a lot traction. Well, it already is! ❤️

@natpbs Oh! Thanks for pointing it out 🙏

So glad you can edit messages in here 😄

@aras Oh! I hadn't! 😲

That's very sweet, a hell ton of functionality for a code-base that size.

@MikkoMononen great job!! ❤️

Oh and yet again blaming @aras cause it made text rendering sound very neat to work on in the classic https://aras-p.info/blog/2017/02/15/Font-Rendering-is-Getting-Interesting/ ❤️

My first one one got an unexpected amount of interest. Huge thanks to everyone who read it! (Especially
@jendrikillner since he was probably the biggest reason 😄)

This topic gets way more coverage but I've never seen it done/presented like this, so trying to make my contribution 🙏

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! 😱

https://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! 🧡

@popperelay Nice! Good job!

My first guess there is that the middle layer is self-occluding. You could tweak the interpolation or bias the depth closer when sampling.

The most effective for surfaces though will be to remove the coefficients of the surface as you’re sampling it. Because they’re additive you can just subtract the ones your surface added while in the final pass.

This gives you the transmittance of all other surfaces besides yours so they stop self-occluding.

@popperelay So all there is to set these up really is doing a pass doing min/max depth. Another adding the transmittance coefficients. And a final one sampling it. ❤️

@popperelay All of the relevant code should be in the post though. All surrounding stuff would be engine dependent.

@popperelay Hey! Thanks so much! I’d love to see this improved further 😊

I’m not able to make the whole project available unfortunately 😔

Been quiet but busy

Hope you all like it! 🧡

https://www.youtube.com/watch?v=VQRLujxTm3c

https://www.rockstargames.com/VI

@aras @zeux @TomF Zen 5 Larrabee-Style GPU when AMD? Could be fun cmoooon 🙃

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 ❤️

👨‍⚕️ 9/10 doctors recommend avoiding self-occlusion, so I've added a neat trick to the "Extra Sauce" section of https://osor.io/OIT about this since it kept coming up during GPC 🙏

Another frequent request was to have a video will less spheres moving slower and visibly intersecting so here it goes too! ❤️

@schrompf Something I hope comes across is that many other solutions are possible and perhaps the way to go especially if you know your constraints well.

@schrompf Thanks so much! 😊

About storing the transmittance events directly. Yep, you could do something like that. The sorting and the later search + accumulation might not be too cheap.

In my experience you sadly end up hitting any "reasonable" event limit. Especially with particles and if you add volumetrics into this as well (via marching and keep adding at each step)

5 bits per colour with transmittance might get a bit rough too, might be able to denoise though.

@jendrikillner Oh! Thanks so much!! ❤️

@rygorous @dngrs Base _ten_ should have been base _9_. 16 -> F, 2 -> 1.

*Insert badly edited meme about change my mind*

@simonschreibt Thanks! ❤️

I'm glad to hear that the RSS is working as well!😄