Graphics Programming

When creating any interactive 3D application being able to fly around a 3D scene and interact with objects makes it feel like all that math created something tangible. One of the simplest forms of interaction one would want in a game, or an engine, is being able to select objects by simply clicking on them. Before implementing this I was able to select entities by clicking on their name in the scene hierarchy list but that does not feel like you're interacting with the world, just the UI. Time to get to work. Ray Casting The first implementation we take a look at is ray casting. The idea is to cast a ray into our scene and check for intersection with any mesh in the current scene. A ray is just a mathematical structure that holds a 3 component vector stating the ray's origin and a 3 component vector stating its direction. struct   Ray  {      Ray () =  default ;      Ray ( Viewport &   viewport ,  glm ...

I have been putting this topic off for a while but my codebase - in particular the way a scene is structured - has gotten out of control. I have a Scene class that has a container of SceneObject , with automatic for loop support. You loop over the entire scene and do something with each SceneObject . The Scene class has a point light, directional light and camera as member variables. SceneObject has been a culmination of "what do I need entities in my scene to have?". It has member variables for a name, bounding box, an albedo texture, a normal map texture, Bullet triangle mesh. Oh and it also inherits from Mesh and Transformable. ECS Time to refactor. The idea is to implement an Entity Component System (ECS), a software architectural pattern mostly used in games. The pattern is relatively straight forward but implementations can differ a lot from each other. One problem that ECS tries to solve is the cost and trouble that comes with traditional OOP. C++'s virtual ...

I noticed that one of my cpp files was getting rather large and narrowed it down to the applications run function. I use this function as a giant main function, where there is a bunch of variable declerations and setup done before entering the applications primary while(running) loop. This file contains most of the render pipeline setup like textures, framebuffers and render buffers plus all the render execution code inside the while(running) loop. I actually do not mind working with big files, but it was getting harder to conditionally execute certain passes like Bloom or Ambient Occlusion and/or extend the pipeline. I will preface this by saying that I have done little research towards modern solutions to this particular problem, and that this is solely what I came up with and what works for me. Most software solutions come down to figuring out what works for the specific problem you are encountering, and common software patterns are often not directly applicable. I have done...