Final Report

 

A. In the project review document, start by addressing these main questions:

  1. Game concept: How and why did your game concept change from initial concept to what you implemented?
  1. Initially, we wanted to make a 3d fps version of the original bomberman game. We planned to have different game modes, character abilities, and a lot more bombs. We ended up with only deathmatch mode and combined different types of bombs into only 5 bombs. We did not have time to implement multiple game modes and character abilities. The reason we combine the bombs is that most of the bombs share similar properties and we think it is more fun to have more than 1 property per bomb.
  2. [Robin] We were initially planning to construct a world with dynamic objects such as moving geometries and destructible. A good candidate game we can develop our idea upon was the TNT war mod of Minecraft, where the world is comprised by blocks and the blocks are free to be destroyed and moved. We spent about 2 weeks dedicated to develop our in game editor to make constructing such world easier. Unfortunately, during week 6, I suddenly realized we were developing a multi-player game. That meant no matter how polish our editor was and no matter how well we could construct the world dynamically, we simply could not put all of those dynamic objects in a multi-player context that required the server to do calculations on all of those dynamic objects in real time and send to all the clients efficiently. And we cannot afford to investigate in a different server model to make it possible. Therefore, we choose to abandon those dynamic elements and construct a static world instead.

  1. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
  1. [Martin] I feel as if our initial design didn’t change too much from what we had intended which was a first person shooter with only bombs.
  2. [Steven] One thing we did follow through from our initial design is the UI, as most of the UI stuff is what we have wanted. However, we also wanted to implement a minimap, but we find it to be unnecessary later on because our map is quite small.
  3. [Alexie] Changed Bomberman to Bombergirl at the professor’s recommendation. Also scrapped the original idea that bombs were automatically generated inside the robot. But these were just small details.
  1. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.)
  1. Well our status reports were mostly optimistic, we anticipated the time to implement many of the features, and leave some wiggle room in our schedule.  We were staying on track with our schedule for the first few weeks. However, we deviated from our schedule sometime in the middle due to various reasons, such as falling behind or being ahead on schedule, scrapping ideas due to time constraint, and re-prioritizing features to be implemented in the game. Most of the UI stuff got pushed to very late in the schedule because of this reason.
  2. [Alexie] I underestimated the difficulty of using Maya to model, rig, and animate. In particular, I wasn’t able to get the skeleton rig working, and subsequently couldn’t get any animations done. I didn’t get to do as much with the robot model as I could and wasted a lot of time.

B. Then address these more general questions:

  1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
  1. [Martin] We would meet twice a week to see how everyone was doing and if anyone needed help or talk about what we want next in the game.
  2. [Steven] We don’t always follow through in some of our meetings, as sometimes some of us would miss a few meetings because of other classes and projects, but luckily we were to fill in most of ours communication gaps through slack.
  3. [Robin] For group based decisions, we separated our team into different parts, each of which was dedicated to a specific task. I was in charge of graphics frameworks so when I was coding, I rarely thought about other aspects in the engine, such as how Wai Ho’s entity component system for the game specific management. The merit of this approach is that we reduce the coupling of our works so no one’s work was largely dependent and stalled on others’. The downside was the framework might not be scalable in a long run, since the entity component system needs to be incorporated into every aspect of the engine to easily do memory management. We finished most of our engine in week 10 but we encountered large amount of memory leaks that were hard to trace. Anyways, for the demo, we were able run the game within 15 mins without crashing. So there will always be a trade off.
  1. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
  1. [Martin] Implementing UI was a lot easier than expected since we used a library called librocket. After we had it going it was relatively simple to do
  2. [Brian] Animation was more difficult to implement that expected, mostly because animating the models the way we want them to took a long time to figure out.
  3. [Wai Ho] We thought implementing character physics in Bullet physics engine would be easy, but it turned out it is more difficult than we expected. The correct way of implementing the character physics would be to make it a kinematic object and write our own character controller, but we ended up making our character a rigid body and modifying the player’s velocity directly because it is easier. We decided to use entity component system in the beginning, but because nobody on our team has solid understanding of this technique, I ended up refactoring a lot of code throughout the 10 weeks to make our code more usable and extensible. After our backend code is stable, it is simple to add new features. Although I didn’t work on the client side a lot, I feel like it is very easy to handle key input and loading models. This is probably because we are using OpenSceneGraph, which handles most of these stuffs for us.
  4. [Steven] Modeling for the map actually took longer than expected, as we don’t have a solid map design in mind, and we ended up changing and scraping parts of the map when we do gameplay balancing. One thing I regret is scraping the Jump Pad feature I implemented, because we removed the second level of the map, we deemed it to be unnecessary and later on removed it from the game. Texturing also took a lot of time as well, mainly because I want to do create a workflow for texturing. Things like designing metallic, roughness and normal map for different of the texture requires an extra bit of effort. And later on, I found myself doing a lot of texture baking, texture atlas, and compressions in order to decrease memory usage, and improve on the graphical performance.
  5. [Robin] The in-game editor and shadow mapping in the tiled-deferred shading context.

The in game editor is just too time consuming to make so that it is production ready. There were lots of edge cases to deal with, especially for the object picker and manipulator.

The shadow mapping was exceptionally hard to implement in a tiled-based deferred shading framework. For classical deferred shading algorithm, the lights are rendered one at a time, so that we can reuse a single buffer every time we render a light. However, since all lights are rendered in one pass for a tiled-deferred shading algorithm, I need to prepare a huge 4K buffer altas for all possible shadow depth maps before the light render pass begins. This involves organizing the lifetime of a atlas slot as well as the uniform buffer object of a light to include all necessary information to index the location of the shadow depth map in the shadow atlas  Also, for point light shadow maps, I need to render the whole scene 6 times to prepare 6 shadow maps for a single point light. So, I need to do both occlusion culling and frustum culling to disable light updating for all invisible lights in order to save performance. Next, it was tricky to index the faces of point light shadow depth maps in an atlas, since the typical point light shadow map lookup directly uses a vector to find the faces in a cubemap. However, we didn’t have a depth cubemap at hand, since all the depth maps were stored in the 2D atlas. I did something really tricky to index the depth map. I used 6 single pixel images to construct a cubemap. The six images represented values of {0.0, 0.2, 0.4, 0.6, 0.8, 1.0}.  So, when the shadow calculation wanted a face, it got one of these numbers. Then, in the shader, I multiplied the number by 5.0 to get the correct face of the cubemap. e.g: 0.2 * 5.0 = 1.0, which is negative-x face of the cube. Then I used the face to find the shadow map index in the atlas by indexing into the shadow_map_indexes uniform array passed into the shader.

The whole PBR pipeline was easier than I thought. Since I did a shader manager and a basic implementation of deferred shading before the project started, it was easy for me to make changes to the shaders to experiment with different PBR rendering equations. The open source of unreal 4 engine helped me a lot as well in terms of choosing the right equation.

  1. Which aspects of the project are you particularly proud of? Why?
  1. [Martin] The UI is what I am proud of simply of how good it looks. Alexie, Phil, and I did a great job in making sure everything looked nice and to form.
  2. [Phillip] The UI and getting a HD image of Marty face into the game as the SM Bomb.
  3. [Alexie] I’m proud of the appearance of the final model, especially since I did it super quickly to make up for lost time.
  4. [Brian] I am proud of our in-game world editor since it helped us out with modifying our game world and seeing those changes directly in the game without have to export/import anything. Plus, we can reuse this editor for creating more maps if we decide to do so in the future, and it isn’t limited to the game we made in CSE 125.
  5. [Wai Ho] I am very proud of our in-game world editor plus many advanced rendering techniques that my teammates implemented. We have very nice UI and models thanks to our artist. I am also proud of the trailing effects of the bombs that I implemented, which adds some colors to our game. Personally I believe I did a good job implementing the back-end side. My teammate who has never touched the server code thought that it was relatively simple to add new features on the back-end side.
  6. [Steven] I’m proud of how we did the map and implement the lights, it gives the map and the game a unique style.
  7. [Robin] The physically based shading and an optimized tiled deferred shading renderer.

The PBR pipeline is just so powerful that enables us to make the outstanding indoor scene without manually adjust 100+ parameters of the game object to make it look nice; we only have 4 parameters: albedo, roughness, metallic, and normal interpolation.

The classical deferred shading algorithm can handle approximately 100 phong shading point lights at a reasonable performance. But we were using PBR pipeline that involves doing more gbuffer fetches per shaded pixel and more calculations for each pixel, that will make the classical deferred shading taxing. With a tiled-deferred shading algorithm, the number of buffer fetches is drastically reduced, e.g: 100 overlapping lights only needs to fetch the gbuffer 1 time instead of 100 times; also, some expensive tricks like stencil buffer culling, in classical deferred shading is not used in the tiled deferred shading context to reduce light overdraw.

What’s more, I optimized the gbuffer size to two 32bit RGBA ubyte buffer for materials and one  64bits floating point buffer for compressed normal and linear depth used to reconstruct the view space position. The tiled deferred shading algorithm enabled us to put up to 1000 dynamic PBR point lights in the scene without impacting performance drastically.

  1. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
  1. [Alexie] Autodesk Maya was hell’s incarnate. It had a massive learning curve and trying to model, rig, and animate as a complete newbie within 3 months time with other courses to do. I was able to figure out a lot about modeling from watching videos and looking things up online, but ultimately rigging took too long for me to complete. Robin managed to find some programs to automatically rig and animate our model, however, and we managed to get that done in time.
  2. [Steven] 3ds Max crashes a lot :’(, I had to learn quite a few more tools in order to do all the texturing stuff, all of which cost me a lot of time that I would otherwise be able to work on something more productive.
  3. [Robin] How to manage a large amount of shaders and how to manage shadow map update in a tiled deferred context as mentioned above.

Also, debugging shader is a huge pain.

Yes I solved all of them, except for an efficient way to debug shaders. I used a rudimentary way to debug shaders: output the color representing the value of interest. Before discovering tools like CodeXL and apitrace, which can peek the frame buffers every frame, I manually write the buffer data out as a raw image file to inspect the per-pixel data inside, which sucks.

  1. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid?
  2. How many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted.
  1. 50k lines of code total
  2. [Robin]

wc -l `find . -type f`

KaboomGraphicsEngine:

include. -> 3,476

src -> 13,275

Media/EffectFiles -> 607

Media/Shaders -> 2,485

==> Total: 19,843 (should be over 20K including the other parts I wrote)

  1. In developing the media content for your project, you relied upon a number of tools ranging from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere?
  1. [Robin] For troubleshooting OpenGL and shaders:
  1. Are you sure? Try DirectX 11 instead. The visual studio 2013 has an awesome graphics debugger for debugging directx 11. Surprisingly, it can even set a breakpoint in the shader!
  2. Look at 1)
  3. If you are stubborn, initialize your OpenGL context to core profile. With this, you can use Nvidia’s NSight to debug the shader upto OpenGL 4.0; also you can use Crytek’s Renderdoc to debug.
  4. If for some reason, you have to use compatibility profile for OpenGL, like us (since we choose to use OSG, which was built on top of deprecated opengl functions), remember, currently, there is no way to set breakpoints in shaders (after OpenGL 3.3, for 3.3 you can try a tool called GLSL-Debugger, though I never had a chance to try that) ! You have to somehow go through the process I mentioned before. Use apitrace to generate a list of OpenGL draw calls, and inspect the immediate state changes before and after a draw call. Also, use AMD’s CodeXL to inspect all the buffers used per frame, in order to know if a buffer is properly filled during an intermediate stage of your pipeline.

For our PBR pipeline:

  1. make models in 3ds max
  2. do albedo textures in 3dsmax or blender.
  1. If you hand paint textures, do it in blender, as there are lots of tutorials online
  2. do not paint lighting information in the albedo map, light specular and ambient occlusions
  3. save the unwrapped uv maps to use for roughness, metallic and normal maps

      3)  Do the roughness, metallic and normal maps

             For detailed surfaces, we hand paint them. For general purpose surfaces such as a wall, there is an convenient commercial tool called bitmap2material.

4) for a preview of pbr asset before putting them in the game editor, we use Marmoset toolbag 2, a brilliant PBR tool, to conveniently see if the textures are correct or not.

5) In 3dsmax, construct the world geometries light indoor walls and grounds. Then manually unwrap the uv to do texturing on a huge texture atlas. In this way, the objects are rendered with fewer draw calls to improve performance.

        6) compress all the textures to pvrtc or dxt1

        7) all all models in the in-game editor to assemble them.

        8) create textured materials for all models and slightly adjust the interpolations and make it look right in the game.

                

        8) add lights to the scene.

        9) profit.

For visual studio,

  1. NShader for highlighting the syntax of shaders.
  2. VA Assist X for improved auto complete and refactoring.
  3. VsVim for supporting vim keybindings in visual studio.

  1. Would you have rather started with a game engine or would you still prefer to work from scratch?
  1. [Wai Ho] Since this is my first time writing my game, I found that I learned a lot by working from scratch, but if I were to write another game in the future, I would prefer using a game engine.
  2. [Steven] I have learn quite a lot from this project as well, but I didn’t learn as much of OSG/OpenGL as I would like, because I don’t have prior experience in graphics before taking this class. So I would prefer to work from scratch to work on graphics if I can start over.

c. [Robin] I would start from scratch for the graphics part (not the level editor or game logic part).

In this project, we were using osg as our dependency for rendering. OSG is pretty optimized to handle some basic stuff, like frustum culling and reducing the draw calls taking advantage of its awesome scene graph structure.

However, there are some caveats that really bites me hard during the development.

  1. Every time you make a RTT camera for rendering to texture, by defaults, it creates 2 buffers – the buffer you assigned and an additional depth buffer the same size as the color buffer. (If you create a depth buffer, it creates an additional color buffer the same size).

        

        However, this behavior is not documented (or not easily found on its website). When I was to implement the huge depth buffer for the texture atlas, it created two 4K buffers! I only found this when our game frequently crush the driver of the demo computer. I then used apitrace and osg source code to find the duplicate of render buffer for every frame buffer object I created.

2) The whole osg is built on top of the deprecated opengl function calls. Some routines might be optimized for apis prior to Opengl 3.x and for a forward rendering pipeline. But since we are rewriting the rendering part and using deferred shading, some optimizations in osg become extra and unnecessary cost in our framework, such as the unused draw calls glLightfv(), glMaterial(), glEnable(GL_LIGHTING), etc will be called very frequently and there is no easy way to prevent them from generating.

3) Since it uses the compatibility profile of osg, if you want to use OpenGL core features, you cannot use it under Mac OS, since Mac OS can only initialize core context for features after OpenGL 2.1. This means we immediately lose the portability of our game.

4) Currently, there are no tools to debug the shader of OpenGL 4.x under compatibility profile.

However, the reason we chose to use osg is that I before 125 I was not an expert of OpenGL api so I had no idea what was the best way to reduce the draw calls. Although osg generates lots of unnecessary draw calls, it is still optimized in most cases, such as it has a osg::Optimizer class that can automatically delete all the unnecessary state changes and group geometries and send them to graphics card by batch. Also, osg has very solid utilities, such as its math classes, bounding box, polytope, intersection calculation, occlusion query, image and model loaders for nearly all the common types, etc, which speeds up our development a lot.

For the level editor, I’ll definitely use a third-party library such as the newly open-sourced sony level editor, which can be customized to integrate our own engine.

For the other parts of the game engine, I’ll probably going to find a well tested entity component framework, since these are not gonna change as frequently as a renderer would and rewriting it is just re-inventing the wheel.

  1. For those who used a networking library (e.g., RakNet or Boost) or physics library (e.g., Bullet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect?
  1. We use Bullet physics engine and we didn’t use RakNet or Boost for our networking. I [Steven] followed one of the tutorial on the 125 website for building the networking layer and it proves to be very useful later on when debugging. If you are using TCP and experiencing slowness, try turning on TCP_NODELAY.
  2. We don’t have to struggle on networking as much as we did for the Bullet library. A general advice for Bullet is to learn it early. There aren’t many tutorials on bullet and even less when you encounter issues. Learn from the example code instead. As for implementing the character controller, we looked at the btKinematicCharacterController, but ended up not using it because it’s too barebone and require us write our own collision detection between other kinematic object and rigid bodies.
  1. What lessons about group dynamics did you learn about working in such a large group over an extended period of time on a challenging project?
  1. [Martin] make constant reports and If someone is struggling with a concept or work help see if you can help them out.
  2. [Alexie] If you’re struggling with something, ask other group members to help. Wish I had done that way earlier than I did.
  3. [Wai Ho] Communicate with team members often and regularly. Discuss any struggle you face early.
  4. [Steven] Group meeting is very important, as it is the only way to know if your teammates are struggling on a particular problem or not. Also I realized most of our team are night owls, so meeting early is probably not a good idea….
  5. [Robin] Before I join the group, I need to do extensive research on graphics topics and have a vision of what the game will be like. Next, I need to write something to the other group members to show certain level of graphics is indeed achievable.

  1. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
  1. [Alexie] Start earlier, ask for help earlier, dedicated more time to the project.
  2. [Steven] Not to add more feature on the last two weeks, and should work on polishing up the game instead.
  3. [Phillip] Playtest the game more and forced more on the gameplay.
  4. [Robin] We were doing pretty well in terms of code organization, but it still needs a lot of improvement to be reusable.

Before even start coding, we should take 3 or more days (before the quarter start) to design the overall software structure of the game. It is better to have a visual representation of the whole engine like a UML diagram for each classes we are going to implement in the game.

Then, write out how a single component of the game is going to go through the whole engine and finally appears on the screen. That might be a chain of function calls going through the diagrams designed and art toolsets to use for production.

Also, I made a wrong decision on shadow mapping. I literally speet a whole week working out the shadows for our game. But I only tested them on my own desktop, which has a GTX580, and it was not at all laggy. When we were doing the dry run, the framerate drops below 30 in most cases because of the taxing point light shadows and the poor performance of the graphics card. Only one point light shadow will make the fps drops 10fps, which was unacceptable. I knew the shadow system could be more efficient, but it was already week 9 at that point and we could not afford to spend additional time to do shadows. In the end, we ditched all the point light shadows and only left the directional light shadows for the sun, which means I wasted a week on nothing substantial for our game.  

Moreover, we should have do the textures right from the point when I finish the PBR system. It ended up me, and Steven spending nearly 3 whole days (20hrs * 3) before the demo day to make the textures, do texture mappings, uvw unwrapping, combine them into texture atlas, and struggle with 3ds max quirks and pvrtc, dds compression tools crashing. I can say it was pretty close that we could not finish the textures on time and left the whole scene untextured instead.

I should have make the reflection probe freely movable in the scene right after I finish implementing the pbr reflection system. I only started doing this 12 hrs before the final demo, and I simply could not get it done with some bugs bugging me for hours. That’s why in our final demo, the reflection was actually not obvious and was incorrect on some ground with low roughness. All surface reflection was relying on the global reflection probe centered at the origin, which effectively captured the sky but not the actual indoor scene, making the reflective ground reflecting the sky, instead of the ceiling in its zone.

Should have focused more on the game mechanism. I found our game though visually appealing, but lack playability and not juicy in terms of interactivity. I guess if we made the game efficiently handle dynamic objects, the game would be a lot more interesting. That means we would need to ditch bullet engine for physics and choose a simpler physics engine that does not handle all the calculations physically correctly, but calculate fast enough to handle a lots of objects.

  1. Which courses at UCSD do you think best prepared you for CSE 125?
  1. [Martin] CSE 123 helped in terms of networking.
  2. [Steven] same as Marty, CSE 123 helped a lot in terms of network communications.
  3. [Brian] CSE 167 helped in terms of graphics.
  4. [Alexie] CSE 169 for understanding various modeling, rigging, and animation terms.
  5. [Robin] CSE 167, 169, 131, 199 (thanks to Prof. Jurgen Schulze), and UC socially dead 😉
  6. [Phillip] CSE 167 for graphics, CSE 134b for the UI since we used HTML and CSS
  1. What was the most important thing that you learned in the class?
  1. [Martin] I learned how to work as a group to accomplish a large project like this.
  2. [Phillip] Marty learned how to be a salty team player.
  3. [Alexie] Some people are very salty in life. Also, learned how to use the basics of Maya, something I’ve been wanting to do for a while now.
  4. [Robin]

1) How to speak english.

2) If you jump for the sun, at least, you can land on the moon.

That’s what we did. We imagined the graphics of our game could be like one of those AAA titles with our superb rendering capabilities from the start, so during the first few weeks, we have all the plans set up for making it possible and we worked really hard to achieve that goal. Although, during week 7, we encountered numerous difficulties and realized we could not possibly achieve that goal before the deadline, but the foundation of the first 6 weeks really prepared us to get closer to that goal.

3) Be active and make progress constantly.

 

  1. Please post four final screenshots of your game on your group pages for posterity. I will also display them on the group web page.

We need to find some picture with our particle effects.

 

image00 image02 image03 image01 image04

C. Finally, if you wish, I would appreciate any feedback on the course (entirely optional):

  1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?
  • Game engine architecture: things absolutely needed for a game engine
  • Game programming patterns
  • Real-time shadows: Although the title is about shadows, the book is a really good guide for people to really understand how real time rendering works.

  • All Shader X and GPU Pro series, if you want to make AAA graphics 🙂

  • Physically based rendering: from theory to implementation: Teach you the foundation of graphics rendering both real-time and non real-time. I always use this book to reference the equations I don’t understand in real time rendering. It also helps with the implementation of our PBR framework.

  1. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
  1. [Alexie] TO ALL ARTISTS. DO. NOT. UNDERESTIMATE. HOW LONG IT TAKES. TO MAKE 3D MODELS. AND RIG THEM. AND ANIMATE THEM. ESPECIALLYYYYY RIGGING THEM. This is assuming you don’t have previous experience working with Maya, but it also depends on how ambitious you are about your model’s final product. I wanted a really clean and smooth model that I could animate as I please, but rigging turned out to be really difficult. If you plan on doing everything yourself, the Maya Learning Channel on YouTube is great for that. Start really early and don’t waste time. If you haven’t worked with Maya before, expect a high learning curve. Here’s a general idea of how long the videos for each step are: Modelling, 1 – 2 hours. Rigging, 6 hours. Animation, 1 hour. This doesn’t include the time spent trying to find the features in Maya and actually doing the work. Something else important to consider when designing models is where the joints have to be. I recommend looking at other model schematics for reference. There’s a lot more joints than you’d think if you wanted a more complex looking model. Blender has a bit of learning curve too for texturing, so prepare for that. Look into hand painting materials if you like to manually draw in details and textures!

b. [Robin] For those who are interested in graphics:

If you really want your graphics to be outstanding: Read more, code more about graphics related things before entering into this class. There is no time for you to take more than a day to learn a completely new graphics concept during the development in 125.

There are times that you cannot hold off yourself from implementing fancy algorithms like PBR, deferred shading and global illumination without prior knowledge about these. Based on my experience, these algorithms are not at all complicated, but making them work properly and consistently requires lots of experience of setting them up in an engine. For example, simply setting up the gbuffer requires you to know at least how to render to texture, how to choose texture format for the buffer and how to control their sizes. Some tutorials of deferred shading does not care about these details and instead choose rgba32f textures for all of the render targets to make it work. It is sufficient for a simple demo with only a sphere and 10 lights in the scene, but as the game grow larger and the shaded pixels need to cover the whole screen, the graphics card memory bandwidth and size will become the bottleneck if all the targets are rgba32f, and you just don’t know what happened to drag down your fps. Due to extreme frustration, you may end up implementing them half complete and never got a chance to show them or at least make the effect obvious. That’s what I experienced before the class, but these experience is invaluable when I actually develop the engine in 125.

I personally spend at least half an hour reading technical blogs about rendering before sleeping. Here are some recommendations:

This guy is a developer of The Order 1886.

Two resources helped me the most:

  1. Its shadow mapping technique demo
  2. Its position reconstruction from depth demo

https://mynameismjp.wordpress.com/

I learned how Unreal 4 did PBR in a siggraph course in this blog

http://blog.selfshadow.com/

Some neat and easy techniques, such as the flow map of water, and dual parabolic shadow map.

http://graphicsrunner.blogspot.com/

I implemented the tiled-deferred shading in these slides.

https://software.intel.com/sites/default/files/m/d/4/1/d/8/lauritzen_deferred_shading_siggraph_2010.pdf

http://www.slideshare.net/DICEStudio/directx-11-rendering-in-battlefield-3

A lot of PBR stuff. Helped me out on implementing reflections.

https://seblagarde.wordpress.com

A collection of research papers published in Siggraph, i3D, EG, etc. Terrific and most up to date real time rendering resources.

http://kesen.realtimerendering.com/

Wolfgang Engel’s blog. A lot of optimization tricks.

http://diaryofagraphicsprogrammer.blogspot.com/

ShaderToy: enjoy the amazing shaders written by extremely smart people.

http://www.shadertoy.com

Documentation of Unreal 4. Really useful to know what are the best effects you can possibly make.

https://docs.unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/LightTypes/SkyLight/index.html

Gamedev forum:

http://www.gamedev.net/index

A collection of industry people’s blogs:

http://svenandersson.se/2014/realtime-rendering-blogs.html

  1. How can the course be improved for next year?
  1. [Martin] This course can be improved by having former students come back and talk about their experiences and what libraries they used. Having Jake come in and talk was great but only gave us one perspective of it.
  2. [Alexie] Agreed with Marty. I really wish I could have heard from previous artists what programs they recommended and also general model design.
  3. [Wai Ho] Lecture in afternoon instead of morning.3
  4. [Robin] For the guest lectures, I think it might be more useful for us to have technical ones that are not too hard for us to implement.

The first guest lecturer from blizzard talked really deeply of how the network works in a blizzard game. But that was actually not very useful for our purpose. Instead, it might be better to let the guy talk about some general problems we might encounter in a small scale game like the one we developed.

A real example of what we actually need is how to correctly set up the Entity component system. There are numerous tutorials online on this topic but different tutorials has different mindsets of doing that, making us wonder if some of the authors really understand what is entity component system. We ended up a customized or “imagined” version of entity component system that fits our need, but we never knew if we were doing it correctly or if it was scalable in a long run.

Also, it would be nice to have some classes focusing on optimizing the Microsoft C++ compiler settings and how to efficiently manage the headers.

As our codebase was enlarging overtime, we find our compilation time was too long. For a clean build, it needs at least 4 minutes to build on the demo computer using Core i7 950, a very decent cpu. I did build some other source code similar in size using visual studio. It was taking less time than ours. I guess there should be a specific compiler setting that speed things up.

Also, the header management was really bad in our game. Lots of files include headers that are frequently changed; so if the header is modified, all associated files are going to be recompiled, which takes a lot of development time. It would be great to have lectures on organizing header files and program structures so that the dependencies are minimized.

Moreover, it would be great if we can have a lecture on how to do a robust and flexible logging system to trace bugs in a real time environment.

New graphics card… It’s already 2015 and the GTX460 on the demo machine is a mid-end card released 5 years ago, and the graphics cards in the lab computers are only slightly more performant than my integrated graphics card in my laptop. If the graphics card can be more performant, like a mid-range GTX760 in 2015, we can enable 6 or more shadowed point lights without lagging. A good thing about a slow graphics card is that I know the algorithms or settings are not efficient enough. But that’s all. In 10 weeks, it is hard to make everything optimized. When developing on a laggy computer, I usually feel really frustrated and reluctant to move on, always thinking my implementation is crap… (even though it is)

  1. Any other comments or feedback?
  1. [Alexie] Thanks for an awesome quarter! I had a lot of fun.
  2. [Martin] Woot I got a degree.
  3. [Steven] Thanks for the donuts, it was a great moral boost! 😀
  4. [Robin] This is the class that makes me confident enough go the graphics route in the next couple of years. Thank Professor Voelker for the awesome class and thank all the members in the Salty Marty group.

 

 

Week 9 Report

Group Report

1) summarize your overall status for the week

Our game is coming together, we still have stuff to finish up. HUD is coming along. Texture is still being work on.

 

2) include both the week # and the date of the meeting

June 1. 6:30pm

 

3) add a statement summarizing the group morale (feel free to be creative

in expressing your morale) The salt is getting to Marty. He is going crazy. He wanted to change the salt marty bomb into an 18+ bomb…. Besides that everyone is feeling good and bit nervous since the deadline is coming up.

 

4) add at least one of your latest screenshots to your group page

image00

 

 

 

Phillip Ho

  1. Finish up the rest of the UI with Marty and anything else my teammates need me to help on. see above.
  2. Swapout html HUD for image based HUD, looks a lot better now. Added the feature of entering a username for your character. Added a respawn button. Fixed up score board so that it remove disconnected players from the board.
  3. Was not able to finish up pre-game and end-game screen because changing the HUD to image based took a lot longer to position correctly, ran into bugs for respawn, where all players get move to the respawn screen when one person dies.
  4. Finish up swapping out HUD with images to improve the looks(transparent version) and finish up end-game screen and pre-grame screen.
  5. Good and nervous

 

Brian La

  1. Disable rendering the player’s own model. Find where and when to swap between idle/running animations (may need to add/modify network events so I will need help on that). Testing and bug fixes.Any in-game editor changes. Create more character animations if able to swap multiple animations.
  2. Got multiple animations to work and made it possible to swap between them (idle/running). Extended the export feature in the in-game editor to copy the current directory into a new one, including the modified world file. Exporting textured materials also includes every property that can be modified in the editor. Made a first-person running animation and a first-person shooting animation (models that only have arms).
  3. Did not disable rendering the player’s own model since we want to have each player see their arms moving while running/shooting in first-person. To do so, we’ll replace the current model with the arms-only model.
  4. Replace the player’s own model with the first-person animation models (More tricky because we have to make a nested camera and place the model in front of that camera). Once I am done with that, I will focus on gameplay testing, balance testing, bug fixes, and helping my teammates with things that need to be done.
  5. Waiting for the rest of my team to write their reports.

 

Alexie

1) Finishing textures and UI, bomb crates

 

2) UI is done, Should have textures on character model done tonight!! Will then quickly move onto bomb crates

 

3) iFor once I met almost all of them. I didn’t finish texturing (and thus didn’t get to bomb crates) because I was having issues with unwrapping the UV, but Robin and Steven figured out a way to do a clean auto-generate of the model’s UV map so I’m currently texturing that. Also spent a while working on UI. But should have everything done in time for the final showing!

 

4) HAUL ASS TO FINISH UP THE GAMEEEEEE

 

5) Pumped yo

 

Martin La Pierre

1) what were your concrete goals for the week? The goals of the week were UI and Audio

 

2) A little bit of both looking good now though

 

3) Still working on both but audio is basically done and UI only needs a few touch ups

 

4) Finish UI and Audio

 

5) Fear I may overdose on salt.

 

Wai Kit Leung

1) Fixing bugs, added client respawn on the server-side. Improve the map models, and apply texture to the map

 

2) Fixed most of the bugs, and finish the player respawn. Still need more work on applying texture onto the map.

 

3) Mapping texture coordinates took longer than expected, b/c the model of the map is circular and cylindrical, and most of our texture is squares, so I have to manually edit the unwrap uv coordinates to make it work.

 

4) Finish texturing and add some more model and finish the game

 

5) Almost there….

Wai Ho Leung

  1. Fix bug where player is able to shoot through walls. Balance gameplay. Adjust explosion particle size base on explosion radius. Fix bug where explosion effects get blocked by the map. Send running/jumping status to clients.
  2. Fix bug where player is able to shoot through walls. Adjust explosion particle size base on explosion radius. Fix bug where explosion doesn’t hit player if the bomb was spawned near player. Add random spin to newly spawned bombs. Investigate into why server is crashing. Add trailing effects. Add chat event. Fix timer. Fix crashing issue again. Fix trailing effects can be seen through walls. Fix timer not synchronized across machine. Lower Kaboom 2.0 explosion effect. Create fake pickup. Create salty marty bomb. Make pickup rotate. Fixed looking through wall issue. Fixed particles can be seen through wall issue.
  3. All goals were met.
  4. Finish the game.
  5. Finally done with the project.

 

 

Zonglin (Robin) Wu

1) Bug fixes. Optimize shadow maps. Texturing.

2) Suppose to. All except texturing

3) Texturing takes longer than expected. Need to learn different software to do good looking textures.

4) Continue doing textures and debugging.

5) LoL

Week 8 Report

Week 8 report

Group Report

1) Still working on animations (almost done!), designed our game map, added more UI stuff

 

2) (Week 8) Monday 6:30 PM; 5/25/15

 

3) Chugging energy drinks; while Marty chugs his salt.

 

4) add at least one of your latest screenshots to your group page

image00

image02

 

Robin:

1.what were your concrete goals for the week?

Implement shadows for directional light, point light and environment light in the tiled-deferred shading framework.

Tron / sci-fi like emissive materials.

 

2.what goals were you able to accomplish?

Whole shadow manager and shadow caching mechanisms.

Point light shadows and ambient occlusion with temporal filtering.

image01

  1. if there were goals you were unable to meet, what were the reasons?

Directional light shadow. Sci-fi area light.

 

Burned out with designing a scalable shadowing system that works both indoor and outdoor in tiled-deferred framework without obnoxious shadow artifacts as well as achieving reasonable performance.

Fighting with opengl quirks such as uniform buffer objects.

 

  1.  what are your specific goals for the next week?

Finish what I left off.

Texturing the map.

Post processing.

Help more with animations.

 

  1. Weekly morale:
  • Never thought doing shadows in Tiled-deferred shading can be so difficult. Due to tiling where the all lights are rendered in one pass, all shadow depth maps need to be in place before doing depth testing in the lighting pass.This requires careful culling of lights and caching of these shadow maps to make the shadow algorithm efficient.

 

  • Uniform block sucks!

 

std140 struct {

vec3 pos;                  // 3N

float padding;            // N

float shadowIdx[6];    // 24N wtf !! ? My whole morning was ruined.

}

 

Wai Ho Leung

  1. Support several game matches. Implement jump pads and teleporters. Send deaths/respawn events. More bombs. Send player position for minimap.
  2. Support several game matches. Send deaths/respawn events. Send player position for minimap. Send pickup item spawn event. Add functionality in backend for renaming players. Refactor sound related code. Fix bug where client crashes after join. Fix bug where players are able to shoot their feet when looking down. Fix all known network issues.
  3. Another teammate wanted to implement jump pads and teleporters. We decided to keep number of bombs at 3 for now.
  4. Fix bug where player is able to shoot through walls. Balance gameplay. Adjust explosion particle size base on explosion radius. Fix bug where explosion effects get blocked by the map. Send running/jumping status to clients.
  5. Ok.

 

 

Brian La

  1. From last week’s report: Disable rendering the player’s own model (can currently see its body parts like the legs). Work on the map and any graphics stuff that needs to be done or fixed. Any fixes/additions to the in-game editor, if needed. New goals created during the week: Create animations from our static character model. Utilize our Type-ID XML to load files (along with other info) for our character, bomb, and item pack models
  2. I made several animations (idle, running) for our robot model and modified the Model class to store multiple (animated) models and be able to swap between animations. These models are defined in the Type-ID XML and stored into each player. Also contributed in the map design during team discussion.
  3. I have not yet figured out how to disable rendering the player’s own model since I am too familiar with the structure of our entity-component system. I will ask someone who can help me with that as I also need to find the where and when to swap animations within the system. Overall, my main goals shifted to animation within the week as we have decided that Alexie should be focusing on other things after spending quite a while with the character model. Robin found several software that can help generate animations for an input model, so it took me a while to get familiar with the software and experimenting with our model.
  4. Disable rendering the player’s own model. Find where and when to swap between idle/running animations (may need to add/modify network events so I will need help on that). Testing and bug fixes.
  5. Wish I was more productive

 

Martin La Pierre

  1. Finish up UI and Audio
  2. making progress on both not done yet
  3. Chunked out UI and audio was tweaked but overall
  4. work on finishing the two UI and Audio
  5. Salty as ever

 

Phillip Ho

  1. Finish most UI with Marty and swap out sphere with bomb model with the help of Brian
  2. Pickup is just using bomb models, but we want to switch that out with crates
  3. Timer is not done because there were some delay on implementing it on the server side.
  4. Finish up the rest of the UI with Marty and anything else my teammates need me to help on
  5. Good

 

Wai Kit Leung

  1. Added some more game logic stuff like player dropping pickups, and healthpacks. I am also doing the map re-design.
  2. Finish all the game logic stuff. Still working on the redesign of the map.
  3. Have some proportionally issue early on when designing the map, I’ve finished the inner and outer layer, just need to connect them together.
  4. Working on applying the texture to the map, and work on audio if I have time left
  5. Aright.

 

Alexie

1) Texturing and Animations, bomb models, crates

 

2) Finished the bomb models and also made some UI images for the bombs. Didn’t really get around to texturing

 

3) Needed to learn a little bit about PBR. Also was at a convention selling art from Thursday night until Monday night and work time was almost non-existent. I did at least look over PBR so I could do some stuff when I got back Monday night.

 

4) Finish texturing and UI stuff

 

5) Glad that Robin found an alternative to animations! Feeling like I can finish something now (after I catch up on some sleep)

Week 7 Report

Group Report

1) summarize your overall status for the week

Get a general UI working, some sort of animation, simple map layout, player can switch bombs and respawn, editor bug fixed, improved graphics.

 

2) Monday 6:30; 5/18/15

 

3) add a statement summarizing the group morale (feel free to be creative

in expressing your morale)

Marty is high on salt, beside that feeling great.

 

4) add at least one of your latest screenshots to your group page


image04

image02

image00

image06

image08

image01

image05

Wai Kit Leung

1) what were your concrete goals for the week?

Player Spawning. Creating the Map layouts and models, apply texture to it, and have it render in game. Fix some more bugs both client-side and server-side.

2) what goals were you able to accomplish?
All the above except loading texture to the game.

3) if there were goals you were unable to meet, what were the reasons?
I have difficulties in porting the texture I applied in 3ds Max and to the game. The thing is we want to minimize the amount of draw calls for our game engine, so we want to compact all the uv map texture to just one file. and so far I haven’t been able to figure out how to do that.

4) what are your specific goals for the next week?

Hoping solve the texturing issue, start working on the SoundManager, do some more game logic like jump pads (or teleportors). If I have time I’ll work on more modeling for weapon pickups, etc.

5) what is your individual morale (which might be different from the overall group morale)?

Stressful, we have so much more stuff we want to do, I don’t think we will be able to finish them all on time. Possibly we would have to cut features.

Wai Ho Leung

  1. Add sticky property to remote detonator. Make time bomb bounces higher. Implement weapon switching functionality.
  2. All of the above. In addition, added functionality for keeping track of score. Fixed remote detonator bomb not being destroyed after player dies. Added functionality for removing/killing entities that go beyond map boundary.
  3. All goals were met.
  4. Support several game matches. Implement jump pads and teleporters. Send deaths/respawn events. More bombs. Player position for minimap.
  5. Tired.

 

 

Brian La

1) Continue working with the animation system and integrate it into the game. More fixes/additions to the in-game editor, if needed (currently it needs to have multiple export destinations rather than just one fixed path).

 

2) Replaced the player capsule-shaped model with our actual model. Investigated in animation options and reached the conclusion of swapping animations (i.e. walking, idle) rather than attempting to interpolate animations for transitions. Added a GeometryCache that loads each file only once, but can generate multiple models from it.

 

3) Main goals were met, although I could have worked on more stuff.

 

4) Disable rendering the player’s own model (can currently see its body parts like the legs). Work on the map and any graphics stuff that needs to be done or fixed. Any fixes/additions to the in-game editor, if needed.

 

5) I can start to feel the rush.

 

 

Phillip Ho

1) UI for in game and Start-screen; particle system

2) The core UI are there. Could have made it look better, but that will be put on hold for now. Need to finish up score board screen, which can be seen by holding tab. and end game screen. Particle system was finished up by Robin.

3)

4) Finish up UI, so in this case Score board screen and end game screen. Mini-map

5)  Good

 

Martin La Pierre

1) UI for in game and Start-screen; audio system

2) UI is there didn’t have much time to work on audio.

3)  Getting help to work on it this week but last week didn’t have much time since surgery

4) Finish up UI and Audio

5)  Salty

 

Alexie

1) what were your concrete goals for the week?

  • animation
  • texturing
  • rigging
  • bombs and crates

 

2) what goals were you able to accomplish?

  • I’M ALMOST DONE WITH THE RIGGING I JUST HAVE TO MIRROR IT NOW. AND THEN ANIMATION WILL BE EASY I SWEAR I’LL HAVE THIS DONE BY MIDNIGHT SO MY GROUP CAN THROW IT INTO THE GAME I’M SORRY

 

3) if there were goals you were unable to meet, what were the reasons?

  • Schoolwork. Lots of it.
  • Stress overload
  • Housing is literally the worst thing in the entire world can I just get a nice cardboard box and shack it up underneath the i5
  • I did the thing where you get a lot of work done and then screw up something major and that messes everything up and you didn’t save so you had to redo all of it.
  • I tried to hard to have nice physics in the animations and then I realized I didn’t really need it (or I didn’t have time to learn all that)

 

4) what are your specific goals for the next week?

  • Texturing!
  • Bombs and crates
  • UI design
  • This is all actual artsy stuff so I HAVE NO EXCUSE.

5) what is your individual morale (which might be different from the overall group morale)?

  • Tittering on the border of stress overload and super motivated?? I will get stuff done I don’t like being a disappointment.

 

 

Zonglin (Robin) Wu

1) what were your concrete goals for the week?

  • An efficient occlusion solution for the global illuminated scene.
  • Improved material system so that materials can be more expressive by interpolations. Also, created interface for dynamic material support.
  • Fixed normal mapping
  • Implemented particle system, explosion and  trailing effect.
  • Find ways to make use of online art assets.
  • Refactored game gui client interface
  • Fix most noticeable bugs in the editor so that it will not block the development of the map

 

2) what goals were you able to accomplish?

  • Nearly all. For the occlusion, I implemented a variant of SSAO for indirect lights that does not eat up gpu resources. For direct illumination occlusion, I come up with a method that eliminating obnoxious shadow mapping artifacts, so hopefully a robust shadow mapping can be implemented soon.
  •          image03
  • image07

 

3) if there were goals you were unable to meet, what were the reasons?

  • debugging…

 

4) what are your specific goals for the next week?

  • Make the map
  • Make the map
  • Make the map
  • Emissive materials.
  • All sorts of mainstream post processing effects.

 

5) what is your individual morale (which might be different from the overall group morale)?

  • I am gonna be super productive this week. ~~

 

 

Week 6 report

1) summarize your overall status for the week
Overall status is that we all worked on minor things that will come to fruition later in the project. Things such as beginning map design, implement library for UI, and creating multiple bomb types.

2) Monday 6:30; 5/11/15

3) add a statement summarizing the group morale (feel free to be creative in expressing your morale)

MARTY is SOOO SALTY this week!!! that if he was water, you could walk on him.

4) add at least one of your latest screenshots to your group page

image07

~ Light Visualizer

 

image03    image01

~ Robot and bomb Models

image05image00

~ New GUI  

image04

~ Visualizing Collision Detection

 

===========================================================================

Individual Report

Robin (Zonglin) Wu

1) what were your concrete goals for the week?

  • Construct a small demo scene.
  • Make a tutorial for creating the world.
  • Compress textures.
  • Post processing.

2) what goals were you able to accomplish?

None above….

But I finished

  • Integrated in game GUI system. With editor GUI and in game GUI separated.
  • Construct an textured infinite ground.
  • I finished jumping logic.
  • Fixed some bugs in the editor
  • Created light visualizer so that we can control lights in the editor.
  • Fixed a severe rendering bug that the edges of the geometries in the scene are not correctly shaded.

3) if there were goals you were unable to meet, what were the reasons?

  • Debugging Editor is time consuming.
  • Debugging shaders………………………… – -!
  • There are different tasks constantly showed up.

4) what are your specific goals for the next week?

  • Finish what I left off this week.
  • Shadow mapping.

5) what is your individual morale (which might be different from the

overall group morale)?

Github will say this is a feature, not a bug…..

 image06

Alexie

1) what were your concrete goals for the week?

  • Redo model
  • Rig model
  • Animate model
  • Bomb models/textures
  • Crate models/textures

2) what goals were you able to accomplish?

image02

  • Redesigned model (I made into robot girl)
  • Basically done with model! Just need to add hands/hair and then mirror it.
  • One bomb model (designed the others though)
  • I did a really simple animation of one leg moving forward and back to feed into the pipeline to make sure it works.

3) if there were goals you were unable to meet, what were the reasons?

  • I had numerous club events running this weekend that I had to manage so I barely did anything during the weekend.
  • Redoing from scratch took a while regardless, but I managed to get to most of the stuff this week. Rigging shouldn’t be take too long now that my joints make sense (I hope to get done with that tonight so I can start animating tomorrow during the meeting!). Animating will probably be the most fun for me. I enjoyed the little animation I did this week a lot.

4) what are your specific goals for the next week?

  • Do all animation sequences
  • Finish bomb models
  • Texturing of various things

5) what is your individual morale (which might be different from the

overall group morale)?

  • sleep deprived but feeling way better about what I’m getting done

 

Wai Ho Leung

  1. Implement time bomb and remote detonator bomb. Send network events, such as weapon/powerup pickup, score, and other events to client. Implement a way of keep track scores on the server/client.
  2. All of the above, except score-related tasks. In addition, refactored server code to allow better extensibility.
  3. The score-related tasks depend on another team member’s progress.
  4. Add sticky property to remote detonator. Make time bomb bounces higher. Implement weapon switching functionality.
  5. 🙂

 

Wai Kit Leung (Steven)

  1. Have the server load the collision shape base on the osg model. Added a few simple 3d models and a debug viewer to see the collision shapes. Spawning for bombs, and players. And a few minor changes here and there.
  2. All except spawning
  3. Didn’t get to it in time
  4. Got to finish spawning finally, and work on creating the maps, and fix some more game logic bugs.
  5. So-So

 

Martin La Pierre

  1. Planned on working audio and user interface
  2. Chipped away at both but they still need a bit of work before completion should be done soon though
  3. Reasons where all personal shouldn’t of interfered with my work but it did and I will try and make up for it
  4. Finish user interface and audio system
  5. Salty as ever

 

Brian La

1) Expand on the current animation system so that it can handle transitions between animations. Maybe a couple fixes/additions to the in-game editor, depending on its current usability.

2) Lots of modifications/additions to the in-game editor, such as copy/paste and undo/redo, as well as bug fixes for the editor.

3) Didn’t have much time to play around with the current animation system due to features/bugs for the editor that needed/desired to be addressed.

4) Continue working with the animation system and integrate it into the game. More fixes/additions to the in-game editor, if needed (currently it needs to have multiple export destinations rather than just one fixed path).

5) Salty since TSM did not wonnered.

Phillip Ho

1) UI for in game and Start-screen; particle system

2) So worked with Marty on the UI but was not able to finish everything. Particle system was putted on hold because of UI.

3) Was not able to finish because we had to spend some time to learn how to used libRocket, which took longer than we expected, but we got a good understanding now and should be able to finish it soon.

4) Finish up UI and particle system.

5)  OK

 

Week 5 Report

Group Report

1) summarize your overall status for the week

Fixed networking issues, implemented audio, bombs blow up on contact,working in-game editor

 

2) Monday 6:30; 5/4/15

 

3) add a statement summarizing the group morale (feel free to be creative

in expressing your morale) Marty feels happy salty. Everyone is “Feeling Great!” and tried. Everyone drunk from sun god. May the heavens heal this hangover.

 

4) add at least one of your latest screenshots to your group page

Untitled

image00

image01

 

Robin (Zonglin) Wu

 

1) what were your concrete goals for the week?

  • Finish the reflection probe system. Currently we can place the reflection probes in the scene. Reflection’s detail will change corresponding to the property of the surface (roughness, metallic)
  • Finish Light-weight global illumination. Currently, can receive natural light from the skybox

(not real-time, but it doesn’t matter since we are not using dynamic sky)

  • Check the math and fix the lighting model.
  • Able to load HDR files so the reflection will be more realistic.
  • Implement screen-space reflection,

 

2) what goals were you able to accomplish?

  • All, but not the screen-space reflection.

 

3) if there were goals you were unable to meet, what were the reasons?

  • Editor still need some polishment to be usable. But I think a good way is to fix it while we are making the map, since we cannot afford to spend extra blocks of time on the editor.
  • Real time SSR is bit tricky to integrate into the current reflection probe system. Figuring out how that works may take a lot of time, so I want to postpone the implementation.

 

4) what are your specific goals for the next week?

  • Construct a small demo scene.
  • Finalize the art pipeline. Hopefully make a tutorial.
  • Improve the editor while I am making the scene.
  • Improve the current material system, storing different maps into separate channels of a combined material texture, so that
    • 1) drastically reduces graphics memory usage
    • 2) flexible in terms of the existing shader system, so that we don’t need to write different combinations of GBuffers for different combinations of texture inputs.
  • Find a way to place reflection probe in the scene visually.
  • Plan for HDR for better shading, glow effects for emissive materials and shadow mapping for occlusions.

 

5) what is your individual morale (which might be different from the

overall group morale)?

  • Want to eat something better than the food in price center.
  • Want to get a better mouse. :<
  • F___ the graphics driver issues !

 

Alexie

 

1) what were your concrete goals for the week?

-finish animation

-simple skin

-bomb models

 

2) what goals were you able to accomplish?

-nothing

 

3) if there were goals you were unable to meet, what were the reasons?

note that this happens regularly…I would prefer you to be

aggressive in what you want to try accomplish rather than limit

yourself to goals you know you’ll easily achieve. so answering

this question is more of a reflection on the development process

and the surprises you encounter.

-I don’t really have any excuses. Rigging was unexpectedly unsuccessful but I didn’t work long or hard enough on it to fix it in a timely manner. I guess I had a midterm and SunGod weekend made it harder to work, but not necessarily an excuse. I was just lazy and unproductive this week.

 

4) what are your specific goals for the next week?

-Same as last week…

 

5) what is your individual morale (which might be different from the

overall group morale)?

-Like crap. Disappointed in myself for not doing more.

 

Wai Ho Leung

  1. Study bullet physics library on collision detection. Detect and handle bomb explosion on both server and client side. Extract player and bomb configurations to XML files.
  2. All of the above. Additionally, setup foundation/infrastructure for handling collision. Added functionality for detecting entities within an area. Added functionality for removing exploded bombs on client. Added functionality for picking up weapons on the ground. Extracted hard-coded constants for bomb and player to XML files. Added a upper limit of how many bombs a player can hold. Fixed network lag issue. Refactored a lot of code to allow better scalability and extensibility for different kinds of bomb.
  3. All my goals are met.
  4. Implement time bomb and remote detonator bomb. Send network events, such as weapon/powerup pickup, score, and other events to client. Implement a way of keep track scores on the server/client.
  5. =D

 

Wai Kit Leung (Steven)

  1. Work mostly on game logics, Implement inventory for bombs, knockbacks for bombs, health/damage system, spawn system, added a way to keep track of player status.
  2. all the above except spawning
  3. Didn’t get to implement spawning because of time, I blame sun god.
  4. Setup a simple room with texture, staircase, and objects. Have the server preload the map (for  collision) using xml. Finish spawning system, work with Marty on implementing the UI for spawning, and if I get to it, create some texture, some models for bombs/objects.
  5. Making progress, but there is so much stuff I still need to do. X_X

 

Martin La Pierre individual report

  1. Implement an audio system
  2. Implemented an Audio system
  3. met goals
  4. More work on audio and try and help with UI
  5. Salty/Very Salty/So much salt

 

Brian La

1) Finish implementing the main features of the in-game editor.

2) Finished implementing the main features of the in-game editor.

3) Finished my main goals of the week. A couple bugs/wanted features came up along the week, some of them I am holding off for the meantime as they are not that critical.

4) Expand on the current animation system so that it can handle transitions between animations. Maybe a couple fixes/additions to the in-game editor, depending on its current usability.

5) Indifferent

 

Phillip Ho

1) Focusing on setting up the particle system.

2) Got a basic particle system working.

3) The explosion particle is not exact the way we wanted it to look like. This just require more playing with the different numbers. Integration is not done yet since I have not full finish the particle system.

4) Finish up particle system and work with Marty on HUI.

5) Good.

Week 4 Report

Group 3 Week 4

 

Group Report

1) summarize your overall status for the week

Project have been merge, and we are able to switch between edit mode and game mode. Pretty much on track with our schedule. Modeling animation is a bit behind?

 

2) Monday 6:30; 4/27/15

 

3) add a statement summarizing the group morale (feel free to be creative

in expressing your morale) Marty feels happy salty. Everyone is “Feeling Great!” and tried. Everyone is also excited for SunGod!

 

4) add at least one of your latest screenshots to your group page

image02

Zonglin (Robin) Wu

1) what were your concrete goals for the week?

Implement reflection system.

Add more features to the in game editor.

 

2) what goals were you able to accomplish?

Reflection 40% percent finished – reflection probe.

The added features in the game editor.

Current progress:

image01

 

3) if there were goals you were unable to meet, what were the reasons?

note that this happens regularly…I would prefer you to be

aggressive in what you want to try accomplish rather than limit

yourself to goals you know you’ll easily achieve. so answering

this question is more of a reflection on the development process

and the surprises you encounter.

Reflection is not fully done. Busy with integrating the camera with the server.

 

4) what are your specific goals for the next week?

Complete the reflection system.

 

5) what is your individual morale (which might be different from the

overall group morale)?

Fatigue.

 

Alexie

1) what were your concrete goals for the week?

  • Finish model
  • Skin/texture the model
  • Animate model

 

2) what goals were you able to accomplish?

  • Finished the model! (at least something that has a head, arms, legs, etc.)
  • Looked over all materials for PBR pipeline texturing that Robin gave me
  • Started rigging and animating (Realized there were many things to consider when animating, like IK, FK, or just keyframe. Seems like we want keyframe for now.)

 

3) if there were goals you were unable to meet, what were the reasons?

note that this happens regularly…I would prefer you to be

aggressive in what you want to try accomplish rather than limit

yourself to goals you know you’ll easily achieve. so answering

this question is more of a reflection on the development process

and the surprises you encounter.

  • Rigging and animating is another monster, so had to look up more videos(And very few were in reference to rigid robotic parts)
  • Also spent a lot of time looking at materials for PBR, but realized probably wasn’t necessary to do anything overly complicated for the time being since the final model isn’t done

image00

 

4) what are your specific goals for the next week?

  • Have an infinite loop animation of the robot walking
  • Very simple texturing done to at least make sure that works
  • Bomb models for regular bomb, time bomb, and remote detonation bomb
  • Bomb crate models + textures for each bomb type + fake bomb crate texture

 

5) what is your individual morale (which might be different from the

overall group morale)?

  • Feels like I’m getting more done, but still very slowly. Have projects and midterms due this week, so will be kept very busy between this class and my other ones.
  • Not entirely sure how I feel. Guess I’ll keep pushing and at least try to get what I wanted done this week because the deadline is fast approaching. I feel like it should be faster starting this week since I got more used to Maya and its functions (and learning Blender doesn’t seem too bad) so hopefully subsequent models/etc won’t take as long.

 

Wai Kit Leung(Steven)

1) what were your concrete goals for the week?

Added logic for spawning bombs (sphere) on user input. Added some spawn and delete entity function. Added functionality for client disconnect and reconnect. Added several walls and ramps to test the physics. Research a bit more on bullet.

2) what goals were you able to accomplish?

All the above

3) if there were goals you were unable to meet, what were the reasons?

note that this happens regularly…I would prefer you to be

aggressive in what you want to try accomplish rather than limit

yourself to goals you know you’ll easily achieve. so answering

this question is more of a reflection on the development process

and the surprises you encounter.

None so far

4) what are your specific goals for the next week?

Implement Timing functionality, Import xml to bullet and create custom collision shape using meshes. Implement custom collision detection, create weapon pick up logic, and create several bomb models(if I have time). Improve the character collision.

5) what is your individual morale (which might be different from the

overall group morale)?

So far so good.

 

Phillip Ho

1) Finish merging camera. Work on start screen and HUD.

 

2) Camera is integrated. Start screen and HUD was puted on hold. Looked into particle system for osg and started setting up the classes.

 

3) Start screen and HUD was puted on hold.

 

4) Goal: get particle system working and integrated into the system.

 

5) Feeling good.

 

Wai Ho Leung

  1. Implement basic bomb model. Be able to spawn a bomb. Research on how to implement physics.
  2. All of the above. Throw bombs at the direction the player is facing. Load bomb definition from XML file. Implement rotation for players and bombs. Fix bugs regarding disconnecting players.
  3. All goals were met.
  4. Study bullet physics library on collision detection. Detect and handle bomb explosion on both server and client side. Extract player and bomb configurations to XML files.
  5. Feeling good

Martin La Pierre

1) add jetpacks and handle collision detection.

 

2) added jetpacks

 

3) if there were goals you were unable to meet, what were the reasons? bullet is a bit difficult to deal with at times.

4) what are your specific goals for the next week? add sound get collision detection

 

5) salty

 

Brian La

1) Add various functionalities for the in-game editor: export world scene to an XML file, add/remove a model, add/remove lights, add/remove materials, rename items, make lights pickable.

 

2) Implemented the functionalities: exporting scene to XML, adding/removing models, adding/removing lights, renaming items.

 

3) I couldn’t get to implement all of the desired functionalities in time, due to other classes (midterms and assignments). Also, it took a while to figure out how to load files through a Windows dialog. During the week, we had found issues and concerns about the editor that will need to be addressed, such as the XML needing to store/load a model’s scaling info.

 

4) Finish adding all of the in-game editor functionalities.

 

5) Feeling good for now.

 

Week 3 Report

image00 image02 image01

Group Report
1) summarize your overall status for the week
Still on track of the schedule. Merging the different branches, but need to finish up connecting/wiring the interaction.

2) date of the meeting: 4/20; 6:30

3) group morale
Baked (4/20); Marty is still as salty and Hai as ever!

4) add at least one of your latest screenshots to your group page

 

Individual
Martin La Pierre
1) Implement agreed upon protocols. Fix multiplayer. implement more physics.
2) Implemented agreed upon protocols. Fixed multiplayer.
3) We didn’t fully implement physics with ground detection and the ability to jump.

4) work on sending camera info over network, title screen, player disconnect(remove entity), bullet research, chat system , and if time conquer the world(only if we have extra time)
5) *silence*

Phillip Ho
1) First person camera.
2) Yes, I was able to accomplish the basic implementation.
3) I was not able to merge my camera after the big merge. I just have to read over the new merge code and connect it properly.
4) Connect my camera logic to the game; learn set up of entity-component in our project; start setting up Start Screen and HUD with Marty and Steven.
5) Doing well. Got a sick a bit overweek :(. Hopefully the sickness stop passing around.

Brian La
1) Be able to load a “world” file in XML format into the scene. Also be able to export the world scene into an XML file. This file contains models, materials, and lights. Each of these objects can have their properties modified with the in-game GUI editor. Merge my Model class with the main branch
2) Loading an XML file into the world scene. Exporting the world scene into the XML file.
3) Did not merge the Model class with the main branch yet, since all of the branches were getting merged over the week as well as implementing the entity-component system. Also, I was out of town for several days.
4) Implement more features for the in-game editor: load/remove models, change the textures of models, add/remove lights. Merge everything I have with the main branch. Learn the entity-component system.
5) Feeling alright. I’m starting to see the workload build up this week (along with other classes).

Wai Ho Leung
1) My goals were to render player falling onto the ground. I also aimed to improve and organize the existing networking code so that it can handle incoming network events better.
2) I was able to make the players falling onto the ground. I helped merging graphics code into our main branch. I also helped changing the network architecture so that it can process network events more efficiently.
3) All goals were met.
4)Integrate game mode and edit mode with Robin. Implement a basic bomb model. Be able to spawn a bomb. Maybe look into physics for bomb.
5)Will be busy this week with midterms. Hopefully I can meet my goals for this week.

Zonglin (Robin) Wu
1) Figure out an efficient way to do reflections
Create geometry object manipulator in the in-game editor.
Integrate the rendering engine to the game client.
Figure out why my shaders fail to compile on lab computer
Created a separation of Game Mode and Editor Mode.
2) All
3) No reason
4) Implement the reflection system.
Add additional manipulators object manipulators for the geometry.
Add buttons to select different object manipulators.
5) Progressing slowly but steadily

Wai Kit Leung
1)Help finish the camera integration, and implement the networking code for the camera data. Work on title screen, player disconnecting (destroy entity), chat system.
2) Finish with the networking integration with the new entity component system.
3)I was sick for the couple of days, so mostly all my goals has been push back a couple days. However, during my off time I did some research on implement a better and more customizable character physics, but our team have a discussion and decide to focus on getting the camera and setting up the world first. So we will be delaying on working the game logic and the core physics implementation until next week.

4) Help with Phillip and Brian to finish the camera and implement the networking code for the camera. Hopefully we get it done quickly so I can move on to work on the title screen and player disconnect.

5) Cloudly

Alexie:

1)

1) Learn Maya

2) Build a model and start skinning and animating it

2)
Well…I learned Maya. Also learned it was a massive pain and I have to juggle 23974632974923 different functions all at once. I also realized that geometry is very important in 3D modeling after wasting a lot of time finding out that having a 25 x 25 subdivision sphere makes for really messy modelling and that quadrilaterals don’t make circles, I decided to make something simpler than I have in mind. Therefore, I only got part of the model done.
While not an original goal, I did learn about the PBC pipeline from some videos Robin sent me because he wanted me to know how it worked while I worked on art and graphics.

3)Because learning Maya and being caught by its pitfalls took so long, I didn’t get close to finishing my model. (See above for a more specific example of what trapped me) I thought I went in having a really simple design and model but apparently I lost all my 8th grade geometry knowledge. Also, for whatever reason, Maya is kinda funky on my personal laptop so it works a little differently from the Maya on the lab computers. It’s probably just something different in the default settings, but I’m not about to go through each of the different settings and figure out what’s different. I figured out work-arounds in the meantime and I’m getting used to it.

4) what are your specific goals for the next week?
Finish model!
AND GET IT SKINNED AND TEXTURED.
AND ANIMATED.
Pat self on back and get some sleep cuz I ain’t getting any sleep to get this finished.
Curse Maya more. Maybe start liking it. Hoping for the latter.

5) what is your individual morale (which might be different from the
overall group morale)?
Really swamped by work I have to catch up on, but not sick anymore and totally motivated to work. Intend to have completed model by tomorrow morning’s meeting. Little disappointed that I basically didn’t get anything done, but hell am I letting that happen this week.

Week 2 Report

Summarize:

  • Finish week 2 goals
  • Milestone: Got a network game with 2 movable cubes working

Group Meeting: Week 3:  Monday 6:30 pm

Group morale: feeling good (TSM TSM TSM); NA >>>> world, stay mad world; BabyRage marty is still SALTY BabyRage

Concept Arts:

Char_Concept1 Map_Overview

Individual Reports

Martin La Pierre

  1. Network a system to have two cubes moving with each other
  2. Networked a system to have two cubes moving with each other
  3. met goals
  4. Work more on protocol/physics
  5. Salty/Very Salty

Wai Ho Leung

  1. My goals for the week were to set up a foundation for the game client that could translate network messages and render two players with networking support. I was also aiming add some basic game physics.
  2. I implemented entity component system for our framework and was able to implement the part of the game physics. I also helped implementing the network client.
  3. All goals were met.
  4. Be able to render a player falling for the game physics. Setup encoder and decoder for translating network messages.
  5. Feeling accomplished.

Wai Kit Leung(Steven)

  1. Establish the networking framework and have a server that can communicate with two clients that can move the box on screen
  2. Settle on the networking protocol, and provided a layer of abstraction between the game logic and socket layer, in which the both the game client and the server can communicate and send data.
  3. Be able to settle on an game architecture early, each of us has an architecture in mind, but we haven’t talk about it together enough to settle on one general framework.
  4. Implement the physics layer in the server, add the game logic to the server, add more players, and merge the code base with the rest of the group.
  5. feeling hungry, need more free pizza in the lab.

Brian La

  1. Figure out how to load and use animations from an .fbx file
  2. Created a Model class that supports loading a model file and manages animations
  3. Be able to transition between animations (ex: walking to idle). I tried creating a dummy model that contains 2 different animations but couldn’t figure out how to preserve multiple animations upon importing the file. Instead, I have thought of a way to achieve the same goal through a different approach, but I haven’t tested/implemented it yet.
  4. Merge the Model class with the project code. Help out with managing the camera
  5. Feeling good and happy since TSM wonnered

Robin Wu

1. Finalize the rendering framework:

  • separated plain material and textured material for an asset
  • optimized G-Buffer to reduce the bandwidth requirement of graphics card
  • implemented normal mapping
  • implemented physically based shading
  • implemented tiled-based deferred shading
  • interface to load art assets
  • Created GUI to control as a in-game editor
  • Able to control geometry object’s material (albedo, roughness, specular, metallic), position
  • Able to change the texture of an object on the fly
  • Able to control the light position, color, direction

2. All

3. Illness.

4. Help integrating rendering system into the client code.  Implement procedurally generated sky for skybox. Implement image based lighting for the foundation of reflection. Design an efficient reflection rendering algorithm without relying on gi. Investigate a way to combine emissive materials into the pipeline, without modifying the optimized gbuffer.

5. Feeling Positive.

Phillip Ho

  1. Work with Brain on Animation
  2. Agree with Brian on an Animation scheme.
  3. Wasn’t able to create a model with 2 animation for Brian to test blending different animation.
    1. Maya was a new tool. Got to learn the new tool.
    2. Tried Blender: but realize never worked with multiple animation in one model before. Got to learn how to do that too on Blender.
  4. Goals for this week:
    1. Get a first person camera working.
    2. Maybe get 3rd person camera working.
    3. Compare between the two?
  5. Happy, Happy, Happy. Sleepy.

 

Alexie:

    • Complete concept art for playable characters
    • Complete overview of environment and other details regarding the map
    • Basic sketches of the playable characters along with features and logic of its functions
    • Basic sketches of overview of map and various features of it
    • Offered new ideas to group from an artist perspective (in terms of layout and character abilities, etc)
  1. I didn’t get as much done with the art as I would have liked. I wanted to have more detailed concepts with various angles and full colored schematics, but I only got basic sketches done. This was mostly in part to the fact that I was sick the entirety of last week. I still am, but I feel considerably better and am in condition to work longer and harder on the art again.
    • Start building character 3D character model for the game
    • Start building map environment
    • Learn programs needed to accomplish this (eg Blender, 3D Max, etc)
    • Plan to stretch this across two weeks since learning new programs and building models from scratch (or near scratch) won’t be easy
    • Sick 🙁 getting better though and ready to work harder! (Although currently nursing a headache)
    • Somewhat intimidated by the task of building 3D models…it seems really hard, but I’m excited to try (and hopefully do awesome) I’ve been meaning to learn how to use these programs for a while now and this is the perfect chance to do so.