> It wasn’t just that we’d managed to get a triangle onto the screen. That could be done in about a day. It was the journey the triangle had taken to get up on the screen.
If anyone wants to experience something like that today, just follow an introductory tutorial on Vulkan programming. Vulkan is a programming model that gives so much low-level control directly to programmers. As a result, this "Hello Triangle" example became (in)famous for its need to implement a skeleton of a full 3D engine in thousands of lines of code before you can render a triangle on the screen.
If you RTA, that’s a perfect example of drawing a black triangle versus “A Black Triangle Moment”.
That tutorial is a general overview of all the possible boilerplate you would expect to see in a template project, and just happens to end in a triangle being drawn on the screen.
You could skip a lot of those steps. Is that 5 page section on constructing validation layers and fine tuning the debugger really necessary if your end goal was a triangle?
You can draw a triangle in Metal in thousands of lines of code too. And it’s common to have several hundred lines of pipeline descriptors, buffer management, and debug tooling before you even started encoding into your shaders. But it’s not necessary for _just a triangle_.
DirectX9 will even load the image for you, DirectX11 okay we get a few more structures to fill out, DirectX12 is where it goes off the rails and we are filling out a bunch of UNKNOWN DONT_CARE JUST_DO_IT. Then of course Vulkan is the one that gets the big fat "this probably won't actually work for you" warning.
I understand whats happening, but you know sometimes I just want to display a fucking image.
Thanks for sharing this, I was thoroughly tickled. The optimistic tone of the tutorial stands in stark contrast of the convoluted path to drawing an object.
Spent the last 4 days trying to get the raylib example game to run on my Android. Yesterday I changed course and got rawdrawandroid running instead. That was my black triangle (actually it was green heh), proof that my goal was actually possible. If rawdraw can build and run, so can raylib! I got raylib working shortly afterwards.
It's funny I always thought C gamedev would be hard, I just didn't think the hard part would be the "hello world"... I'm looking forward to actually building the game now!
(My experience is more like "the triangle that should take a day", but I still thought it was relevant as a kind of major milestone that puts you in a qualitatively new reality where now you have an actual working thing you can fiddle with.)
I appreciate the concept, I had my own black triangle recently when I finished writing my own implementation of an adaptive radix tree that is highly concurrent and keeps hot paths in an LRU and loads everything else from disk.
Now when I circle back to my full text search extension for Postgres I can do so knowing I can replace my naive inverted index with something that gives like a 10% performance gain but more importantly significantly reduced and CONSTANT memory profile.
On it's own however, it doesn't seem to do much and unless you're in the space you won't appreciate why this is an interesting implementation.
It's good to have a name for this. I feel like my entire career has been "black triangle" problems, and it's been a struggle to get recognized for that effort at times.
I've built a reputation for leading skunkworks projects in my org.
The trick I've discovered is that maximizing self-interest eg: maximizing your recognization of efforts (and for everyone else working on the project) is the best way to deliver long-term actual customer value.
So you put out some hype in the org first, build your black triangles internally, and then when you connect customer value, then connect the hype with results.
One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times in favor of shiny demo projects that demo well but can never go much further. Black triangle projects require time investments that at least big companies only rarely bet on despite being in possibly the best position to do so.
I think a part of it is that humans, or at least those that make their way into management, are in large part very visual creatures. If you can’t show them progress in a traditional visual way you sort of have to figure out some contortion to show some visual thing to use as a proxy of progress to keep the faith. Sometimes it can be achieved through selling some abstract progress metrics about work remaining (most often entirely detached from reality) but that only works so long.
More often you end up knowingly spending a large percentage of resources on vacuous side projects solely because they demo well to management in the short term — it’s a distraction but a way to keep the faith and the resources. I find it funny how much time and energy we’re willing to waste to play the game — paying the souped up visual taxes for decision makers, while doing the real work independently, often in the dark because we know management will react short sightedly to the black triangles.
working on these sorts of building blocks for big
wins will often actually result in projects and teams
getting axed.
Had this experience at a previous position. My predecessor had implemented a solution that was extremely hairy, and took many hours to run in production.
My manager (a software engineer himself, still involved in day-to-day engineering on this product) said that it couldn't be meaningfully bettered. But in the meantime, we were taking a beating from our primary customer upon whom we depended for ~75% of our revenue. I viewed this existing solution as a potential company-killer.
So I spent some nights and weekends hacking together an alternative. Got the run time down from several hours to thirty seconds using some basic caching and a basic tree structure... not exactly advanced black magic. It also required about 50% less code.
I excitedly showed it to my manager. I walked him through the code. He became angry for the following "reasons."
1. Instead of making the code smaller, he felt it made the code larger. This is because he failed to comprehend that my MVP "hey this is possible" prototype didn't actually remove the old solution. It was just an MVP! I explained this to him but apparently it didn't take.
2. He couldn't understand the underlying concept. Again, it was... a tree. Something you would encounter in a 200-level computer science course, at the very latest.
3. My code lacked tests. Again... this was a "nights and weekends" MVP.
Probably the single fucking stupidest moment in the history of my career. I am not a person who typically has communication issues with managers or coworkers. I was dumbfounded that he was dumbfounded and to this day I am absolutely baffled by this whole incident. Our relationship had been deteriorating somewhat but not to the extent that would explain his brain-dead and hostile response.
Unsurprisingly this lead to my departure from the company.
I've worked in places where management understood the idea of laying a foundation, and building up the abstractions and information architecture, and understood that the result of the first 50% of the project could be a single text log showing all the data paths working, but those companies are rare. Most places are like you said: they won't believe any work is happening until they are bamboozled by a visual demo of the software--and they think it's "close to done" when the visual demo matches what they think the software should eventually look like. That's why so many places ship unfinished demo-ware: Engineering shows off the proof of concept that only scales to 10 customers and doesn't actually write to the database, and then management demands they ship it because it looks done and the deadline is coming up.
I wish I could figure out, as a candidate, a good question to ask in order to suss out which kind of company is interviewing me.
> By the end of the day, we had complete models on the screen, manipulating them with the controllers. Within a week, we had an environment to move the model through.
The Black Triangle was a leading indicator of a payoff that began happening by the end of the day. Too many similar projects result in a constant string of promises that we are just about to turn the corner on velocity/capability if only we would let the engineers focus on this refactor for a bit longer.
In practice, "Black Triangles" projects are bets like any other. If they work out, they unlock faster velocity and the ability to deliver better features. Often they deliver nothing but a refactor to someone's idea of a better architecture, and are lucky to ever reach breakeven on engineering time.
> One of the engine programmers tried to explain, but she shook her head and went back to her office.
...Maybe they shouldn't be making their way into managing engineering then?
To be fair, the lady in question, Jen, did come around in the next paragraph. However, it still highlights the extremely annoying problem of doing non-visual work under visual(-only) people -- one then has to actively create visuals.
I learned a lesson early on in my career: never show a functional but ugly demo.
I once worked for months on a modern front-end for an incredibly old legacy system. This was so technically challenging that we weren’t sure if it could be done at all, so a functioning demo was a huge achievement.
What the customer saw was that it was ugly: black and white, plain text, no CSS, no styling of any kind.
They completely ignored the technical milestone and spent an hour asking if we could rearrange the buttons and change the colours. Bike shedding, in other words.
Since then I would much rather show something that’s very pretty but completely broken.
In my experience, maybe half of "foundation" or "infrastructure" work is actually bullshit. That's probably why it's not a carte blanche to just do whatever with nothing to show for it until "later".
The black triangles are also a lot more fulfilling than other problems. When you get the foundation of your project finished, it feels so good. And you know that you can start doing the fun stuff with relative ease now that the hard part is over.
I used to write opengl screensavers for xscreensaver (glplanet and pulsar) and I have to admit, sometimes when working with opengl it would take me more than a day to just get a triangle (or sphere, my preferred primitive) to show up on the screen. Anything from an errant transform, to a mistaken feature bit (lighting, whatever) turned on/off could make a huge difference. Once I could draw a quad I had everything required for pulsar, and once I could draw a sphere I had everything I needed for glplanet (although I later learned, I did get the projection math wrong the first time).
I had the pleasure of working with Jay doing the character illustrations on his indie space shooter, a couple of years before I started coding professionally. This was the article that always stayed with me, especially at times when progress was difficult (which became especially poignant 18 months ago with my ADHD diagnosis).
These days he works for a VR company, but his main creative activity has been writing sci-fi/fantasy/horror novels for some years now, and he has his own series.
PS. I was going to say this article was from way further back than 2014, but on reading the post it appears it was his own repost.
OpenGL? I did the monkey too! But I did a simple software rasterizer... (No OpenGL, draw bitmap directly.)
I only got as far as point cloud (the wireframe without the wires, heh). Want to continue the project and add lighting and texturing eventually.
My "big insight" (shower thought) that gave me the confidence to do 3D is that you don't need linear algebra. You can do it all with trig! A 3D rotation is just three 2D rotations!
It won't be very performant, obviously, but I'll take "my toy renderer runs slowly" over "it doesn't exist because I am struggling with linear algebra for the 7th time".
It's a lot more fun doing things the easy way! Even perspective is one line of code.
It helps to know that under the hood almost every serious game is a complete more-or-less real time operating system with its own IO, scheduler, memory management and various sub-processes relating to output generation and so on.
It was only after I wrote a couple of games that I realized that extracting this OS component would be worth the effort and after that making new games went substantially quicker.
>"It wasn’t just that we’d managed to get a [black] triangle onto the screen. That could be done in about a day. It was the journey the triangle had taken to get up on the screen."
So this is a 10-year old repost (2014), of an original article 10-years older than that (2004), describing and event that happened ten years before that (1994)?
segfaultbuserr|2 years ago
If anyone wants to experience something like that today, just follow an introductory tutorial on Vulkan programming. Vulkan is a programming model that gives so much low-level control directly to programmers. As a result, this "Hello Triangle" example became (in)famous for its need to implement a skeleton of a full 3D engine in thousands of lines of code before you can render a triangle on the screen.
https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Base_co...
fingerlocks|2 years ago
That tutorial is a general overview of all the possible boilerplate you would expect to see in a template project, and just happens to end in a triangle being drawn on the screen.
You could skip a lot of those steps. Is that 5 page section on constructing validation layers and fine tuning the debugger really necessary if your end goal was a triangle?
You can draw a triangle in Metal in thousands of lines of code too. And it’s common to have several hundred lines of pipeline descriptors, buffer management, and debug tooling before you even started encoding into your shaders. But it’s not necessary for _just a triangle_.
stefan_|2 years ago
https://github.com/ocornut/imgui/wiki/Image-Loading-and-Disp...
DirectX9 will even load the image for you, DirectX11 okay we get a few more structures to fill out, DirectX12 is where it goes off the rails and we are filling out a bunch of UNKNOWN DONT_CARE JUST_DO_IT. Then of course Vulkan is the one that gets the big fat "this probably won't actually work for you" warning.
I understand whats happening, but you know sometimes I just want to display a fucking image.
y-curious|2 years ago
andai|2 years ago
It's funny I always thought C gamedev would be hard, I just didn't think the hard part would be the "hello world"... I'm looking forward to actually building the game now!
(My experience is more like "the triangle that should take a day", but I still thought it was relevant as a kind of major milestone that puts you in a qualitatively new reality where now you have an actual working thing you can fiddle with.)
ianbutler|2 years ago
Now when I circle back to my full text search extension for Postgres I can do so knowing I can replace my naive inverted index with something that gives like a 10% performance gain but more importantly significantly reduced and CONSTANT memory profile.
On it's own however, it doesn't seem to do much and unless you're in the space you won't appreciate why this is an interesting implementation.
jacquesm|2 years ago
nerdponx|2 years ago
LASR|2 years ago
The trick I've discovered is that maximizing self-interest eg: maximizing your recognization of efforts (and for everyone else working on the project) is the best way to deliver long-term actual customer value.
So you put out some hype in the org first, build your black triangles internally, and then when you connect customer value, then connect the hype with results.
0xfffafaCrash|2 years ago
I think a part of it is that humans, or at least those that make their way into management, are in large part very visual creatures. If you can’t show them progress in a traditional visual way you sort of have to figure out some contortion to show some visual thing to use as a proxy of progress to keep the faith. Sometimes it can be achieved through selling some abstract progress metrics about work remaining (most often entirely detached from reality) but that only works so long.
More often you end up knowingly spending a large percentage of resources on vacuous side projects solely because they demo well to management in the short term — it’s a distraction but a way to keep the faith and the resources. I find it funny how much time and energy we’re willing to waste to play the game — paying the souped up visual taxes for decision makers, while doing the real work independently, often in the dark because we know management will react short sightedly to the black triangles.
JohnBooty|2 years ago
My manager (a software engineer himself, still involved in day-to-day engineering on this product) said that it couldn't be meaningfully bettered. But in the meantime, we were taking a beating from our primary customer upon whom we depended for ~75% of our revenue. I viewed this existing solution as a potential company-killer.
So I spent some nights and weekends hacking together an alternative. Got the run time down from several hours to thirty seconds using some basic caching and a basic tree structure... not exactly advanced black magic. It also required about 50% less code.
I excitedly showed it to my manager. I walked him through the code. He became angry for the following "reasons."
1. Instead of making the code smaller, he felt it made the code larger. This is because he failed to comprehend that my MVP "hey this is possible" prototype didn't actually remove the old solution. It was just an MVP! I explained this to him but apparently it didn't take.
2. He couldn't understand the underlying concept. Again, it was... a tree. Something you would encounter in a 200-level computer science course, at the very latest.
3. My code lacked tests. Again... this was a "nights and weekends" MVP.
Probably the single fucking stupidest moment in the history of my career. I am not a person who typically has communication issues with managers or coworkers. I was dumbfounded that he was dumbfounded and to this day I am absolutely baffled by this whole incident. Our relationship had been deteriorating somewhat but not to the extent that would explain his brain-dead and hostile response.
Unsurprisingly this lead to my departure from the company.
ryandrake|2 years ago
I wish I could figure out, as a candidate, a good question to ask in order to suss out which kind of company is interviewing me.
drc500free|2 years ago
> By the end of the day, we had complete models on the screen, manipulating them with the controllers. Within a week, we had an environment to move the model through.
The Black Triangle was a leading indicator of a payoff that began happening by the end of the day. Too many similar projects result in a constant string of promises that we are just about to turn the corner on velocity/capability if only we would let the engineers focus on this refactor for a bit longer.
In practice, "Black Triangles" projects are bets like any other. If they work out, they unlock faster velocity and the ability to deliver better features. Often they deliver nothing but a refactor to someone's idea of a better architecture, and are lucky to ever reach breakeven on engineering time.
winwang|2 years ago
...Maybe they shouldn't be making their way into managing engineering then?
To be fair, the lady in question, Jen, did come around in the next paragraph. However, it still highlights the extremely annoying problem of doing non-visual work under visual(-only) people -- one then has to actively create visuals.
This quote from Feynman expresses a similar idea: https://fs.blog/richard-feynman-on-beauty/
jiggawatts|2 years ago
I once worked for months on a modern front-end for an incredibly old legacy system. This was so technically challenging that we weren’t sure if it could be done at all, so a functioning demo was a huge achievement.
What the customer saw was that it was ugly: black and white, plain text, no CSS, no styling of any kind.
They completely ignored the technical milestone and spent an hour asking if we could rearrange the buttons and change the colours. Bike shedding, in other words.
Since then I would much rather show something that’s very pretty but completely broken.
recursive|2 years ago
unknown|2 years ago
[deleted]
orenlindsey|2 years ago
bluedino|2 years ago
Me: Look at this dot!
Mom: You put a dot on the screen?
Me: Yes! Now hit the keys! You can move it!
dekhn|2 years ago
pm|2 years ago
These days he works for a VR company, but his main creative activity has been writing sci-fi/fantasy/horror novels for some years now, and he has his own series.
PS. I was going to say this article was from way further back than 2014, but on reading the post it appears it was his own repost.
dejobaan|2 years ago
burrish|2 years ago
andai|2 years ago
I only got as far as point cloud (the wireframe without the wires, heh). Want to continue the project and add lighting and texturing eventually.
My "big insight" (shower thought) that gave me the confidence to do 3D is that you don't need linear algebra. You can do it all with trig! A 3D rotation is just three 2D rotations!
It won't be very performant, obviously, but I'll take "my toy renderer runs slowly" over "it doesn't exist because I am struggling with linear algebra for the 7th time".
It's a lot more fun doing things the easy way! Even perspective is one line of code.
jacquesm|2 years ago
It was only after I wrote a couple of games that I realized that extracting this OS component would be worth the effort and after that making new games went substantially quicker.
ReactiveJelly|2 years ago
unknown|2 years ago
[deleted]
082349872349872|2 years ago
intrasight|2 years ago
peter_d_sherman|2 years ago
Related concepts:
Egg of Columbus: https://en.wikipedia.org/wiki/Egg_of_Columbus
Hindsight Bias: https://en.wikipedia.org/wiki/Hindsight_bias
gchamonlive|2 years ago
https://news.ycombinator.com/item?id=29879009
unknown|2 years ago
[deleted]
wiz21c|2 years ago
cybrexalpha|2 years ago
sitkack|2 years ago
unknown|2 years ago
[deleted]
unknown|2 years ago
[deleted]
therealcamino|2 years ago
[deleted]
unknown|2 years ago
[deleted]
unknown|2 years ago
[deleted]
Zpalmtree|2 years ago
[deleted]
mensetmanusman|2 years ago
[deleted]