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!
Tuesday, June 7, 2016
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!
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!
Monday, June 6, 2016
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.
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.
Sunday, June 5, 2016
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.
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.
Saturday, June 4, 2016
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!
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!
Friday, June 3, 2016
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.
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.
Thursday, June 2, 2016
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!
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!
Wednesday, June 1, 2016
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.
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.
Subscribe to:
Posts (Atom)