Day 46: Not a Good Day

Today has not been the best of days. I'll keep it to a minimum, but not too much of note has been done so far. We have had a very successful playtest today, which is a bright side!

I'm currently working on creating a slightly curved plane for additively blending cloud textures to the sky. Stay tuned!

Day 45: Mr. Blue Sky

Today was mainly a day for capstone to get the build ready for tomorrow's playtest. Lock and load! And fix up the patrol volumes. I found a nasty bug where the patrol volumes for the insects were placed in such that they all forced their way down the level, but I managed to fix the spawn transform relatively easily.

As for the programming project, I did manage a skydome while waiting on things today (today was extra busy like every other day in the past week), in which we lerp a color from one to another across a skydome model. I also put in a bit of a height modifier so we can change how much sky to see:

It's so much more vibrant now! Just wait until we get clouds!

Day 44: Greenlight

Woo! We finally got greenlit on Steam! 

Other than that, a few changes were made, including a fix on the new sprint control where the player could sprint if they were still moving and the key wasn't held down. However, they couldn't sprint when the key was held down and the player started moving. We fixed that!

As for homework, I finally figured out how to manage the priority queue for best-first searches and use the function object syntax (overloading parentheses) to make compare functions in the template for Greedy Best-First, Dijkstra, and A*.

What's next? Finally getting back to terrain!

Day 43: Long and Bitter

Yeuch. Today was a day filled with things other than programming work.

On the bright side, I did get a few tasks done, including attaching voiceovers to text (that will only play one voiceover at a time, keeping track of the other voiceovers in a scene) and finally putting keyboard UI in the tutorial text!

I still have to do plenty though, mainly implementing console pathfinding systems for homework.

Day 42: The Cluster

Today's another day to wait for design to catch up. I did do some refactoring code (taking movement switching out of the attack code in the insect character) and fixed a bug where the levitation shot wouldn't follow the insect, but all in all not much was actually changed for today in the capstone project.

The big thing today? Clusters! The csv-file reading (however janky and not quite foolproof) is usable to create a specific cluster that has two parameters: a radius of trees and how many trees.

It's a simple interface (X's establishing the four corner boundaries with "amount-radius" found within the Excel cells), but allows me to create clusters of trees that seems more deliberate design than randomness:

Now I can relax a little bit, caught up and ready to make things a little prettier.

Day 41: Beautiful Water

Today was almost a day to relax, until I realized that the trees were still small. No matter! I applied a scaling matrix to get them up to size. I also started working on a possible .csv-file format reading process to help with clustering trees in specific spots with certain radii. Hopefully it'll turn out nicely!

Like this here water I worked on today:

It was some quick work with fresnel reflections and transparency, but it should serve as a good replacement for the depth-ignorant fermented tofu that showed up yesterday.

What's next? Actually doing the spawning of trees to this csv format style.

Day 40: Itty Bitty Baby Trees

Yeesh, this billboarding certainly gave me the runaround. Turns out that by using the matrix calculations inside the GPU, the billboards were all wrong. That is, rotating around strange points, much like the previous post.

What's the problem? Not sure, but I know I can shuffle in the rotations as a parameter in the instance buffer.

Wait...why not do the whole world matrix? Crazy, I know, but possible. The catch? I'm working on a fairly high warning level, so the memory won't be set as 16-bit aligned with regular mallocs. What to do? Override the operators! _mm_malloc(size, 16) did the trick. The same applies to array new operators.

With that, I can now use the matrix (properly set at row_major in the shader) and get proper rotations of a rich and lush land of...mini-trees.

I'll have to scale it at a less tired time.

Day 39: For Instance,

Today was a busy (and hungry) day. Mainly got preparations in for the build for tomorrow, including pushing  my computer to the limit for lighting builds.

What's the big part of today? Instanced drawing! Imagine that we have a single buffer for vertices, but we don't want to have 500 instances of that buffer. Instead, we can have an instance buffer that uses the same vertex buffer across different variations in position, scale, etc.

This example worked with position:

What's this? The positions aren't right? Nor are the rotations? Egads! Each position will have to have a specific calculation! Looks as if I'll have to do the billboard rotation calculation in the GPU.

Day 38: Boarded Up

Time for the most difficult part of my programming career...rendering a quad!

Gasp! Nah, although I had quite a bit of trouble rendering the thing. Apparently I had forgotten to set the index buffer indices correctly. We got something on screen!

Oh wait, we should probably have it face the viewer at all times. If you imagine the x and z difference of the object position to the billboard as two sides of a right triangle (the smaller sides, not the hypotenuse), then voila! Taking the arc tangent of those and decoding it to radians leads to the rotation that the object must have at all times in order to face the camera!

Wait a second:

This tree doesn't look right. Perhaps we should enable alpha blending?

Ahh! A ghost! Wait wait, I forgot to use the alpha channel as a coverage mask:

There we go. Taking the tree and firmly placing it into the ground requires a bit of an offset, but it's slight compared to the rotation and alpha.

Next up: instanced rendering! When you don't want 6000 vertex buffers.

Day 37: Quadruped

Today's been mainly a day of refactoring and bugfixes again. Oddly enough, GPU particles cannot have a color particle parameter that can be changed per system. Who knew?

As for the plans today, I've been making plans to render something other than terrain. Gasp! Time for a quad. The nice thing about quads is that I can essentially use the same set of points (can we say static vector?) and even the same texture, to possibly use instanced rendering.

Now I just got to get the rendering going.

Day 36: Dynamically Detailed

Apologies for the short post for the last couple of days; now we're getting back on track.

Capstone's moving smoothly so far; the designers are just about getting the boss area design on and are working in tweaks to current objects like horizontal elevators:

The big thing though? Dynamic tessellation! Seems that one can apply tessellation factors to control point patches (i.e. triangles) based on depth from the camera. Where to apply it? I was foolish and thought to apply it from the vertex shader, but it appears the vertex shader doesn't really do much where tessellation is involved. Nah, it has to be done during the constant patch function during each run of the hull shader. There, we can stick (currently 3) tessellation values and vary them in a similar depth-based way like distance-based normal mapping. The result?

Way cooler than distance-based normal mapping:

10 times the triangles, but none of the frame rate drop!

Day 35: Long Weekend

Ugh, today's been much too long of a weekend. I've gotten plenty of bugs out of the way and figured out how to read in input parameters to the constant patch function that determines the tessellation of objects from the hull to the domain shader, but most of it has been taken up by some very important, very stressful stuff.

Pictures to come soon when relaxed!

Day 33: Null Hull

Today was a very long day, thanks to a surprisingly good playtest! Plenty of bugs were found, but we're in good shape for spreading our news elsewhere.

As for the big things today, I was mainly working on getting tessellation to work in my terrain project. By using the uvw coords of the tessellated patches (see 3-point structures), one could set a new vertex position and run it to the pixel shader from the domain shader. However...

Yeah, the textures weren't interpolating correctly. I tried a similar process with the vertex position and...

Wait, wait, wait, I had to do the same with the normal, tangent, and binormal. And then why not for the depth and height?

It's faint, but now there's a VERY obvious line of static where one height ends and the other begins. Oddly enough, only by actually interpolating the y-position of the three patch control points can I actually manage the same coloration without the static line:

One more thing! Why is there no cell outline or UI? This is troubling! Seems as if I forgot to set the hull shader and domain shader references to nullptr when switching to a shader that doesn't use tessellation in the device context.

Phew. Now we can start working on distance-based tessellation.

Day 32: Roughly A Bazillion Triangles

Phew! Today marks a big milestone in my graphics programming know-how. Through use of the hull and domain shader, I can now tessellate my terrain!

What is the hull and domain shader, you ask? Well, compared to the geometry stage in GLSL, the hull shader is very specific to tessellation. The hull shader is responsible for making a "patch" of control points, or taking a set of vertices in which to tessellate by a tessellation factor. It's a fairly automatic process, but very important. The domain shader... well, does what the vertex shader originally did.

It doesn't make too much sense to use the vertex shader; the vertices need to be tessellated before any world-to-view-to-projection space transformations are involved. In this case, the domain takes the work off of the vertex shader in another pipeline stage.

The result? We go from this:

To this!

Wowza! That's about the same distance from the camera. 5 times as many triangles!

What does that do, other than kill the graphics processor? Well, imagine that we don't have to produce 1000x1000 points anymore and just tessellate the detail in! Or do so anyways and optimize it.

Next up; only optimize at a certain distance!

Day 31: Behold My Kingdom

Today was juggling quite a few things today!

Capstone was mainly about sound attenuation; turns out that a lot of our programmed sounds were 2D, attenuation-less sounds, so I worked in bringing some depth to our audio.

As for the homework, I worked through that memory manager with time to spare! (very little) I won't say much since it's homework, but it's interesting to see how one creates a memory manager using a doubly-linked list of a specific size of data. It's kinda like a mini-heap! I also ran into a bit of trouble after I fixed the manager; looks as if it wasn't the only place where bugs were found.

And as for procedural texturing, I played with a few values to interpolate textures and get what feels a bit more right. Lava shouldn't have rock textures and should have at least a bit of interpolation with the surface, so I'm still tweaking them. Next up is working with normals and then maybe... the geometry shader!

Day 30: Busy and Bugged

Finally! A performance hit. Seems as when I gather too many cells (size too small) on large enough terrain, the frame rate takes a hit:

Now I wonder what it'll do for only one cell?

As for bugs, I found out that the enemy, when the player is currently attaching to it and it goes back to normal, actually crashes the system. Gadzooks! That's what happens when an actor is destroyed without waiting until the next tick. I made sure to use a boolean to make sure that exactly happens.

We also got an assignment, so I'll keep the words short. Gotta fix the memory manager code!

Day 29: Grassy Patches

In capstone, today was a day for refactoring. That is, take all of the recommends to take my else-if statements and polymorphize them. That said, I did also put in the new particle system effect for our elevator, and tested it out so the level would be playable:

I also mainly worked with procedurally applying textures to the terrain. After the TGA-loading issue gave me trouble, I defaulted to loading a dds texture instead, as the data doesn't load in a wonky way based on the bpp value. That said, does setting the texture based on a singular slope check work out?

Yeugh. Yeeeuch. That is definitely looking more like pond scum than grassy overlay. What to do? Linear interpolation! Just applying it based on the grass texture at the lowest slope to the rock texture at the slope value did the trick. I also did a similar interpolation with normals:

What to do next? Applying several levels of depth would probably do the trick. Snow, grass, and...why not hot lava?

Day 28: A Slippery Slope

Today was another day for wrapping up big bug fixes and little changes, such as setting players' powers upon respawning checkpoints so they couldn't take a power where they shouldn't. There's also the deal of fixed camera angles, where for special camera angles and vistas the player camera blends with a fixed point. However, the player's movement wouldn't be in relation to that camera. What to do? Constrain the rotation while the camera was borrowed by that fixed point so the player could only move in relation to that point in space.

As for procedural texturing? I'm still figuring out the TGA format in terms of loading files; the method I figured only works with 32-bpp, and trying to fnangle it for 16-bpp makes some weird designs. As for slope based texturing, one can take the normal's vertical value (essentially the normal would be perpendicular to the tangent (slope) value and vary the texture based on that slope. I'm still figuring how to make the TGA file loader more friendly so I can use more textures, but I used an example with the rock slopes to make it more apparent:

Hopefully I can figure out this 16-bpp malarky!

Warp Surfing and the Moon

Today was a light day, but carried its fair share of busy all the same.

For capstone, it was mainly fixing the big bugs of yesterday's playtest. What were the bugs? Mainly being able to spam the warp button and using its small vertical offset to reach ridiculous heights, along with the cube actually carrying the player in a warp if shot from below. The first one required a cooldown, but the second one required a tricky sweep in which the player had to sweep her body and check for a cube; the cube sweep had more of a chance to sweep into something else, since its body is larger.

As for terrain? Good news! I figured out what was the problem with the terrain mapping. This hearkens back to my studies in depth mapping, where depth values vary exponentially, or at least not on a solidly linear scale. That meant that around the values 0.9-1.1 were the big depth values in terms of varying texture. In that case, I decided to go with three levels of detail: One with the fully detailed normal, one with the stretched out distance map, and one with absolutely no normal map. This manages at least some more level of detail that feels a bit more natural than just dropping from lots of detail to no detail:

Also, the deep blackness of space and the barren environment reminds me of the moon; I should probably introduce greener pastures.

Day 26: Not Sure If Distance Mapping Or Not

Got distance mapping to work on top of height map movement! Whew!

After wrapping up the work to get metrics measured on a small room scale (as opposed to the whole game), I fixed up height based movement on my terrain. Essentially the inputs would be an x and z, and would search for the triangle to use. Once the triangle had been found in the specific cell, a raycast would be shot through the triangle and an intersection would be calculated at that point (from 1.0f through the triangle. The intersection would essentially be a float value that I could use to set that distance. Behold!

I assure you, it's a lot more interesting in video form.

As for distance-based normal mapping, the idea is to only set the actual normal mapping at a set depth value. The other one would be a less detailed map that would be stretched over a larger quad (say, stretched over an entire cell). That way, less detail would mean less processing power on getting the little details in. However, I'm not entirely convinced, and may need to play around with values until I get what I'm looking for:

Day 25: Metrics Revamp and Stats Galore

Today is a statistical kind of day!

Just kidding, here's another podium design. The idea is to consistently slow and speed up an object to give a general idea what the power does:

As for more stats, it seems as if the team is finally ready to start testing out room-based metrics, so we'll see how that goes. I also started work on gathering new data such as warp recall/placement, as well as time spent in gravity wells and during slow time dilation effects.

As for my terrain project, I finally figured out what the problem was with font! (subtracting textures in the vertex shader, hurr durr) And as a result, I've started up gathering statistics such as position, cell and triangle render count, and frame rate:

Luckily enough, large-scale terrain pretty much has me rendering only half as many cells on an average basis.

As for the next step? Let's try moving along the terrain! Which means...complex raycasting to place oneself on a triangle! Woo!

Day 24: What I Can't See

This week poses quite the odd assignment: it seems that in order to make the identity of the ley-giving powers more obvious and less dangerous (see: evil electric gates), the producers are having me work on a podium-based design, in which we'll be showing mini-behaviors of the powers at work. This'll require taking out the powers and replicating them in a repetitive, mini-environment. So far the gravity podium has been rather simple, but the time one may be a bit tricky depending on which movement we will use. Since the dissolving blocks now only dissolve one material instead of the other, I think I may opt for the spiral design.

As for the terrain work, I've (I think?) successfully culled terrain cells that are not visible in the viewing frustum! How do I know this?

...I don't yet! But that's what statistics are for. I'm currently working on those now in a screen-space UI shader.

Day 23: Greenlight

Today was a fantastic day for our project! It is now featured on Steam Greenlight for all who have an account and would like to keep up with what my perils are amounting to!

As for other news, I'm currently in the midst of creating a viewing frustum so I can test the six faces of a cell versus the actual viewing frustum plane (calculated from the proper matrices). Soon we will get results!

Day 22: Multi-cellular Organism

Tomorrow's our next update for capstone! As a result, I poured through and made sure the build worked properly, along with fixing bugs such as a strange levitation interpolation bug. When the code was created, it set the speed to (DeltaTime * Speed) instead of time, even as the DeltaTime was already being used as another parameter in the function. These results weren't noticeable in high frame rates, but since we're still working through slower rates due to unnecessary shadowing, the levitated objects jitter. It's all fixed up now.

I've also started refactoring; this means saying goodbye to unused ideas... (sniffle)

As for the better news, I managed to get some good work done on the terrain cells before they kicked us out of school for a tropical storm warning! The odd thing was that the buffer creation calls were returning false, but only because the Terrain Cell initialization mistook S_OK for a false value. (???)

Now with cells of varying height and width, we now have proper terrain cells for frustum culling in future updates!

The question is, how many cells are too many cells and how many aren't enough? I may have to get the font texturing working after all when I start working with optimizing.

Day 21: Cell-Splitting

Today's mainly an interim day; it's surprising that one day, you can roll through with plenty of fun visuals, and other days where it's quite low in terms of big accomplishments.

The big bug in capstone today was differentiating between control rotation and actor rotation for the respawning of the player. When respawning, the player is actually teleported back to their previous location. In order to preserve things like direction, one must change both the actor's rotation and the specific rotation of the camera. The camera rotation is controlled by controller rotation, so one has to properly offset the camera rotation from the actor rotation and use that as a constant whenever the respawn actor rotation changes. This was all realized in discovery over a matter of time, so it took awhile.

As for exciting things? Cells? Yes! Terrain cells! Seems that that process takes a while to do as well. I just finished creating the classes for cells rendering their specific bits of terrain; they hold a buffer containing an entire cell's width and height of terrain quads. This means that I'll be spending the next couple of days taking the buffer rendering out of the terrain and making it a vessel for the Terrain Cells.

Day 20: Setting Up Cells

Bug fixing is continuing quite smoothly; at first I was worried that the request to ignore certain post processing effects for particles wouldn't go through (since Custom Depth seems to be the only parameter that can differentiate post-processing effects and can't be used for multiple sets of effects). Luckily enough, without selective transparency the post-processing effect actually won't apply to materials with transparency!

As for bugs, the elevator likes to swallow objects when moving, so I put in a sweep check to stop the movement or in the case of levitated objects, grab the object away from the player:

As for continuing normal mapping work, that effect I talked about in detail yesterday finally went into effect last night:

That much detail over a gigantic level of terrain? Yeesh, I should probably work on optimizing at this point. I'm starting up from semi-scratch to create a set of equal-volume cells to hold the terrain to frustum cull it. Hopefully we get some progress!

Day 19: Basic Bug-Fixins

Today was a day primarily saved for little bug fixes here and there; the levitating platforms could actually be used like a magic carpet, so I placed a quick sweep check that would prevent the player from being able to move it while directly above it.

As for that, I also coordinated the bow color to fit Vala's main color and placed a distance limit on warps. What else?

The big stuff comes tonight, as I'll be working on calculating not only normals for the terrain, but binormals and tangent vectors.

What are those? If we already know what the normal is from previous posts, we can imagine that the normal can be treated like an axis (y axis, for example). In that case, the tangent vector (doing exactly what a tangent does) is the x-axis for that example (perpendicularity), and the cross product of those vectors produces the binormal.

What? Those x, y, and z pieces can be represented as colors? That's what a normal map is all about! In that case, we can point the normal based on whatever color is sticking out at that pixel. In that case, the pixel shader calculates the diffuse lighting based on the normal changed by the map sampling instead of an actual normal, which produces much more detail.

Visual details may come today or tomorrow! Still calculating those vectors I was talking about.

Day 18: Depth Free

Phew! Today is a long day and this article is late, but I'll crank it out anyways.

Currently working on improvements upon code for normal mapping! Mostly calculation of vectors for tangent and binormal vectors for normal space.

As for the homework? Almost done! I'm just confused as to why the Column Major traversal, known for taking much too long, has less cache misses than the Row Major traversal?

Capstone? The most was done in that today! In fact, I found that the Custom Depth attribute that objects (pixels) have in the scene actually help with depth-immune calculations, say rendering objects regardless of depth. The Custom Depth acts as a z-buffer value, which is an optional parameter in case it takes a lot of data. This can also help with a post-processing effect that favors Custom-Depth-Users.

What's next? Figuring out the homework? Gasp!

Day 17: Plenty of Little Graphs

Today was mainly a day to tackle the homework, but there still remains a couple of lingering questions.

In the assignment, I learned that the height actually varies inversely by width, to the point that the allocation for the matrix (from a one dimensional sense) is the exact same data. One allocation, no problems!

As for the data, I'm not sure exactly what they're asking for in terms of CPU performance counters. I profiled and easily saw the advantage of row major over column major traversal, but I'm not sure at all how to use performance counters to catch cache misses. Microsoft isn't the best at teaching how to use its tools.

As for capstone work, it was mainly composed of a few bug fixes. The big fix was dropping through an elevator; the main character would drop through an elevator going up quickly enough, so I made it that the elevator slows its ascent a little bit to catch the fall of a jumping character.

What's next? Finishing up this gosh darn assignment and getting back to normal mapping.