It also helps that your work is undeniably pretty awesome ;)

This is valid, and for the most part I approach failure this way. Nonetheless, a bit of injured pride remains, and the thought of my failures being public forevermore, rather than just private conversations, feels pretty terrifying to me.

Minor side-note:
Yeesh. I'm thirteen years in. Feels pretty wild to think about.

Me from ten years ago, in the first years of my game-dev journey, would never have been fazed by that thought.

But nowadays, I'm so keenly aware of all the things I'm *not* aware of, that it's given me a whole new kind of impostor syndrome, and accompanying discomfort in communicating around work.

Does anyone else not tweet about their work because of impostor syndrome?

I feel like I've got expertise in some game-dev topics I could meaningfully share thoughts in, but I just can't get over the feeling that more competent folks will come and point out I'm super wrong in every way.

I'm starting a new blog on #techart tips focused on short snippets and lesser-known functionalities.

First 'fragment' is up: Editing the #UE5 Engine Shaders (without recompiling the engine)
chosker.github.io/blog/editing...

Very cool, I love this problem-space. I've not seen the cell approach before.

At this rate, the problem's going to be solved before I ever have the time to properly sit down and bang my head against this wall! 🥲

Understanding C++ Compute Shader Dispatch and RDG in Unreal Engine YouTube video by Ghislain Girardot

This was long overdue and took wayyyyy too long to produce, but here it is.

There are still a few knowledge gaps I was hoping to fill, but I ran out of time.
📺 Watch here:
www.youtube.com/watch?v=NxIa...

Honestly, I don't know if I want to move to any service that isn't decentralized for Discord-likes.
Just let me self-host and let users from their own self-hosted account systems log into my server.

If any central Discord-alternative gets big enough to be useful, it'll hit the same legal problems.

Fully agreed on that.

One thing I will say, as a product person, is that I frequently come to the engineers with vague premises intentionally. I specifically want to have a nuanced conversation to find the right path forward, so I don't waste time thinking of non-viable solutions in a vacuum.

I don't think you're alone in the sentiment at all. I certainly do share it.
I'm personally active across Twitter and BlueSky as that covers most people I like to hover around, but even with that, people have left entirely or moved to Mastodon etc.

I really don't know what the path forward is.

tldr; I don't think it's a criticism of engineers, I think it's a criticism of short-hand communication.
Assuming all parties are invested and are trying to get the best result, people should communicate their full thoughts and nuances, not shorthand "we can't do that" type things.

We all have our own frame of reference. If we want to build the best tools we can, we should all be trying to avoid embedding that frame of reference in our communication.
The product folks need to explain *why* (they think) they need something, the engineers need to explain why it'd be a problem.

It's the same type of situation as when people ask for help on their specific problem and proposed solution. That solution is often like using a screwdriver as a hammer.
A lot of the time, it's more productive to zoom out, get the broader context and find a solution from there.
Same for dev-talk.

I don't really think that's what Robin is trying to convey.
The problem with "It's not possible" is that it's a dead end.
Working with engineers on features, I frequently run into them going "we can't do that". A decent chunk of those times, my pushback prompts us to find a way it *can* be done.

This has been my experience working with it.
In very common topics, it can potentially remove most of the barrier to entry. In technically complex, niche topics, it helps on the implementation/iteration side, but it needs to be guided very tightly, and as user, subject-matter knowledge is *needed*.

I made a directional noise type I call Phacelle Noise which is pretty fast!

Is it new or does something functionally identical already exist? I'm not sure! But I didn't come across one like this yet anyway, so here's my findings:
blog.runevision.com/2026/01/phac...

#Graphics #Shaders #Shadertoy

A timeline visually representing the advice from my post, emphasising how dramatically and reliably having more time, with a testable build, converts to your game being better and your studio being safer.

I've been running an indie games studio for 15 years now, and it felt like a good time to boil down what I've learned into 4 pieces of advice:

www.pentadact.com/2026-01-08-1...

I hope it's of use, not least because goddamn I forgot how long blog posts take to write.

I feel like until this morning, you guys had more snow than I had up here, near the arctic circle in Sweden! It's been a weird winter.
Finally getting proper snow now, though, and even the infrastructure here isn't quite coping with it all coming in one go.

Well darn, I share the sentiment written there entirely, so I guess I'll have to go order this book. On the Christmas list it goes!

Huge congrats! Excited to see what you'll be up to, regardless of what form that takes exactly. Your contributions in terms of learning resources in the space have been incredible. There's few deep yet accessible sources in our niche, but you've helped fill that void. Enjoy your next steps!

In a nutshell; take your instance-space Z position, multiply that by world-space up (0,0,1).
Subtract instance-space Z multiplied by instance-space up ((0,0,1) transformed instance->world).
This is the core WPO math for 'straightening'. Do make sure your mesh is aligned to the surface first!

This same math also lets you easily adjust the height of your grass - you can drive this using instance data if scattering procedurally, or based on noise textures or global parameters (like seasonality).
I often use instance data in PCG to decrease grass height close to edges.

One of the things I'm adding in the upcoming Universal Wind Shader update is a fun math trick which takes your surface-aligned grass, and adjusts the geo to be 'world' up again (instead of local) using WPO.
This stops your grass from floating, without making it look like it's growing sideways!

I barely ever use the Shader Complexity view mode anymore.
I honestly feel like it's mostly a gun for people to shoot themselves in the foot with when new to graphics optimization in Unreal. It'll send you on endless wild goose chases that don't actually matter, while not showing you what does.

An update on our terms of use | The Mozilla Blog On Wednesday we shared that we’re introducing a new terms of use (TOU) and privacy notice for Firefox. Since then, we’ve been listening to some of our

This is just the usual T&C panic. Whenever any company changes T&Cs, people that aren't into legalese read the changes and go "LOOK HOW THEY'RE ABUSING US!" regardless of whether that's actually the case.
If you're sharing this, you should also share Mozilla's reply: blog.mozilla.org/en/firefox/u...

An image of Unreal Engine's Widget Reflector with the Application Scale field selected.

It's also easy to do this just for the current session!
If you press Ctrl-Shift-W, the Widget Reflector will open. That contains a global Application Scale setting as well, which will be discarded after you restart.

I dunno. Just spitballing. It's a fun problem 😄

Depends how much state you actually have, I guess. But I feel like you'd probably want to find your 'root' flow path first, and then in 'post' allow paths (higher likelihood/width as flow gets higher) to branch off it when terrain's flat, forcing them to pathfind back to the root flow when steeper?

As I think about this, deltas are just a consequence of large amounts of water in soft terrain with relatively little verticality. Feels like you should be able to just increase 'flow' along the river as you get further from the origin, and then deviate into multiple smaller paths if slope is low?