Hacker News Reader

Comment by 60654 | Hacker News Reader

That's a very cool intro to a variety of shader techniques, especially post-processing effects.

What's even more wild, is that modern engines include all of this stuff out of the box, you just have to tick a few check boxes to enable them in your game. :) For example, check out these postprocessing filters built into Unity and Unreal - a ton of person-hours went into these:

https://docs.unity3d.com/Manual/PostProcessingOverview.html

https://docs.unrealengine.com/en-us/Engine/Rendering/PostPro...

View on HN

I agree with you, however in almost all commercial games that I worked on, we do write our own shaders. For simple shaders, artists use directly a graphical tool included in unity for shaders authoring without writing any code, for complex ones we write our own code.

do you write them completely from scratch or do you write custom nodes for whatever node-based shader editor you use? I am a novice when it comes to shaders but I wonder about the performance difference between hand written shaders vs generated from a node-based editor.

Nowadays it's more valuable to create custom nodes to enrich the node-based editor library. Sometimes we write shaders from scratch if we need to implement some original lighting, materials, etc

Oh sure, and especially for custom materials with specific lighting or masking properties, or for tweaking instanced meshes, etc. The standard materials only get you so far.

But post fx like bloom or vignette? I'm okay using a stock shader for that, it's not worth spending the time on building one from scratch. :)

that's great but there's lots of reasons you may want to roll your own engine

Especially if it's a 'smaller' game with mechanics that are unique. I just wonder if there are any good resources for the basics that a game engine needs.

The advantage of writing your own "game engine" is that it would only have the exact set of features you need for your game, and it would make the things you need to achieve as fast and as easy as possible.

This means traditional advice for "the basics of a good game engine" doesn't really apply, because if you're just making a bog standard game engine you're wasting your time and making a crappier version of Unity or Unreal.

https://geometrian.com/programming/tutorials/write-games-not...

Agreed, but I guess I'm saying basic architecture stuff like:

- "How do I render things?"

- "How do I integrate sound?"

- "How should I handle events?"

THREE.js[0] is high enough level that it solves some basic problems (hierarchies of objects, basic materials, basic lighting, rendering pipeline) and low enough level that you still have high granularity control (you can roll your own shaders, lighting, render order, etc).

I don't know if anything like THREE exists for OpenGL, though.

The upshot of THREE is its super easy to develop with (alls you need is a browser). The downside is that it slows down very quickly for even simple things.

[0] https://threejs.org/

I've been looking for something like THREE.js for C++ for years now, to the point where I actually started developing my own. But due to my inexperience with large codebases I have a hard time doing something like it that looks good and works well.

(I am a security analyst, not an engineer, but I'm transitioning to engineering roles now, so this might change in future, who knows :) )

For a general reference I would look at Jason Gregory "Game Engine Architecture".

For a deep dive into all game engine topics I would recommend the Handmade Hero dev streams: https://handmadehero.org

(Note that Handmade is not a useful model for an actual game production, it's more like a platform for investigating cutting-edge engine topics, so you can pick and choose parts to get what you need. It's been going for years and remains mostly a tech demo.)

Reply on news.ycombinator.com