Serenity – Deferred Rendering

Over the last few days I’ve been working on switching from forward rendering to deferred rendering in my OpenGL Game Engine Serenity.

The purpose of deferred rendering is simple: To reduce the overhead of lighting calculations and to make post processing easier. This happens by limiting the lighting calculations and post processing calculations to only what is drawn onto the screen.

To determine the information for the calculations, some information that would normally be rendered to the back buffer (what you see on your screen) will instead need to be rendered to a framebuffer object. The information for standard lighting calculations that need to be saved are:

  • Diffuse textures
  • Normals
  • World Positions (or the depth buffer rendered to a texture, in which case you can recalculate the world positions in the fragment shader and save space)

Using the information saved to the framebuffer, you can then import the rendered textures as 2D texture sheets (sampler2Ds in OpenGL shaders) and then read the textures using the screen’s dimensions and pixel coodinates as UV coordinates. Finally, you render a 2D Quad covering the window with the updated information produced from the fragment shaders.

I am basing my system off of two tutorials: http://ogldev.atspace.co.uk/www/tutorial35/tutorial35.html

and http://www.codinglabs.net/tutorial_simple_def_rendering.aspx

Roc Py – 12/16/2014

First ever Roc Py at RIT! Well, first as far as I am aware…

The topics were all about RIT projects from HFOSS and AdvFOSS.

The HFOSS guys presented the projects they developed on the OLPC. The projects were:

  • Get 24
  • Puppy’s Pen
  • Matter
  • Robobuddy
  • GeoMunchers

PyHUD was presented from the AdvFOSS class as well as Libfab.

OpenGL Engine – Serenity

I feel as though it is time to work on an outside of class project that has the following goals:

  • Teach me more about OpenGL and graphics APIs in general.
  • Teach me more about the structure and functions contained in game engines
  • Result in a very good portfolio piece
  • Be used for educational purposes and/or as a platform to work off of for projects.
  • Allow for me to use as a template for future OpenGL projects

I know IGM is looking for people to provide OpenGL examples of programmable physics so I thought this would be a good start.

I am code-naming the project “Serenity”, as the word describes harmony and fluidity. Game engines require all the pieces to be working fluidly and using the least amount of memory and processing power possible. I thought the name would suit perfectly for this.

The engine will use OpenGL for all rendering functionality. It will use SFML for OS related functionality like hardware processing and window initialization. It will use glm for mathematical operations, GLEW for OS related OpenGL extensions, SOIL for loading in texture data, and Bullet for the physics functionality.

Github: https://github.com/mstubinis/Serenity

Paint Partners – Final Thoughts and Assignments

What initially seemed to be a complicated project for a 2 week development cycle turned out to be ok due to the re-use of networking code from the previous hack. This coupled with dedication and commitment resulted in the project being completed on schedule. Some minor enhancements remain for post-development. These enhancements could possibly be added by community contributions and not just the initial two developers (check issue tracker).

Some of these enhancements include:

  • A way to save the drawing board to a file
  • A way to have the admin erase the entire board
  • Handling text overflow in the client list and chat windows
  • Having the mouse icon reflect brush type and size when hovered over the drawing board

Final Hack Proposal

Title: Paint Partners

Description: A collaborative drawing tool made in python using pygame as the GUI, and using homemade networking code mostly borrowed from the second hack. In theory, the program could be made into a teaching tool by limiting who can modify the drawing board (for example, a teacher could be the one modifying the board while the connected students see the board).

Libraries Needed: pygame

Upstream Repository: pypi.python.org

Hardware Needed: Raspberry Pi, mouse, keyboard, internet connection

Team Members: mtubinis, Pharas

Upstream Mentors: N/A

Project Milestones:

  • Week 1: Develop non-server side code to modify an image, load configuration data, and prepare program text fields.
  • Week 2: Develop server side and networking code to send and process: pixel data, client chat messages, client mouse cursor positions,clients connecting and disconnecting from the server, and server admin issuing server commands using their terminal.
  • Weeks 3 – 5: Finish any remaining development tasks, build documentation, test, record bugs, and distribute the finished program over to PyPi.

Anticipated License: GNU GPL 2.0