Little Progress, but Detour in the Works

So far I've found something that may help; a Mr. Michael Cutler has used a simple form of the Detour client code to create a straight path for an object that may help the ball in my application (Here) travel in a straight line to its target. Unfortunately I've been quite busy today, but will definitely be adapting it when I get the chance. More details tomorrow.

Enemy Husk Created and Copy Inheritance Established

Alright, time to take a break from untangling Recast and Detour and time to create an enemy in order to attach pathfinding. The Copy object was previously a struct, so I upgraded it to be an inherited copy of the Enemy that would go twice as fast. I had quite a bit of trouble understanding why things like the model's name that would be used as an index from the Enemy and Copy object did not transfer properly; seems like if the Enemy and Copy objects aren't pointers, the copy constructor messes up the transfer of information.

Along with that, I also cleaned up a couple of lines involving getting members from Copies; since Copy isn't a struct, it's best to use get/set methods so the information is transferred properly; there was a problem referencing the correct copy when the Copy was recycled, and it had a reference to "Copy0" when it was "Copy1" when remaking a copy. Luckily enough, everything's all set with that initial framework.

I also added movement via deltaTime to the player and enemy; without a proper managing of speed in regards to frameRate, the movement was quite jagged until the fix. Luckily I already put in some code for deltaTime to measure when the copies would die.

Next up is figuring out how to implement pathfinding for Enemies and Copies...

The dangers of dynamic memory allocation and working out a passable navigation mesh

Phew, today was a tough day. Regardless of the lack of documentation, I pedaled through Recast's methods of creating a basic navigation mesh and figuring out how to load DirectX vertices and indices into the float* and int* arrays that Recast uses. I have no idea why the person who did these libraries thought it was a good idea; I was very confused by the cap variable and its use in constantly allocating memory as the amount of vertices and triangles increased (y'know, because of that no-documentation thing) but finally managed to figure it out, along with the need to put a counter in midst a vector iterator to get the indices into proper triangles after three iterations.

After preparing said triangle mesh, the rest is creepily straightforward. Create a heightfield, compact it for faster use, a set of contours, a 3D mesh with matching detail object, then peel off the 3D to make a 2D mesh set that Detour can later use for pathfinding. Next up is to figure out how to fit Detour in the whole equation and I may finally be able to test a proper AI. Due to the amount of code tailored to use SDL in the demo, I am a bit hesitant in rendering the navMesh at this point, but if worse comes to worse, I may have to convert back from dynamic arrays to vectors. If anyone uses Recast or has worked with it, a version that actually uses std::vectors would be VERY much appreciated.

Giving Recast Another Shot

It seems that although Recast grossly lacks any documentation whatsoever, the rest of the Internet grossly lacks friendly information on navigation mesh creation. Unfortunately, although I was able to cover the main surface in triangles, there was little in the way to actually figure out how to create a navigation mesh with the triangles that were blocked by an object. 

These things do happen, and I had to start over from scratch with not enough knowledge on the intimately complex process of navigation meshes. I decided to give Recast another shot, using premake (the new version supports VS2013! Thank goodness!) to make the demo so I could trace variables that would otherwise seem horribly confusing by just perusing the source code. 

I understand the process of Recast's mesh input a little better. The bounds I have to set manually (main plane z and x bounds, y bounds aren't too wild since the ball can't go up such a steep plane), while the vertices and indices (labeled triangles with Recast) are entered not into a specific buffer, like DirectX's buffers, but a dynamic array of floats and ints. Luckily I've got plenty of experience with dynamic array usage while working with C, so I understood that process. However, I'm not too sure whether it'll work. The demo loaded from an obj file, whereas I am loading multiple models from multiple obj files (e.g. world-specific models). The conversion process seemed to workout alright, and I am currently on the post-build config process (before I head to bed, *yawn*)

In the demo, settings were managed via an editor, but I'll put some values in on the fly and manage them from code. Those settings won't be changed in the front end anytime soon. Hopefully this works out; navigation meshes are no joke, and could use some more support from the open source audience and/or people looking to post another pathfinding tutorial.

No Documentation? Making a Navigational Mesh from Scratch

For Navigation Meshes, I thought in my previous post to use Recast. However, the documentation is...nonexistent. Unfortunately, there was little in the way to increase understanding of navigation mesh creation nor using another library to abstract the process. I have brainstormed for most of the day on how to go about it, but am currently coming up blank and have not found many useful resources online. That said, I am still in the making of creating a navigation mesh from a set bounding space, with each triangle represented with a random color for debug viewing. So far I managed to create Mesh objects from scratch for each triangle as they are created, but I am still figuring out the collision process and have come up with debug rendering in the least.

In the future, I will see what I can do to create a map of triangles that cover the entire main surface while not drawing all triangles that intersect with any world objects in the scene. Bullet should help with its raycasting usage at this point.

CMaking Recast and Killing Copies

The next step was to set copies to kill themselves after a certain point in time; this required me to setup a deltaTime (which will be used for velocity changes as well in the future) by using GetTickCount64() and setting the current time as a previous time to calculate the change between frames.

However, the big question was, how will the AI work? A* was a possibility, but a grid is a bit firm for full 3D movement and can get tricky with non-square terrain. Luckily, a Mikko Mononen included an open source navigation mesh library, Recast. Navigation meshes are a bit more complex, but allow me to setup a mesh of 2D polygons that specify where the AI is supposed to go. Combine that with targeting the player, and we may have a good enough AI on our hands.

Getting the library is half the battle, however; the code is there but needs to be properly compiled before usage in Visual Studio. CMake is a good way to compile libraries, but I was very used to having CListMake files already made for me, as if many people have had this problem. I even used a couple that somebody made for an earlier version, and ended up confused on what was wrong. Turns out I needed to have a little more complex understanding of where to specify my source and include files, and even had to make a few from scratch. Luckily, everything ended up alright, and I have a set of libraries I can use for some work with navigation meshes.

Max Velocity and Transparent Ghost Perils

Now on a previous assignment, I was creating ghostly images that would not collide with the player but move forward at a quicker speed; this is an upcoming test of future images on something like an AI who interacts or antagonizes the player. So far the images...are not turning as transparent and ghostly as I expected. Odd; when applied to the player, the transparency works fine, but to all other objects...

Gasp! A peril is found. The objects seem to not be as transparent as previously thought, borrowing far too much color from the clear color in the background. This is a problem with alpha transparency objects that are drawn before opaque objects. The fix? Separate the group of models to be drawn transparently from those that are drawn opaquely, and render them right after another. Since this iteration is done twice, a RenderModels method should be created to handle this.

So far, so good. However, I've been meaning to fix the player's velocity as well, as it has no limit on how fast I can push it via keyboard input. This is a problem with no damping values set; without linear and angular damping, the player ball will not respond to friction and slow down appropriately. I've settled on 0.04 for the linear and angular values.

And so far so good! The copies themselves slow down relatively quickly since they have no forces applied to it (reading the player's mind? How do we even?) but that would mean the next step would be to create an AI that interacts with the player. That, and getting the ghosts to actually disappear after awhile.

Starting up the perils

Hello! This is a personal blog to account the struggles and trials of learning all sorts of programming concepts, primarily those featuring rendering and game development. Pieces of code never always work like they should, but especially in this type of skill-mongering, something's bound to go ESPECIALLY wrong. That said, it's a programmer's hobby to make sure that wrong part gets fixed. I will be posting as much as I can whenever I get on to practice. Right now I'm in the middle of a DirectX application utilizing Assimp for model loading and Bullet for physics.

Making an ugly ball roll across an ugly landscape that can make shadow copies of itself. Riveting!