Monthly Archives: September 2014

More of texturing day

Yesterday I worked quite a bit with my character animator Tyler Hurdle to get the animations properly exported from his modeling software into my graphics engine.  After much wrestling, I got the simple walk cycle loaded in and it looks awesome.  

Things happened today.  Those things included me finishing up the texturing for the Hotel.  I must say, it’s really starting to look good. I can’t imagine how it’s going to look once I add in the final shadowing and post-processing effects.  I didn’t take as many intermediate screenshots as I should have this time. So I only really have the final results of where I am at the end of today.  Nothing too-far out of the ordinary happened during the last steps of the texturing of the hotel besides me modifying the basic window shader effects to include partial transparency. I did this so that I could “cheat” with the interior shops of the hotel, modeling the interior as a simple gaussian-blurred backdrop which is partially of obscured by the semitransparent window.

I also decided to get rid of the ugly default “sand” texture that I’ve been using for my background terrain.  I spiffied this up a bit with multitexturing effects using a detail texture which came out pretty awesome.

After all this, the frame rate performance within the editor and the game started to both get really bad.  So I had to stop modeling and dive into some optimization once again.  Using instruments within xcode, I uncovered some horrors related to the terrible performance of objective-c’s NSString methods (namely stringWithFormat) which forced me to eliminate their usage and some of the more critical sections of the rendering engine’s code.  That alone, gained me another ten frames per second back and started getting me to question the viability of Objective-C for hardcore game engine development.  I sure hope Swift’s string methods are faster than Objective-C’s.

Continuing with optimization, I put off the long-needed step of sorting scene entities first by transparency, and then by material.  This helped me avoid unnecessary state changes which propagate to the shader and harm performance.  I also hard-coded a backface culling test which showed that I really need a per-model “cull backfaces” option within the editor.  All of this optimization added up quite a bit to bring my performance back up to a reasonable level.

All of this work today uncovered quite a few new bugs in the editor itself, so tomorrow will likely be spent fixing those…

Texturing day

I got alot accomplished today.  I continued with my texturing efforts and started texturing the hotel.  This is the most important building in the scene since its the biggest and stands out the most.  I really wanted to work on my attention to detail while working on it.

One feature that I programmed for verto yesterday that has proven insanely invaluable to me is the unwrap texture feature.  This feature maps polygons to one of 6 faces of a virtual box and assigns them their own coordinates within the UV texture space.  In lamens terms, it makes texturing box-like objects a hell of alot easier.  It works best when the object has some flat shading enabled.

I finished texturing the supermarket yesterday but I’m not all that satisfied with it.  I’ll probably revisit it when the rest of the street is further along.

The hotel on the other hand, is looking really nice.  Sometimes its all about finding the right texture.  I found an excellent brick texture via turbosquid.  I then ran it through my favorite filter:  gimp’s “make seamless”.  Lastly, I created a normal-map for it using the “crazy bump” tool for mac.  All rendered with bumpmapping, the hotel front looks great.

Perhaps the most fun part of today was painting the sign decal texture for the sign that sits above the left shop in the hotel.  For someone who’s a crappy artist, I felt like I didn’t do too bad of a job.  After throwing in a few references to name’s of my buddys, I got it all ready to go.  I render it using a simple alpha-test shader.

Last but not least, I took on the “opaque window” shader that will be used on all the non-transparent windows in the scene.  I tried a flat reflective environment mapping effect but it looked pretty unrealistic.  Since we’re in the early 30′s here, I figured that I would simulate “wavy” or “mildly bumpy” glass.  This means combining bumpmapping and environment mapping shader techniques.  The result is very awesome.

Working on this game is proving to be too fun.  Sadly, I should probably do some non-game-related work on Verto Studio tomorrow and return to this stuff next week.

 

The insanity that is OpenGL Occlusion Queries

Intro

So this morning is the first morning that I am working without a day job.  I must say its liberating…. but enough about that crap!  It’s time to get to work!

This morning was a programming morning.  The considerable performance drop of my scene during my modeling efforts led me to investigate methods for improving my scene’s rendering performance, both in the editor and in the game itself (since they both use the exact same rendering engine).  Back in the day, I used to laboriously accomplish this using frustum culling.  Frustum culling is a technique that uses a spatial data structure, an octree, to categorize the mesh objects in a scene into cubic regions, and then mathematically detect whether or not those regions are in the viewing volume (frustum) currently visible in the scene.  This technique works okay, but it’s a pain in the ass to implement and I’d rather not if I don’t absolutely need to.  Furthermore, it doesn’t handle the situation of occlusion, when a very large 3D object is in front of a smaller one, eclipsing it, making it entirely invisible and useless to render since it’ll fail the z-buffer test.

Thus, enters “occlusion queries”.  A very cool OpenGL technique which allows you query exactly how much of a 3D object was truly rendered, and decide whether or not to keep rendering it in the future.  This is exactly what I needed.  It all sounds great in theory, now let me tell you about some of the issues I had implementing it.  I’ll try to avoid some of the ugly Objective-C syntax that surrounds this code in my actual system in my snippets.

Technique Overview

So in practice, occlusion culling is quite simple.  There are basically 3 steps.

First, you must render the scene using very simple solid bounding-box geometry.  ie, for each discrete mesh object within your scene, you render a giant solid box that entirely bounds that object. You only render this box with a very simple flat-color shader which will keep your query render very fast.  You don’t actually want these boxes to appear in your scene, so you do this step with color buffer writes and depth buffer writes turned off (masks set to FALSE).

Next, you query the results of the above for each box rendered and determine which models were visible (not occluded).  You make a note of the ones that were.

Finally, you render the scene normally, with the extra check to ensure that you don’t render the model objects that were not visible.

Setup

So the first thing I needed was a single occlusion query per mesh object in my scene.  In OpenGL, these (like many things in GL) are GLuint ids.  I dropped these into my entity mesh class

Then, in the model init and dealloc code, I generate the query objects as needed.

I then set up a special method that renders the solid bounding box geometry used during the occlusion query.  Now here’s where things get tricky.  There’s a way to do occlusion queries wrong (which I found out the hard way).  So much so that the performance benefit that they offer is entirely negated by the pipeline stalling that you can inadvertently cause.  Note the check against the EntityMeshOcclusionWaiting state.  This will be explained in the next section.

 

Scene Rendering

To kick this off, I added a new special method to my Scene class called renderOcclusionQueries.  I then inserted a call to this method in my scene’s main render method like so.  Note the usage of glColorMask and glDepthMask to ensure the query bounding boxes don’t actually render to the screen.

With the queries properly set up, I can now use them during my main rendering pass of all the entities to ensure I only draw whats necessary.  Again, this was tricky.  I had to absolutely make sure I never stall the pipeline.  No matter what.  This means I don’t retrieve a query result unless GL_QUERY_RESULT_AVAILABLE is true.  If it isn’t, I leave the query in the “waiting” state.  I also don’t start a new query when it’s in the waiting state (note the check against this in the above entity renderOcclusionQuery method).  This essentially means that the occlusion queries are entirely asynchronous with respect to the main rendering.  

That’s pretty much all there is to it.

Considerations

Now aint nothin in this world fo free.  So there’s some things I should mention.  First, if I wasn’t also targeting iOS mobile, I would have probably used the OpenGL conditional rendering method which essentially does alot of the above checking for me automatically.  I noodled around with this and couldn’t get equivalently good performance so I just moved onto the manual way.  I also don’t like how I still have to submit all the expensive drawing “and non” drawing calls with conditional rendering and essentially trust the driver to do whats best.  My method ensures NOTHING is ran if the object isn’t visible.  With the downside being initiating readbacks from the OpenGL device back to the CPU.  However, I’m getting very decent performance with this so I’m happy.

Also, because the queries are truly async, I can get myself into trouble when running this code on very slow or buggy graphics cards (ahem.. intel..ahem).  The problem being, if the query takes too long, you may look at a space where an object should be, and not see it for a few frames while waiting for the query to catch up.  This finally explains to me why when playing some games on my wii u (such as call of duty), I sometimes turn real fast, and see an object suddenly appear a few frames late.

More modeling..

Today was another modeling day.  It’s starting to look pretty decent.  I finished up the convenience store and added a vintage gas station to the end of the street.  I’ve definitely been pushing verto hard so I’ve been running it in the debugger just to make sure I catch any serious bugs or crashes while I work so that I can fix them on the spot.  I’ve already used the crap out of my instancing feature and fingers crossed, it’s working pretty well.

I got to use my shader builder feature today while working on the gas station parking lot which felt awesome.  Being able to quickly hash out shader effects is proving invaluable for this project.  I used the GLSL ‘smoothstep’ function to code a quick-and-dirty solution for cross fading the parking lot with the desert terrain underneath.  Using blending for the entire polygon is not all that efficient but I’ll take that over a more complicated multitexturing solution.

 

I also drafted up a quick terrain mesh using pixelmator to create a height map.  This is how I’m going to take care of the background scenery with a tall “mountain” range in the background of the street view.

Lastly, I screwed around with the multipass pipeline editor to see what a “noire”-like black and white effect would look like on the scene.  It gives me chills and definitely inspires me to keep working on the project.

Early noire effect

I can’t wait to see what it all looks like when I’m done the texturing.

Lots o’ work

Did alot with the “town street” scene today.

I had to add a bunch of new features to verto to keep up.  Namely “merge doubles” and “duplicate instance” to allow for instancing lots of tiny little meshes.  I spent most of today on the theatre area.

It’s starting to look like an actual game scene.

Hoverboards don’t work on water.. Unless you got powahhh

Tiny bit of work today.  Got the second building going and finally put in some powerlines via turbosquid.  I’m not thrilled about the loss of smooth shading on the poles though.  I’ll have to code a quick feature for verto to auto-weld doubled vertices this weekend to fix that.

The framerate within the editor is also starting to drop to 30 fps territory.  Nothing too scary yet, since everything is still quads.  I’ll probably save rendering optimization for the very end.  I hope it won’t be too bad as the scene grows in complexity.

 

Sarging on.

More modeling work was done recently.  I temporarily diverted attention this weekend in a blaze of coding fury to put together a new mac app which I submitted to apple this weekend.  With any luck, this app will hopefully raise more funds to help with this game.

I’ve received some initial renderings and concept art from my character designer.  It’s looking pretty sweet sofar.

Modeling progress of the street below:

First update – all efforts on modeling

So, for the first time in awhile, I’m really using my own modeling tool quite a bit, and I must say I’m pretty happy with it sofar (especially not crashing on me and losing my work).  I’ve only had to pop over to xcode and add two new features that I forgot to bring over from the iPad version (toggle object hidden, and send-to-back for manual transparency render sorting)

Anyways, the city street is coming together nicely, and I hope to keep this momentum up as I build it out.  I’ve also been relying on old-faithful, turbosquid, to help with certain smaller assets that I want to use to fill up the street such as trashcans and mailboxes.

I’ve also hired a character artist, Tyler Hurdle, to put together and animate the character model for me.  I’ll post more on that as progress emerges.

Modeling progress shots below:

The idea has come

Okay! I got it! My “grand plan”. Looks as if it was sketched by a 5 year old, and that’s why I love it.

                                                    This is my game idea. It’s magical

I’m diving in and not looking back. I haven’t felt this excited about a dumb quick game idea in awhile.

There’s a few things I’m going to do while dev’ing this game to keep things fresh.

  • I’m going to leverage my existing VertoCore graphics engine. This is the giant objective-c codebase that my 3D modeling studio was written in. This will save me tons of time.
  • I’ll be writing the actual game logic in swift. This is a brand new language that isn’t even off of beta yet. Since I’m already stuck using objective-c, I’m pretty much tied to mac-osx and ios. Beta language? What could possibly go wrong.
  • This project scope will be SHORT. The “planned” time length is two weeks. I say this because most of my game projects run long. A month or so of work is acceptable. Dragging on for months isn’t. Let’s see how it goes!
  • I’m hiring out the character modeling. I know I’m a beyond bad 3D character artist and worse animator. Outsourcing this part is the way to go for me.
  • I promise to care more about the game than the code. This is a hard one for me, but it’s a must if I want to get the game done properly.

That’s it! I’ve already put a full days work into it and I’ve gotten collada animations loading into my graphics system. The XCode project is groomed and all ready to go.

                                   It works!

all systems ahead!