Real Time Graphics Asg07

This assignment wasn't too shabby.  Once again the hardest parts seemed to be the sorting and setting up the  PIX calls properly.  I probably went about this the completely wrong way, but its been one of those weeks, or months or semesters or whatever.  Anyway, for the assignment we had to set up PIX event calls to make debugging in PIX easier.  Which is pretty awesome, but I haven't really had a reason to use it in awhile.  I suppose that's good, I'm sure I'll learn all the details when something goes horribly wrong as with most debugging tools.  Check these awesome buckets though.

The transparency stuff wasn't too bad.  Sorting the draw order so you could see all three cubes inside of each other was kind of a hassle, but not terrible difficult.  I now have somewhat gross sorting loops in more than enough places, but hey, selection sort on 9 items is probably manageable.

I think the thing that caused me the most trouble was actually a sorting loop that got copied and pasted from another incorrectly.  It was actually causing my transparency to not work at all, I think because certain settings were turned off at certain times.  Once I caught the error, a counting issue, everything just worked.  

Also, I had an issue with the world being incredibly dark, but I think that problem stemmed from some bigger issues.  I'm not sure my specular lighting was functioning exactly as it should.  Speaking of which, I moved the specular exponent to the materials finally, so be happy about that.  :)  I just realized I did not take the number out of my scene file though, so it is still being read in and parsed and not used.  I'll fix that later, everything is already zipped up and uploaded now though.  Anyway, back on track, my specular lighting wasn't quite working properly I thought, and upon looking into it I noticed I was actually passing a zero into the shader instead of my scene files value, I probably switched it out a bit ago as a test and forgot about it.  Upon fixing that, and a few other things, that I messed up this week, the scene went really dark.  Part of that was because of my ambient lighting being really small do to compensate for some of the other errors I had.

Long story short, there were several small lighting problems that when fixed turned into other problems.  I think I got it all sorted now.

Here's the code.  Sorry this writeup was so rambly and all over the place.  Hope you got the gist of it, nothing in particular actually pertaining to the assignment was terribly difficult this week.  Just a lot of little things that needed to be fixed.

Vinyl and the Industry Panel

Last night was the "first gate" that we had to get through to get our prototype greenlighted... sorta.  I kind of feel like getting chosen among the 15 or so pitched games was really the first gate, but I suppose not.  We're mostly programmers, lets call that one the zeroth gate.  Anyway, the game has progressed a ton since I've last written about it.  It currently has particle effects instead of spheres for the static, and the lasers look a little better and even pulse as they pass by the player.

Most importantly we have an equalizer now that jumps to the music and we spawn the enemies based on the intensity of the song.  It definitely needs a lot of tweaking, some songs do almost nothing and others spawn absurd amounts of enemies, but it was definitely effective for the prototype.  Here's a video of someone playing really well, you can see it get crazy when the metal part starts.

http://youtu.be/icjEKQDvM-8

We also have a video of someone butchering Thriller since changing your speed affects the pitch of the song and moving side to side affects volume.

http://youtu.be/HjB0d-RGBAs

The game is pretty fun to play, it just needs some further refinement and a probably a few more features.  And a real artist, right now its pretty much been Mike and I throwing colors into the mix.  If we get past the first gate we have some big plans though that I'll cover in another post.

The first gate went really well, but we'll find out for sure on Thursday which games made the cut.  Everyone put forth a fantastic presentation and had some great prototypes, so it'll be interesting to see what ends up happening.

Real Time Graphics Asg06

This assignment was pretty cool, it was the first time I've ever dealt with reading and writing binary files and it's a lot simpler than I thought.  I still encountered a infuriating bug that was really hard to fix since everything was in binary, but finding it was pretty easy.  Fixing it ended up being easier than what I was trying to do in the first place anyway.  I'm still baffled by the stuff you can do with C++.  This ain't your grandmothers programming language... then again it might be old enough to be.

Anyway, onto the graphics, this assignment was more about sorting and optimization than anything.  We had to sort our entities by their shader and texture in an effort to minimize the slow swapping operations in the update loop.  As you can see by my lovely screenshot here, I set the materials together, the effects together and then all the entity stuff.  I basically just sorted the entity array after I parsed it in.

The actual fun part of the assignment was writing the Maya plugin.  Well, more like writing a method of the Maya plugin.  It was still awesome to be able to model something in Maya and export it into my customized format and be able to parse that into my own graphics system.  I have a feeling when it comes time to add fbx support to our game engines renderer next semester we'll have a lot easier time.  Nothing really bad happened with this section of the assignment, except the Maya install on my laptop apparently broke between now and December when I used it last.  I couldn't hit the browse button on the plug in manager or the export all button or most menu buttons without the program immediately becoming perpetually unresponsive.  It wasn't the plugin either, I couldn't even get that far.  I ended up just using my lab computer.

The only big problem I ran into was the one I mentioned above.  Since I'd never written or read in a binary file before I was a little confused as to how to read it back in.  I ended up trying a way Sherly showed me, which confusingly only worked some of the time.  It worked flawless for my cubes, and for some of the simpler shapes I exported from Maya, but one of my shapes only drew a single triangle and the torus read in a negative vertex count.  It's hard to instantiate arrays with a negative size.  Anyway, her method worked for her, and involved some bitwise ors to convert a char back to an int, but Cody showed me a much easier method that works 100% of the time.  I'm thinking Sherly's method didn't work from machine to machine due to big endian and little endian differences, but I'm pretty sure she tested hers on the same lab machines we were using so I'm not sure.

Anyway, it was a pretty neat assignment, here's the code.  Oh, and one thing to note, the changes I made to   MeshBuilder in order to write the files to binary no longer overwrite existing files, so if you try to change a mesh in the Assets folder, you'll currently have to delete the mesh files out of the temp/data folder.  Sorry about that, I'll find a fix for that next week, it's probably as simple as using another method out of that library that has CopyFile instead of using fstream.

Real Time Graphics Asg05

This assignment was pretty cool.  It's nice seeing all that effort we had to put into this pipeline initially allow us to expand the scene so rapidly.  Just look at all these cubes!

Complete with specular and diffuse lighting.  The four on the left are specular, as you can see by that awesome glare on the left rubix cube cube, while the right four are only diffuse.  Also, the front four use 24 vertices with proper normals, while the back four use the mesh that is only 8 vertices and averaged normals.

The controls are the same, WASD to move the camera, IJKL for the light and the arrow keys for the meshes.

I'm not entirely sure what to talk about this time around, specular lighting is pretty awesome, but the math behind it is pretty simple.  It made for an easy assignment that consisted of maybe 30 minutes of graphics related work and maybe 4 hours of creating and manipulating text files and then debugging said text files.  I ended up using the message logging system a ton to figure out where all my errors were though, so I'm glad I kept up on our teachers policy of logging errors everywhere.

One issue that kind of confused me is the specular lighting doesn't appear to be working on the back left two cubes that use the averaged normals.  Supposedly it should work better,and it's hard to tell because they are so far back, but I don't think it's working.  You can rearrange them pretty easily with the text files if you are interested.  I don't get how the lighting can work for the other meshes, but not for all of them.

Additionally, I set up my code so that the specular lighting exponent could be read in from the scene file before noticing I was supposed to put it each individual material file.  This makes sense so we can specify how rough or smooth and shiny various materials are, but I don't have the sheer force of will to go back and change all the code and add the getters and setters to make that work right now.  I'll probably switch that up next week or when we do some bump mapping (we are doing bump mapping eventually, right?)

Oh, one last question I forgot to bring up in class, but I found interesting.  I chose to pass the world to view transform into my specular fragment shader cause it was easy, but it seemed like it'd be faster and more efficient to output it from the vertex shader and intercept it with the fragment shader.  Then you'd have a vertex shader outputting information that not every fragment shader needs however.  Is their a better choice for handling passing this data?

Here's the source code!

Colors Everywhere!!!

Well, Vinyl now has an overwhelming amount of color in it now.  We got put fancy bright colored texture on the half pipe that repeats to give the player a sense of motion.  Before you couldn't really tell if you were moving since it was just a super long gray halfpipe with a fixed camera.  The balls rushing toward you helped, but the colors makes it feel a bit more frantic and hip.  We also randomly generate colors for the balls.  Ideally these will turn into some sort of electrostatic particle effect, but that isn't really necessary for a white box prototype.  Lastly, we added lasers in that are really just long cylinders that you cannot pass through.  They are forewarned by a red ball about a half second before they show up.  However with the multicolored other balls it's a little hard to tell right now.

In addition to all that Shirly implemented a lot of the musical features of the game.  We couldn't natively make Unity force audio out of the left or right speaker, so for now the farther you get away from the center of the halfpipe the quieter the music gets.  Additionally the speed at which you move affects the songs playback speed.  It's kind of a neat effect, but its still a little wonky.  Definitely works better with some songs than others.

Right now we're figuring out how to analyze the songs using Unity's libraries to actually generate the obstacles.  Also, we'd like to implement a rewinding function.  I have an idea about how to do it and will hopefully get that working on Thursday.

Here's a screenshot of all the colors.  This should hopefully clarify a bit of the details of what I'm talking about.

Oh, also we added some fun lasers in the background for a cool visual effect.  It was kind of an accident when we implemented the red lasers, but it looked cool enough that its not a bug, its a feature!

Real Time Graphics Asg04

So this assignment ended up being way harder than I thought.  Here it is.  This time we had to update our content pipeline so that we could generate all the relevant graphics data from text files.  Now with minor changes to some text I can add dozens upon dozens of cubes in of various colors and textures with colored light and intensity.  It's pretty much the greatest graphics content pipeline ever, objectively speaking.

Seriously though, the assignment had very little to do with actual graphics stuff, but ended up being kind of interesting regardless.  It was a lot of string parsing, which is the devil, and took forever, but that stuff is pretty boring and not too challenging so I don't really feel the need to talk about it.  It did take me like ten hours for that chunk alone though.

The reason it was interesting was the remaining 5 hours, you know, those 5 hours that you expect to take about 1, but it never really works out that way.  Once I got all the parsing stuff in, figuring out how to modify the current renderer class that our teacher built to display multiple sets of vertex data was quite the ordeal.  I ended up wrapping most of the LoadScene, ReleaseScene and Update methods in loops that basically did the same thing for each cube I had to draw.  The whole process didn't seem quite right, but by this point in the project I was somewhat out of steam.  I'll probably look into rearranging some things and optimizing in later assignments.  In fact, I think that's going to be an upcoming requirement of a new assignment.  :)

I also spent a lot of time trying to figure out the best way to pass data up from the parsers and into the eventual DirectX calls.  The other Jason and I had a pretty big debate about some aspects of it.  Mainly because he wanted to copy all the vertex and index data into the buffers we were already using and not change the DirectX calls.  I figured we'd save space and time by just passing the buffers we populated during the parsers directly.  After about 3 hours of trying to make it work my way, I gave up and did it his way.  I think I got really close, cause I found the biggest culprit of the errors I was getting was a typo in my mesh parsing code.  Still, at some point you just got to cut your losses.  I had other stuff to work on and I did meet all the requirements.

Anyway, despite this assignment not having much to do with the high level graphics stuff we always discuss in class, it forced me to be way more familiar with what all those DirectX calls were actually doing since now a lot of them are done three times.  Not all though, turns out clearing the screen 3 times per Update call is a bad idea.

Here's my PIX depth screenshot by the way.  I think this part of the assignment took about 7 minutes, but its definitely noticeable.

And here's my source code.

More Vinyl Changes and Progress

So I mentioned in the last Vinyl related post that we were making some substantial changes to the design.  It sounds like everyone in the cohort did because we're now getting an extra week to work on a prototype.

Anyway, the essence of the game remains the same, but to further emulate being in the groove of a record we decided to put the player in a halfpipe like Sonic 2's special stages.  This allowed us to brainstorm a lot more record-like abilities and functionality.  We still want to effect the stereo sound based on the side of the halfpipe you are on, but are running into technical difficulties with Unity for that, in that Unity doesn't seem to be capable of doing it.  Additionally we came up with ideas such as a player usable "scratch" that rewinds time a bit and of course plays the "wiki wiki" sound.  We'd also like the pipe to curve and drop according to the beat.  I think the coolest, but possibly the hardest feature to implement is changing the point of the song based on if the player gets to far up the side of the pipe and falls into the next track of the record.

What we got so far is fairly simple, we have a player cube that can go up and down a halfpipe while randomly generated balls rush past it.  Here's a screenshot.

The hardest part was getting the cube to actually move along the curve of the halfpipe.  We tried a number of techniques, but ended up settling on a rotateAround method that is currently using the origin.  This isn't going to once we start changing the pipe's direction, but it should suffice for now.  We shouldn't have to change it too much once our levels get more complex.