Assignment 14: Transparency in Meshes

This week’s game: simple one-click download below, unzip, play, enjoy!

NancyNewren_ExampleGame 14

What’s new
I added two transparent objects!

Controls
Main object: Use arrow keys to move main object left/right/up/down
Camera:  Left/Right (A/D), Up/down (W/S), Zoom in/out (Q/E)
(When moving the camera things in the world will appear to move opposite. Thus when you move camera left, the world will appear to move right.)

 About the Project

This time around I added the ability to become transparent to my meshes! It was fun.

First thing was to create a shader and an effect to allow for transparency. Next I created two objects drawn with them, but drew the meshes in whatever order they were submitted to the render thread. This works fine for opaque objects, However for transparent objects when a transparent object is drawn in before an object behind it is drawn, the object behind it isn’t drawn properly (as expected that is) to the screen. I.E. you can’t see the object behind a transparent object if that object isn’t drawn before it.

This means that all transparent objects have to be drawn back to front. The order of the opaque objects doesn’t matter though (with depth buffering on at least), as long as they are drawn before all transparent objects.

So what I did to order the draw calls is: after submission to the render thread is over and and before the swap, I ordered the draw calls. How? First thing: I added the index of all opaque objects (I just asked the mesh’s effect if it was opaque, nicely of course) to a vector in the order they were submitted, and then put the transparent meshes in a separate vector with their index and their camera space z value. This is the key to quickly sorting these meshes: in camera space I immediately know which meshes are in the back and in the front based solely on their z values since camera space is when the camera is at the origin and is facing forward. Then a simple std::sort with a lambda function that orders the z’s based on z forward being negative z (i.e. larger values of z aren’t closer to the camera, they are the farthest away), quickly sorts those values. Once sorted I added the index values of the sorted transparent meshes to the end of the previously mentioned vector (the one with the opaque meshes all in front to be drawn first.) Then in the rendering of the meshes I draw them in the order of the sorted draw calls.

I chose the render thread because with my game it doesn’t really matter which thread does the sorting because it’s such a small game. However, in a real game I would profile both threads and then choose the thread that takes the least amount of time.

 Acknowledgements

I asked my brother how to use the std::sort with my vector<struct> as I hadn’t done a templated sort before . He set me on the path with the google search I needed and I whipped out a lambda compare for my sort in no time.  Thanks bro!

Assignment 9: Now in 3D!

NancyNewren_ExampleGame 09

(Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

Movement

Main object: Use arrow keys to move left/right and up/down
Camera:  Left/Right (A/D), Up/down (W/S), Zoom in/out (Q/E)
(When moving the camera things in the world will appear to move opposite. Thus when you move camera left, the world will appear to move right.)

About the Project

This week I completed the transformation of the game to 3D. To accomplish this I added a third dimension: depth. Then added three matrix transformations to take 3D objects from their local space (at their origin and facing forward), to world space (where the object is in relation to the origin of the world), to camera space (where the object in the world is in relation to the observer, or camera).

Local space is essentially where a 3D mesh’s vertices are in relation  to its origin, and we place the object facing forward as convention so we know automatically how to rotate things and how they should appear without even seeing them initially.

World space is where an object is in the world of the game: if we have a city then we have streets and buildings, and we may use the same mesh to represent all those buildings, at the same local space, but in the world they can be all over the map. World space gives us an object in the map of a game.

Finally we have an observer: world space really doesn’t mean anything until we have an observer. In 2D space what we draw to screen is the world we’ve made, but in 3D what we draw to screen depends entirely upon the perspective we are looking at since we are taking something that has 3 dimensions and moving it to two. Without the observer there’s no way to know how to flatten the world. There must be an observer. In this case we call the observer the camera. Since the camera is looking at the world, when the camera moves the world appears to move in the opposite direction (up:down, left:right, forward:back, clockwise:counterclockwise, etc.). To make the math simple, and since moving the camera is just moving the world inversely to the camera: we take the world to the camera.

The last transform we need then is the one to flatten the world to render on screen.

Here’s how the platform independent transform from local space to world space (localToWorld) in the shader looks:

float4 verPosWorld = MultiplyMV(g_transform_localToWorld, float4(i_position, 1.0));

The last thing I did was implement depth buffering so that instead of the last mesh drawn just covering up the previous one, you can actually have meshes covering up parts of each other. This allows us to render the plane and the cube intersecting (without depth buffering the cube or the plane would be covering the other up):

Additionally…

I chose to make the plane double sided: so I used the same four vertices but sent the index buffer 12 points (instead of six) so that you can see the plane from underneath as well as on top, but the plane is still flat (no sides).

I didn’t have time for any optional challenges this week. I had wanted to do camera rotation, but I ended up spending my extra hours on a Visual Studio bug. I was relieved to discover that the bug wasn’t in my implementation, but still the time was gone. Maybe next time.

10 Ways to Improve Your Game Cameras

Game cameras can be some of the most tricky coding you do. That’s why when John Nesky’s 50 Common Game Camera Mistakes from GDC 2014 went live on youtube (The talk is embedded below), I immediately watched it! We can all benefit from these lessons from Nesky for refining our cameras!

When I first started watching Nesky’s talk I didn’t think he actually had 50 mistakes nor that he could actually get to all of them in an hour talk! But not only did he do both, I also realized that he was also right about these only being some of the issues we face. Which means we should keep the conversation going!

So here are my 10 Ways to Improve Your Game Cameras as takeaways from Nesky’s talk:

1. Use a bigger FOV for heaven’s sake! 🙂
2. If you can use a simple camera, do it!
3. Player’s intent should supersede camera scripts
4. Use the camera to give the player subtle hints, but don’t be overbearing.
5. Don’t use quick camera transitions in place of cuts. Either cut, slow down the transition, or find an in-between.
6. If rotating, camera shouldn’t rotate in place (on its own axes). Should rotate around avatar.
7. WATCH FOR SIMULATION SICKNESS (SS). It’s a disconnect between movement you see and movement you feel. Any movement seen and not felt can cause SS. Have options to turn off extra movement if you want to leave it in the game.
8. Avoid jerky camera movements and constant camera angle changes, especially during combat! It not only leads to SS, but can also be disorienting to players as controlling movement changes with camera angles. It also doesn’t look as pretty, ahem, as aesthetically pleasing.
9. Allow players to invert controls. It’s a significant portion of players that want to invert (like me!). You’ll lose players otherwise.
10. Implement, test, iterate, test, test, test! Repeat.
11. Re-Watch John Nesky’s talk as needed. 😉

I just love GDC talks. There’s always so many of them at the event that you literally cannot attend all of them. So thanks to GDC for posting this treasure to the public. Thanks to John Nesky for being willing to share his own mistakes so the rest of us don’t have to suffer… as much! And for the rest of us I wish a big: Good luck!