Why_It_Changed
Again merging my code into main took more time than wished, I wonder if claude commits by others will make small changes to the file that sort of mess up the merging process, because at this point I’m the only one changing these files, and I’m not really changing many others. Or it could just be my fault not understanding something with github lol.
Next_Week
I want to finish implementing the other methods specified by hybridrender, so I can at least implement the other features that the other render uses. Most pressing is getting the weapons to actually follow the player and always show in the right hand corner. Next is animation and particles. These are already in separate classes, So hopefully the vibe coding didn’t tie those classes and the first renderer too closely, and I can use the geometry and data that they already computed and do a render pass with them in my renderer, I still have to learn more about it. After that is rendering the UI texture, which is lower in priority because I anticipate it will be a lot easier.
Individual_Morale
My morale right now is lower, for right now I’m going to be only one really working on the renderer. To address the obvious, there already exists a renderer that was vibe coded so that the rest of the team can visualize what they are working on, But they went a little overboard in features of a renderer with that sole purpose(albeit with certain bugs like incorrect shadow direction and ghosting). Frankly, I joined this class for two reasons. One, to gain experience developing code on a larger project with a team. Second, I like computer graphics, and wanted experience writing a game renderer combining knowledge from 167,168 and 169. Especially when using a new 3d graphics API(both new to me and new in existence) with limited documentation and not just opengl, this task requires learning what goes into the boilerplate of a rasterization based renderer that 167 gave you to just focus on learning the basics of graphics concepts. I wanted to work on a game’s renderer that I could say was my own(+ Josh ofc lol), and refer to as an example of my efforts on a resume or something I could talk about when people asked about what I’ve done in computer graphics. So when the existing render came into existence, I understood its use for the team, but the addition of the advanced features made it feel like it sort of defeated the purpose of doing this project, making this game without using an existing game engine, which would’ve already done a lot of this for you. Most of the team has been pretty understanding of this and treating the existing renderer as temporary, so I appreciate that, but I also understand that they want many of the existing features in the game(particularly with particles, shadows and advanced lighting models). To not let my efforts go in vain, to get what I wanted out of this project, and to abide by the team agreement at the beginning of the quarter, I will continue to flesh out my renderer to the best of my ability. I will bank on being able to use existing code for the particles and animation, those I am fine with, (I particularly did not want to do animation). But so the rest of the team doesn’t feel like this renderer is a feature subset of the existing one, it would be really cool to work on a graphics feature not implemented by(at least that I know of lol) it. I know near the beginning we spoke about areas of the map being a portal that teleport you to other places. While not necessary for gameplay, I was thinking about implementing being able to see through the portal. I’ve done a bit of research to know how this would be done at a high level. Using a stencil buffer for the boundary of the portal, do another render pass of the scene with vertices transformed with an additional world space transform from one portal to another. It also involves other things like skewing the frustum projection to match the near plane to the plane of the portal, so that scene objects in front of it from destination space don’t get rendered. Of course there's also how to handle entities between both portals, shadows, recursive rendering when you can see another portal surface in the one you are rendering. Many other games will cheat with these as it can add significantly more rendering computation. It would be good to learn how the source engine does it at least. Since I haven’t done this before, combined with the other tasks of getting the renderer to decent parity, there's no guarantee that I will be able to achieve this, in fact it may be unlikely for all I know, but I like to be ambitious, so either doing this or something else the team wants, that doesn’t already existI think would improve my morale.
