Instancing Revisited -- Owen Meyers

     In the previous blogpost, I discussed the Instancing manager that needed to be put together in order to properly display static meshes. The system was essentially a pool for the instances on the CPU side, which would then be organized and sent over to the GPU. There were some problems with building this system, which led to a bit of a longer development cycle on this feature than I would've wanted, however it was still completed on time.

    The first problem that I encountered when building this system was integration. The way I approached this problem was simply by removing all instancing from the Central Processing system, and instead place it within its own manager. This helped to simplify a lot of the update code, as a message would be received in Central Processing to update a model or add/remove an instance. That message would simply be passed along to the Instancing Manager, which allowed for a "black box" approach to utilization. Anybody from anywhere within the engine, should they so need, would simply need to send a message with the proper data (usually a model name and an object pointer) in order to generate the instance. The system would then process the command and keep a registry of objects that are active, allowing for the system to easily update any object on where it appears in the buffer.

    The second problem that I encountered when building this system was the data organization system itself. The approach I had been using up until this point was a copy of the animation manager system. This, however, didn't account for how the buffer had to be laid out for the actual instances of meshes. The reason for this is that the animation manager uses a disorganized buffer that is organized by the instancing buffer. This means that I was building the system the animation manager uses to inform its organization *using the organizational system of the animation manager.* This required a shift in thinking, that ultimately took a few days in order to fully build. The result was an instance manager that was capable of organizing the data given to it, provided those outside of the system utilized it properly.

The striking difference between adding an instance of an animation state machine (left) and a skinned mesh (right). The system on the right is split between skinned and static meshes as the buffer is split in two before being merged.


The result of the final system. Meshes are stamped out in batches on the GPU rather than being individually drawn.


Comments

Post a Comment

Popular posts from this blog

Adding assets to every enemy -- Owen Meyers

Image
      As with every game, it is very important to have assets to denote which enemy is which. Being able to tell at a glance what enemy you are encountering before receiving a face full of buckshot is incredibly important. The issue for Project [REDACTED] is that we didn't have any artists working full time to deliver assets for the enemies. Thus, it fell upon me, the designer of the asset pipeline, to acquire assets for every enemy. This led to having to fix models and integrate animations, with each problem being subtly different.     Take, for example, the shotgunner model. His original model was designed for an OpenGL renderer, and was flipped 180 degrees for that very reason. In addition to this, he was also placed halfway in the ground, likely due to something required for that game's collision to function. Fixing this model to function for our renderer required that it be re-rigged and most of the animations acquired from Mixamo. With the help of Kris, and several hours
Read more

Sphere to AABB collision

       I had a problem today when trying to detect sphere to AABB collision. For some reason the collision check that I made was never turning true even though I could clearly see the sphere hitting the AABB. This was a big problem as we needed this collision to detect whether any entities are hitting walls.     I discovered that the problem with this bug was that I was improperly getting the closest point in the AABB to the sphere. The way I fixed this problem this problem was by getting the max vertex that the circle center could be and using that to get the closest point on the AABB to then determine the minimum vertex between the sphere's max vertex and the max of the AABB.  Once I found this point, I could properly compare the distance of that point to the center of the sphere. This solution will allow detection between walls and any sphere collider such as the player collider, and enemy collider. This is very important to make sure they both stay within the level bounds.
Read more