DEV Community: Wooden H Studio

Goodbye World

Wooden H Studio — Fri, 15 May 2020 22:07:49 +0000

As you can tell by the title of this article. Our studio is closing up shop. Wooden H Studio is canceling our unnamed Spyro clone and disbanding our studio for several reasons.

Due to unforeseen circumstances regarding the COVID-19 pandemic, Wooden H Studio has decided to disband. We have lost several key team members on our team and the project can no longer continue with our original vision. The remaining team members decided that it is no longer in our best interest to continue to move forward with this project.

A Word from the Former Development Lead

"I just want to say I am honored to have led such a talented team of developers. Although we are going our separate ways now I will still remember you all as my teammates. It was fun while it lasted."
- Joseph Whittington (Former Development Lead)

A Word from the Former Art Director

"I had an awesome time working on this project with the team. We didn’t end up reaching our goal, but it was a great learning experience that I’m very thankful I got to be a part of. I hope to see everyone who worked on the project go on to do great things in their careers!"
- Ashton Ritzel (Former Art Director)

Goodbye from all of us at Wooden H Studio

Setting Up A Job System

Wooden H Studio — Tue, 12 May 2020 03:30:19 +0000

What's the problem?

Long story short; we have too much going on. Long story long; games require a lot of computing power, everything you see on screen is the visual representation of a bunch of math, and just like the rest of us, CPU's tend to slow down when exposed to too much math.

Whats the Solution?

Multi-threading! instead of forcing a single CPU core to do all the math, we're going to have to delegate it to other cores. That'll make it so that our main thread can really chill out and find itself while it draws all the pretty shapes that we end up seeing in the game, all while the other lesser liked threads gruel away on boring math (don't worry they like it).

Whats the better solution?

A Job system! A job system is going to let us dynamically start new threads as we need them. A video game isn't going to be mathematically intensive every single second. Sometimes you get some chill moments that let both you and the CPU relax and have a nice sip of tea (please don't pour tea into your CPU), and during these times, you don't really need a lot of threads to render everything. Other times you have way too much happened on-screen, and you feel like you need to step away so that you can call a friend and have them assure you that there are enough threads to handle all that math! What I'm trying to say is that a Job system is a way to queue up a bunch of function pointers that you send off into their own threads so that they can do their jobs in peace. This system allows us to really up the amount of math the CPU can do at once, this way the game doesn't have to wait for the Physics to calculate how far the character flies away so that it can make sure the sky is still blue.

By Ahmed Fayez

Reducing CPU Overhead for DirectX API Calls

Wooden H Studio — Mon, 11 May 2020 23:44:52 +0000

One of the biggest challenges of graphics programming is handling the CPU overhead of the API calls that move memory around and that update buffers and resources. For open-world games, one of the most expensive operations is copying the vertex and index buffers over to the GPU.

Initial Approach

The first thing I did for my renderer was the naive approach. I made a model struct and each model had it's own index and vertex buffer so that when rendering I would just copy over the vertex and index buffers for each model and then render accordingly. This worked during the initial stage, but once I started adding in more assets and ran the profiler I saw how inefficient it was so I decided to do some simple optimizations.

The Biggest Optimization

The biggest optimization in the renderer API calls was combining compatible buffers into one big buffer and reducing the number of API calls for updating the index and vertex buffer. This allows us to now have a few large copy operations in the render loop and then use draw calls that index into the unified buffers using offsets stored in each game object as opposed to allowing each game object to store it's own model data and significantly sped up the rendering code.

Further Optimizations

Further optimizations would be multithreaded rendering calls and using texture atlases to reduce the number of textures that need to be copied. However, given the limits placed on this project that isn't a priority right now.

By Joseph Whittington

Quad Tree Basics

Wooden H Studio — Mon, 11 May 2020 23:33:15 +0000

Trees, oh glorious trees, they provide us shade, oxygen, and a way to optimize our collision system. Recently at Wooden H Studio we have been working on trying to implement a Quad Tree system to help optimize our mesh collisions.

What’s a Quad Tree?

A Quad Tree is a tree that uses a recursive pattern that subdivides itself into 4 other quad trees, insert a point into itself or one of its children, and query how many point are within a defined region like a rectangle or a circle, this type is mainly used for 2D applications. Additionally, quad trees have a long lost brother named Octrees, the main difference between them is rather than splitting into 4 sections it splits into 8 sections and is mainly used for 3D applications.

So how do you use one?

The way both of these trees work is they have a capacity for how many objects can be inside a section at each time for example we will assume our capacity is 3. As long as we stay underneath or equal to the capacity we do not need to divide our tree

But, once we go over that capacity we need to subdivide. Regardless of where the new point is it is prefered that we split it evenly to avoid confusion.

How does this help us?

Well as I said before this will help us optimize our newest problem, mesh collisions. Now we could use an Octree for this but the problem is we have very limited memory and while this is pretty fast it does use a fair amount of memory. The other reason why we opted for the quad tree is the only thing we are using the mesh collision for is the ground. Since our ground is going to be hilly and rugged we find the centroid point of our triangle and insert it into our quad tree. Since we don’t plan on our environment moving around and changing we can pre-compute this before the game begins and call a query to reduce the amount of collision checks. With this knowledge we can reduce collision checks from 200 to possibly 5, with very little complexity or even effort.

By Gage Dietz

Billboarding in Geometry Shaders

Wooden H Studio — Mon, 11 May 2020 23:29:50 +0000

Backface Culling

In DirectX, backface culling is on by default which makes dealing with flat objects more difficult. If the flat object is facing the wrong direction, then the object will not be rendered. This is especially a problem when trying to make use of geometry shaders for particles. For the particles, I decided it would be best just to put in a point and append triangles to it to create a quad. If the quad created with the appended triangles did not face towards the camera it would have been culled.

Billboarding

A solution to flat objects not facing the camera is to have them always face the camera. To have the flat objects always face towards the camera I implemented billboarding in the geometry shader. Billboarding does not necessarily have to be done in the geometry shader, it could be done in the vertex shader but if that vertex also goes through a geometry shader the orientation of the added geometry won’t necessarily be facing the direction you want it to. If the billboarding was done correctly in the geometry shader the object should always be facing towards the camera.

By Taylor Addington

The Oriented Bounding Box Problem

Wooden H Studio — Wed, 29 Apr 2020 18:35:47 +0000

Recently at Wooden H Studio, we have been working on creating an entirely custom physics system for our up-and-coming game engine. Up until this point collision and resolution has been smooth sailing until we got to the dread Oriented Bounding Box, OBB for short.

The Problem

OBBs are similar to its other cubic brethren the AABB (Axis Aligned Bounding Box) as they are both boxes but, are different in every other way. For starters an OBB is not aligned to any axis, meaning it has 360 degrees of freedom whilst the AABB doesn’t rotate at all. So, this meant we couldn’t check for collision or resolution the same way as the AABB’s, so we had to come up with another solution.

The Separating Axis

In-game physics there is a theory that to determine if there is a collision between 2 objects there is a plane that separates the two objects, if there is then there is no collision, otherwise, the two objects collide. This is called the Separating Axis test and we used this test numerous times throughout our development to detect a collision, and even determine the resolution needed as well.

How does it work?

At first, I thought this same question, in fact, it took me a while to understand how to write it into code, but it is much simpler than it sounds. What we need to do is project the box onto a line that is parallel to the axis we want to test and determine the smallest and largest value per bounding box. Once we have each of the boxes projected onto this line all we need to do is check to see if either of the boxes smallest value was less than the other largest value. If these values overlap, then there is collision along this axis. But this isn’t always the case. Say two boxes are sitting flat on a plane, side by side and we wanted to check the axis perpendicular to the plane, we’ll use the vector {0,1,0}. If we project the boxes onto this axis technically there would be no gap between the 2 projects thus concluding there is a collision, even where there isn’t. The solution to this problem to continue doing this test using different axes until we find one that has a gap. Since there theoretically can be an infinite number of axes, we need to devise a plan to shrink that number to something more reasonable.

The solution for our dreaded OBB is to take the X, Y and Z axis of each bounding box and test them, after that the first box’s axes must be crossed with each axis of the second box’s axes. This results in the separating axis test being run 15 times at a minimum! While this might not seem great for computation the theory works and gives us very accurate collision detection and helped boost our thought process with the rest of the collision perils. This system works great especially for different object types like OBB to AABB and really helped boost our productivity after learning about this insane method.

By Gage Dietz

Creating the User Interface

Wooden H Studio — Sat, 25 Apr 2020 03:01:59 +0000

Structuring the UI System

Recently I undertook the task of setting up the Actus Dei Engine’s user interface system. After getting a second renderer up for the user interface I had to approach its architecture. I knew this process could be simple if I planned it out carefully. Despite that, I did find myself turned around a few times. The first step was obvious. Create a base class for the components that would make up the UI and a User Interface class to store them. I also gave the User Interface class the ability to pause the gameplay when accessing menus. Seeing as how each component would most likely only render one quad, it seemed wasteful to make an additional draw call for each one. I created the Overlay2D class to store a list of components. The overlay will then store all the component’s quads into a buffer on the overlay. If it does not require updating, we make it a static buffer. Now we have one draw call per visible overlay. Text is stored inside components but rendered separately using Sprite Batch and Sprite Font from the DirextXTK_UWP package. Considering that an overlay can represent a menu screen, a submenu, a heads up display or just a single log component, I made it so you could render more than one at a time. I also run update through the overlay’s ID lists which allows active components to update things like animations.

Rather than incorporate the controls of the user interface into the overlays, I chose to create a base class called UIController. Implementation requires the game side code to create derived classes of UIController containing the logic for controlling the overlays. Like overlay, this class also receives a list of component ids. Before the update is run, the user interface’s active controllers receive input. They can use this input to modify overlays, components and to toggle other controllers on and off. They also check input against its currently focused components and may respond based on the values they return. Some examples in our game would be a controller for the title screen and a controller for the pause menu and gameplay calls like a pause. An example of a component that returns a value to a controller, would be a button component that returns a stored value based on which input is given while it is selected. With this, the user should be able to make their overlays dynamic with Input and components.

The last major component to the system is a static class that listens for messages to the user interface from other systems. The user interface class creates a component for its debug log which can then be added to any overlays. The listening class can then receive strings from other classes to add to the user interface log. The listener class can also receive messages which the user interface will send to a designated controller to be interpreted. Now the user interface can react to messages from other systems. To implement the system on the gameplay side the user must write his controller classes and any new components they need. Then they will create an instance of the User Interface class, add overlays, controllers and components to it using its functions and pass it to the engine.

By Daniel Hayward

Memory Fragmentation and Pointers

Wooden H Studio — Fri, 24 Apr 2020 21:56:44 +0000

Fragmentation and Pointer Relocation

When I first started making the memory manager, I was aware that when I allocated and deallocated memory, there would be gaps in the memory from the deallocation. When memory was deallocated, I would move any allocated memory that had a higher memory address than the deallocated memory down to a lower memory address to remove any gaps that the deallocated memory left behind. As I moved allocated memory down to lower addresses, I realized that the pointer that was pointing at the relocated memory no longer pointed at the correct data. If the pointer tried to reference that data, then the wrong data would be referenced or perhaps the memory being referenced would be null.

Handles

Handles in this implementation are basically an index into an array of pointers to memory. I originally got the idea of using handles from Game Engine Architecture by Jason Gregory, in the Defragmentation and Relocation section. Gregory described three different ways to combat the relocation of pointers, carefully tracking the raw pointers, smart pointers, and handles.

Handles are much more flexible than raw pointers in regard to relocation. When memory is moved raw pointers would have to be manually adjusted but with handles when memory is moved, the indexes into the array stay the same but the pointer at said index will be moved to a lower memory address. When the handle tries to reference what it is pointing to it will go into the array and find the new or same memory address.

By Taylor Addington

Water Shader Research Issues

Wooden H Studio — Tue, 21 Apr 2020 18:11:06 +0000

The largest issue that I came across when trying to create a water shader was the lack of information. I didn't quite know of a sure way to this, but I had a general idea. I searched the internet for some guidance or at least something to work off of. Soon I learned that there was little to no information relevant or current enough for what I was trying to accomplish. All information was either dated, in a different API with little explanation, or stuffed into a complicated architecture that made it seemingly impossible to unravel given the time.

However, though I had not a lot to work off of, I accomplished in finding something useful. I was at my breaking point, I even tried asking for help online, but then I was pulled back to a specific outdated tutorial. I had often been brought back and at this point, I gave in. It was entangled in some overly complicated architecture and only spoke on the reflective and refractive elements to create water. However, I dug deep and made the best out of the scraps I gathered. There may have been a better source of information I had yet to find, but simply couldn't find it. I simply worked with what I had and it turned out alright.

I was able to create a water shader that created something resembling a calm pond with subtle movement. It relied on my knowledge of 'render to texture' techniques and shader programming. I figured out how to reflect a texture generated from an object in an entirely unseen scene and pass it as the water reflective or refractive texture.

By Moises Carmona

Simple and Effective Collision Resolution of an Axis Aligned Bounding Box to an Immovable Plane

Wooden H Studio — Fri, 10 Apr 2020 00:47:43 +0000

Recently here at Wooden H Studio we have uncovered a way to create some simple Axis Aligned Bounding Box, or AABB for short, to plane resolution, so let’s get started with how we did it!

Standard Variables

As a standard AABB’s have a couple variables that when added together create an AABB, these include a position, and minimum value, a maximum value, additionally we made a simple plane that consists of a position, and a normal vector. So, let’s assume we already know that the AABB and the Plane are colliding and now we need to figure out how to move the AABB back up to where it isn’t inside the plane.

The Calculations

What we did is we started off by using the closest point to a line test. Originally, we didn’t have a line to use so we needed to make one. We used the normal value of our plane and added it to the plane's position to give us the endpoint for our line, this way the plane could be facing any direction and we will always have a valid line to start. From here you can find the closest point using the closest point on a line test. To do this test you need to subtract the lines end position by the lines starting position and normalize it, I’ll call this the "Start To End" vector. Then you take the point you are trying to find, in this case, it is the AABB’s position, and subtract it by the lines start position. Next, we want to find the dot product of both of these values and multiply it with the "Start To End" vector. Lastly, we need to add this new vector to the plane's position and that is how you find the closest point!

Next up we need to find the extents of the AABB, which is simply the AABB’s maximum value subtracted by its position and that will give us the extents of our cube. We can use the extents to get a radius in coherence with the plane. To get this radius we once again use the dot product with the planes normal vector and our extents.

So now that we essentially have the AABB’s position projected onto our line and we have the "radius" of our cube all that is left is to perform a distance check. We can use the distance formula to see how far our closest point on the line is from the plane's position. From here we need to find how much overlap occurs between the plane and the AABB, well we have the distance the object is from the plane, and we have the "radius" of the cube, and we know the object is already colliding, so we can take the radius and subtract the distance from it to get the overlap. Now you can multiply this overlap by the planes normal and that will give you the force needed to keep it above the plane and not colliding with it, and that is how we have done AABB to Plane Resolution.

By Gage Dietz

Reducing Texture Overhead for our PBR Asset Pipeline by 50% using Channel Packing & Emissive Intensity Maps

Wooden H Studio — Thu, 02 Apr 2020 18:55:11 +0000

Wooden H Studio is currently developing a PBR renderer for our Xbox One Engine Actus Dei. We ran into some issues with needing too many textures for our PBR assets. This is a quick breakdown of how we reduced the number of textures we needed for our PBR renderer.

Channel Packing

Our initial PBR renderer used 6 textures for PBR, those textures being base color, normal map, metallic, roughness, ambient occlusion & emissive. This was a bit absurd, but it was my first time working with PBR rendering so I wasn't aware of the tools that the artists had for channel packing. After discussing the texture limitations with my Art Lead she told me that it was possible to pack the metal, roughness & AO into a single texture so that took us down to 4 textures, but that was still too much, so I decided to drop emissive support in the engine to keep us down to 3 textures.

Emissive Intensity Mapping

It didn't stop there though, later in the project, we decided to do a night level for our demo and I (Joseph Whittington - Dev Lead) found it too limiting to ask the artists to avoid using emissive maps for a night level so I looked into ways of reducing the overhead of the emissive maps. After looking at the emissive maps for some of the emissive PBR assets I had for testing purposes, I noticed that the emissive maps were just the diffuse maps with some slight variation in color intensity.

After a quick brainstorming session with my Art Lead, Ashton Ritzel, we created a technique to reduce the data needed for emissive maps into a single channel by storing an intensity value that we map to the base color texture to use as the emissive color in the shader. We coined the technique "Albedo to Emissive Intensity Mapping" because that's pretty much all we're doing here.

On the art side, the artists need to simply use emissive maps that only use the base color, they can color in the emission the same as they normally would just with black and white, keeping in mind that only the intensity value will be stored. Then when exporting they need to take the greyscale color of the emissive map and pack it into the metal/ roughness/ ao map making it the new metal/ roughness/ ao / emissive intensity map.

On the dev side, we just need to use the alpha channel of the new mixed map to get the intensity of the emissive color and then multiply it by the albedo to get the emissive color then use it as we normally would.

The result is a limited, but basically free emissive map. This was more than enough for what we needed and I'm glad I had a chance to implement it. Although this technique is a bit limiting and needs some specific requirements to be met in order to be implemented, if you meet the requirements you can save a ton of memory by not having an emissive texture and you basically get emissive color for free.

By Joseph Whittington

Managing a Game Studio of Students Remotely

Wooden H Studio — Thu, 02 Apr 2020 17:36:40 +0000

Wooden H Studio is currently working on a Spyro clone. Unfortunately due to the current virus outbreak, our project start was a little rough. This post will describe some of the issues we have come across with the transition to remote-only work and how we plan on mitigating those issues.

Issues

The biggest issue is that we have a hard time communicating with each other, and there is a lot of us. Not only is this our first project of this scale, but this is also a studio made entirely of students, so that adds some additional challenge because we also have to balance the workload from this project with other classes that are struggling with the migration to online education. There are some big issues with the dev team because we can't pair program as easily and debugging on the console doesn't translate well in a remote environment.

Mitigation

The way we kind of handle the communication issue is by handling personnel by the department. The dev lead stays in touch with the dev team and the art lead stays in touch with the art team and then each department does internal daily check-ins and the dev lead and art lead keep in touch with the producer and each other and that is how we reduce the amount of communication overhead. This seems to work as we are all busy people and don't have a lot of time to waste, so we keep info on a need to know basis. We also doing public daily standups in discord so everyone knows what everyone else is working on and have a chance to offer and ask for help or information if/ when needed. As for the debugging and pair programming, we pair program over zoom and fortunately, we are developing for Xbox One and can still debug natively on windows, so that was a big help. This is still one of our biggest issues though as our build reviews will be awkward.

Overall I feel like we're doing fine and will eventually get into the rhythm of working remotely. Until we do we will be losing some productivity, but we will still get things done and eventually ship.

By Joseph Whittington