3 ms·

The difference is that with networking, I don't need to bother myself with data being aligned to physical layer boundaries, or similar level small details that

The difference is that with networking, I don't need to bother myself with data being aligned to physical layer boundaries, or similar level small details that belong to network drivers or OS stack layer — and still get gigabytes per second throughput, because of good abstractions. And with OpenGL/Vulkan — it's like I am writing driver-level code, which is not my idea of fun. For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? Additionally, what you have described is still 10-15 lines of code. Vulkan is still more demanding.

groovy2shoes 9y ago
> For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? There is. It's called OpenGL ;) That said, I share your sentiment. Tossing aside the drivers and the general optimizations they offer seems to me to be akin to tossing aside your compiler because you can write more efficient assembly by hand. I think the ability to write such low-level code will always have its place, but I can't help but feel like we (as an industry) are going in the wrong direction with this. In trying to be optimistic about Vulkan and the like, it may be an opportunity for developers to experiment with different higher-level APIs until we manage to find abstractions that are as good as the ones we have for networking (and hopefully better, even). > it's like I am writing driver-level code, which is not my idea of fun. Luckily, that's somebody's idea of fun :)
munchbunny 9y ago
Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need. It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks. If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine. 3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).
- atemerev 9y ago
  I work with realtime scientific visualization, game engines solve different kind of problems. So I have no other choice than to work with OpenGL/Vulkan directly, which is... less than satisfying. Good abstraction layers are totally possible, like it was done for networking, 2D graphics, and other hard problems. However, with 3D, it is more of a cultural issue — the APIs were designed by hardware / driver people, who eat these kinds of complexity for breakfast. The rest of us have to suffer and adapt. Additionally, Vulkan is increasingly pushed as a replacement for OpenGL, and this makes me cringe. It's like somebody took the worst of WinAPI and combined it with joys of developing device drivers...

groovy2shoes 9y ago

> For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? There is. It's called OpenGL ;) That said, I share your sentiment. Tossing aside the drivers and the general optimizations they offer seems to me to be akin to tossing aside your compiler because you can write more efficient assembly by hand. I think the ability to write such low-level code will always have its place, but I can't help but feel like we (as an industry) are going in the wrong direction with this. In trying to be optimistic about Vulkan and the like, it may be an opportunity for developers to experiment with different higher-level APIs until we manage to find abstractions that are as good as the ones we have for networking (and hopefully better, even). > it's like I am writing driver-level code, which is not my idea of fun. Luckily, that's somebody's idea of fun :)

munchbunny 9y ago

Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need. It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks. If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine. 3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).

atemerev 9y ago
I work with realtime scientific visualization, game engines solve different kind of problems. So I have no other choice than to work with OpenGL/Vulkan directly, which is... less than satisfying. Good abstraction layers are totally possible, like it was done for networking, 2D graphics, and other hard problems. However, with 3D, it is more of a cultural issue — the APIs were designed by hardware / driver people, who eat these kinds of complexity for breakfast. The rest of us have to suffer and adapt. Additionally, Vulkan is increasingly pushed as a replacement for OpenGL, and this makes me cringe. It's like somebody took the worst of WinAPI and combined it with joys of developing device drivers...