Marketing your game is usually a pretty drab affiar but when the developers get involved in marketing their technology, things get really interesting. Take Epic for instance and their proprietary Unreal Technology. They're up to version 3 now with 4 coming out relatively soon and their engine boasts a number of confusedly named components. Gemini, Cascade, Kismet, PhAT, Swarm, Matinee, and now Lightmass and MCP. If you've worked with Unreal Tech some of these may sound familiar, but if not, you're probably pretty confused right about now. Who would guess that Kismet is their visual scripting tool? Or that MCP (named after the antagonistic A.I. in Tron) would be their gameplay statistics tool.
It's an interesting brand marketing strategy especially since most companies just use acronyms. For Mark Rein it probably makes things easier for him to be able to spew out cool sounding names like PhAT or Swarm during a press event and I'm sure the public eats it up. For the developer interested in licensing their technology, does it really matter though? Sure, Matinee makes sense as their camera scripting tool but does cascade bring to mind at all particle systems and effects? Does it describe in any coherent way what it as feature does or how it can be utilized? The value it brings to a project?
We did something similar at Raven with names like Icarus (our scripting system), behavEd (the scripting system editor), Ghoul (the dynamic dismemberment system), confuseEd (dynamic object destruction), vertigons (surface sprites), etc... In the end it becomes something cumbersome and annoying to have to deal with the ambiguity but it does add a bit of extra flavor to an otherwise drab sounding feature.
At id, naming engine iterations with the idTech prefix makes a whole helluva lot of sense but outside of a few interestingly named systems (like AAS - area awareness system), the idTech 5 renderer is just, the renderer, not Lightning or Talon or some other pointy sounding name.
At home I tend toward the simplistic. Right now the engine I've been developing on and off the past 9 years is called the AREngine (which I do plan to backronym as some point). I'm just finishing up a shader graph based permutation system which I blandly call MaterialV2 (Material version 2, despite this being the 4th iteration of my material system - it's the first one I've developed in-place with the previous still functional). Here is a feature that could be a key selling point of the engine and it ends not in an exclamation mark but a period.
If you want to get excited about what you're working on (and get other people excited as well) you usually have to add a bit of edge, which is I think what Epic has done. Having said that, attaching a catchy name that represents what a feature is about is the hard part. The easy part is falling into the name game trap.
The response to the interviewing article went really well! I got a lot of great comments about it and am really glad I was able to give back a little by contributing a piece like that. Hopefully I'll find some time to write more articles like it in the future.
So the past few months have been pretty interesting for me. A few months ago I made the decision to leave Destineer to work for id Software. They're a great company and everyone there is absolutely awesome but I just could not pass up the chance of a life time to work at the company that got me excited about computers and games in the first place! They were all incredibly understanding and I truly wish them the very best. Trust me when I say they're working on something really amazing and I'm very excited to see the final result!
So outside of that I've been keeping pretty busy. While looking for some code to generate cubic noise maps (as part of a series of new experiments I've been working on to generate spherical terrains) I ran into my old starfield generator which generates random points and "blurs" them as they whiz by you. A very cool effect, especially when you consider how the points were generated.
When you generate random noise around a unit sphere you have to be incredibly careful to ensure that they are uniform, otherwise you'll see them gathering towards one of the poles as demonstrated here:
The problem lies in how spherical coordinates tend to congregate points towards the poles. To fix this problem you can use sphere picking to ensure any given area around the sphere contains the same number of points:
This may seem relatively trivial and unimportant for something like a starfield (which it is), but where it starts to really matter is when you need to generate random vectors for something like raytracing. I recently created an ambient occlusion generator for heightfields and ran into an issue where the sampled values where resulting in way to many false positives than they should have been. As I'm sure you can imagine, the issue is pretty obvious; most of the generated rays were going straight up, and heightfields by definition do not have overhangs for those rays to hit!!! The simplest solution is to scale the generated rays up value so they go more towards the sides (which helps quite a bit), but really the best way to do it is to properly generate the sampling rays around the unit hemisphere uniformly. By doing this I was able to get away with using a lot less rays for fantastic looking results!
I won't bother to provide the full algorithm here but if you're interested, check out this page: Sphere Point Picking.
So as I mentioned I've been doing quite a bit with terrains. Unfortunately I don't have much to show as far as screenshots as it's been mostly experimental type stuff to learn and get acquainted with new algorithms. After I finished the ambient occlusion generator I went ahead and wrote a lightmapper for fun (it wasn't that much of a departure) and started a survery of terrain shadowing techniques.
Shadow Mapping is a tried and true classic which can give some great results if you're willing to put a little blood and sweat into your implementation (ala CSM's, VSM's, TSM's, etc...). Lightmapping is nice but only works for static terrains and doesn't work so well for dynamic objects (though I know of some neat tricks to fix this). Ambient Occlusion works nice but only works for global indirect light (so is more complementary than comprehensive). Spherical Harmonics is an option but from my research doesn't always result in the best looking shadows.
One experimental shadowing technique I tried which resulted in some really nice soft-shadows is Ambient Aperture Mapping. The idea behind it is pretty novel and is similar to relief mapping but simpler. First, you generate your aperture values which consist of a bent normal; a vector pointing towards an un-occluded light source (i.e. the sky/sun/moon), and the aperture; essentially a circle at the end of the bent normal which defines how much light reaches that point (this value is similar to an ambient occlusion result and make the bent normal into a sort of cone). After you have these you can test any given terrain surface point's aperture against your global light source which has it's own aperture values. The intersection of these two apertures defines how much light reaches that surface point.
The results are surprisingly good! I may utilize this in full force the next time I need an efficient low to medium frequency shadowing solution with modest storage costs for terrain rendering. Here's a paper on it for your reading pleasure: Ambient Aperture Lighting, and a screenshot of their results:
So, I finally caved in and decided to get a next-gen console. Yes, so I do have a Wii, but I really don't think that counts (you go Hecker!). So the question really was Xbox 360, or the Playstation 3. Now both Sony and Microsoft get on my nerves with their ad campaign and hype machine so I tried real hard to ignore things that have been said in the past (which are so absurd I won't even bother to post them here). The question then was, which console offers the most for me, a self-proclaimed casual hardcore gamer. As far as game selection, the 360 wins hands down. I'm not just talking about the much hyped Gears of War or Halo 3, but other worthwhile titles like Just Cause and the soon to arrive Mass Effect. The PS3 is definitely lacking here. On the other hand, things are looking up with games like LittleBigPlanet and Eye of Judgment coming out (which is reason enough to buy a PS3 imo). Oh and CivilizationRevolution of course. :-)
Now the nice thing about the PS3 is that it doubles as a Blu-ray player, which appears to be winning the Hi-Def disc wars. Right now (until stock runs out), the PS3 60GB version is selling at $500, which is not too shabby considering it still maintains hardware backwards compatibility with PS1/PS2 via the emotion engine and vector units (and costs Sony $800 to manufacture. Ha, do the math!). To buy an equivalent Xbox (w/ HDMI) you'd have to get the $450 Xbox 360 Elite. For next-gen video, i.e. HD-DVD (instead of Blu-ray, which the 360 does not support), that's an additional $100 (I should mention MS has mandated this drive can never be used for games either, whereas PS3 Blu-ray can). Oh, and you want wi-fi internet access? That's another $100. So for an equivalent Xbox that can compete (feature wise) with the PS3, you're talking about spending $150 more!! To exacerbate the cost, the reported 30-60% failure rate is insane. I think you can already guess which console I went with.
Now I think for a while the naive approach most developers have taken towards games for the PS3 will result in a slight win for the 360 (thanks to great development tools, more on-die cache on the (same) PowerPC processor, unified (instead of segmented) video memory, predicated tiling with "free" MSAA, etc...), but once people start using the SPU's as they should be, things are bound to change. I give it two years time. Until then, I'm very happy with my new Blu-ray player. ;-)
The only problem I've run into so far is heat due to my keeping the thing in an enclosed cabinet. I'm not willing to sacrifice aesthetics (what can I say, I'm shallow), so I devised a plan to improve air flow and found a cute little usb fan that looks like it will work just nice. So after coming up with all this I decided to run it through my "this has to have been done before" filter and found someone who did the exact same thing (same fan even)! Props to you Mick, I'm sure this will work now!
So to change the subject a bit, I'm nearly done with a major overhaul to my new terrain system. I tried to come up with a good real-time continous LOD algorithm but I ran into a few initial problems. My first approach involved implementing a simple Binary Triangle Tree for polygon simplification (basically split a triangle at it's hypotenuse recursively until a max error level is met), which resulted in improved frame rates in high density terrains in the millions of polygons, but due to the triangle formation not being trivial I had to switch from using triangle strips to triangle lists which resulted in a HUGE performance hit, even with less polygons! I thought about using a 3rd party strippifier (like nvTriStrip) but it will most certainly add a lot of time to the precomputation (which is already somewhat long). I may investigate this in the future, but for now I decided to approach the problem slightly differently.
In addition to the terrain simplification I planned to incorporate a quadtree to split the terrain up. As I was doing this , I suddenly remembed a paper I had read a good number of years back by Thatcher Ulrich on something he calls Chunked LOD. The basic premise is so simple it's brilliant. The purpose of the algorithm is to be able to render massive terrains that could not possibly be rendered on modern hardware. To do this, you take your massive terrain heightmap and subdivide using a quadtree (a recursive structure that divides a 2D field into 4 sub-area's until some condition is met). Each sub-level however may still result in too large chunks (quadtree nodes), so some kind of simplification must occur.
For the simplification I merely resample the heightmap grid using a bicubic filter I coded up a while back (which looks just as good as photoshop's). I also map the height resolutions to some pre-determined max (for sanity's sake). As an example, a 8092x8092 terrain is WAY too large to display on modern hardware in real-time (it would be in the millions of triangles). If I was to decompose the quadtree to the 4th level, I end up with chunks sized 4096, 2048, and 1024. All of those sizes are still pretty massive, but lets say 1024 was acceptable as a max. Now instead of 8092 for the base chunk, we get 1024. For the next 4 sub-chunks we _could_ half the parent chunk's resolution, but this would result in a uniform distribution of points (not giving us better detail as the tree subdivides). By substituting the max for this number, I still maintain something close to my max from before, but increase the fidelity of the terrain mesh. So each level (including base) becomes 1024, 1024, 1024, and 1024 (the original high resolution version). In this case the lower levels (0, 1, and 2) lose some visual fidelity, but the highest level (3) maintains all of the original detail. This is important since this is the level the viewer will view closest.
Thats pretty much how my pre-processing algorithm works. In real-time I recursively render the tree and at each node, check to see if an LOD error metric for that chunk has been met. If not, I continue down the tree until there are no more nodes (leaf node) or we're at a tolerable error level.
The results so far are excellent, I'm very happy with it. The only problem so far is the seems at the edge's are still not acceptable even after implementing the terrain skirts like Ulrich mentions in his paper. I think this might have something to do with me not using enough levels so I'll hold off on trying to fix that further for now. The textures (dif/spec and normal map) are split in a similar fashion so I may be doing something wrong there as well to be causing the seems. The last thing I need to do is get terrain morphing working between levels to get rid of the unseemly pop when the LOD level is changed. I plan on doing something very similar to how I did the GPU vertex morphing for the Mona Sax facial animation demo. I'll have more on this later. Until then, here are some screenshots and a short video to demonstrate how it works!
One last thing! I tried to put into words what I thought of the movie 1408 which I finally got a chance to see last weekend as well as the Unreal Tournament 3 demo which I somehow found time to play. Unfortunately I just wasn't able to, so I leave you with this:
Yes, after all this time the game I've been working on at Firaxis has finally been announced!! Civilization Revolution is a continuation of the civilization series which takes it into a radical new direction (hence the interesting title). It's fast paced, visceral, and incredibly strategically engaging and has been an absolute pleasure to work on. It's been an incredible opportunity to be working with Sid Meier; definitely a a dream come true. I'm constantly learning something new and his level of genius never ceases to amaze me.
The game is set to be released next spring so everyone will have to wait a bit longer before they can play it but there's an announcement trailer floating around along with some concept shots (like here). In-game screenshots will probably be released within the next few weeks, which is very exciting since that will actually show off some of the work I've done related to rendering and general graphics work. The game is looking phenomenal and I think will definitely surprise some people who thought a studio like Firaxis couldn't pull off the next-gen look.
All in all it's very exciting to finally be able to talk about what I'm working on. It seems like so often everything I do is cloaked in secrecy. From one project to the next, I get maybe 6 or 7 months where my friends and family can know what I work on, then on to the next 2 year (on avg) secret development cycle. I suppose in modern times it's a necessity in order to avoid over-exposure (ehem, Duke Nukem Forever anyone?), especially on a game like Civilization that's constantly being tweaked and relies so much on iterative design to ensure the most balanced and enjoyable gameplay.
So even though the past few weeks have kept me very busy at work, I've still had a lot of time to get a lot done at home. I've taken up collecting Star Wars: CCG cards again, which is unfortunately quite an expensive habit (seeing as they haven't been made in years). It was probably my favorite card game growing up (more so than Magic: TG) and even after all these years impresses me with it's strategic complexity and depth.
I'm also really enjoying playing with the adorable little puppy we got about 2 weeks ago. It loves to keep me up at night which is just great... yeah. She's a miniature schnauzer, and incredibly cute, but, ugh, getting a new pup takes a lot of initial effort.
As far as Star Trader work, most of what I've been working on in the past few weeks as been conceptual design work. The combat system is almost completely planned out and just needs to be implemented. I have a document that's something like 20 pages long and goes incredibly in-depth into all the space combat specifics. The last remaining detail actually involves interface design and how a bigger ship's weapons will be fired by the player (for instance, the turret hardpoints on a capital ship as well as any energy beam emitters and torpedo launchers). I'm trying to keep things as simple as possible while still keeping the player involved (via tactile interaction). This means I'm shying away from automated firing but I think this may come back to haunt me.
I've actually gotten quite a bit of code work done as well. In the past few weeks I completely integrated the new very efficient font and gui element (quad) rendering I had prototyped a few months ago back into the main engine codebase. I can now basically render the entire GUI in a single draw pass if I setup my textures intelligently (by texture atlasing for instance).
I also completely revamped my entire GUI system to use xml. It supports a brand new animation system and uses a much better skinning solution which relies upon a few layers of abstraction to reduce complexity. A GUI file defines a layout and a skin. A layout once finished should never change and contains all the windows with the different gui controls that represent any given user interface. The skin file however contains control templates and properties, which define the look and feel of the GUI and can be changed at will. I have a feeling I'll probably be working on all of the layouts and templates and eventually when I get an artist to help out (hopefully sooner than later), he'll be swapping out new art and assets in the property files.
The other thing I finished was adding support for the 360 controller to the game. I recently purchased a wireless Xbox 360 controller and PC wireless adapter for this purpose. It's actually a great controller and works great for playing some Tie-Fighter or Freespace 2. So far I've only implemented controls for the new GUI stuff I had been working on but the plan is eventually allow for complete control of the game through the Xbox controller. Now I'm not of the mind that all game genres perfectly translate to a gamepad controller (first person shooters for instance will NEVER play as good as a mouse/keyboard combo), but I think that Star Trader really is perfectly suited to allow for all levels of control strictly from the gamepad. I actually think it may work even better than the mouse/kb and have a lot of great idea's about how to make the player interactions with the controller completely seamless requiring almost no thought. I'll have more details about this at some point but don't worry, I'm definitely planning on keeping things as simple and straight forward as possible. This situation is certainly something I plan to avoid.
Another thing I had been playing around with is screen-oriented billboard line drawing, which I plan to use these for lasers and exhaust trails (think Homeworld). Although the basic implementation is complete, there are a few issues I still need to work out. Basic laser projectile code is up and running though but I really need to get the ship combat system back up and running. It's been down for a few weeks as I've been revamping my entity management and zone systems. I basically NEED to finish my zone system by next week or progress with the game is going to be completely stalled. I have some idea's about how it should work but right now I'm trying to figure out the best way to implement it with the least room for programmer error (i.e. where's entities aren't accidentally placed in the wrong zone, or objects render incorrectly because of wrong zone ownership).
Alright, that's all I've got for now. Have a good one! Later!
I recently read an article on a study that discovered that the more educated you are, the longer it takes to answer simple questions. Forgive me for not having the link handy, but I'll summarize. The research concludes that more educated people have more points of reference to base their answers on, in other words more possibilities.
As an example, a (relatively) simple question to ask an American is "What battle represented the last major offensive by the Confederacy in the Civil War". The average person probably doesn't know this, but may have at least heard of Gettysburg, probably the most famous Civil War battle. A college graduate with perhaps a Masters in History will have a lot more perspective on the matter. In mere fractions of a second his mind will go through Antietam, Fort Sumter, Bullrun etc... A simple computer related analogy immediately comes to mind; a fragmented harddrive.
Unfortunately there's no Microsoft tool for defragmenting or re-indexing your brain (...yet) but it can definitely help to just step back, take a break and come back with a fresh perspective. I personally use fresh perspective to battle false assumptions and an over-abundance of information on a subject that clouds my ability to make a clear decision. Right now I'm taking a break from my Zone system for instance so I can come back when I'm ready with a clear head ready to tackle the problem again. Unfortunately it's been taking a while for this to happen...
So last weekend I did a hardcore coding binge and fleshed out a terrain prototype for Star Trader. I hadn't made a terrain engine in a long time so I got caught up in a lot of the simple details like grid creation, normals/tangents generation, indices ordering (for triangle stips), and grid resampling (I'm currently using bicubic filtering to overcome 8-bit heightmap artifacts). Texturing terrain was also something new I didn't have much experience in, specifically procedural texturing based on terrain properties. What I ended up doing was implementing a very simple real-time per-pixel "terrain splatting" algorithm, that takes a number of texture layers (like grass, rock, snow) and blends between them based upon a pixels altitude and slope. It looks pretty good but the algorithm I'm using right now is pretty rigid and doesn't allow for much alteration so I have plans to improve it. I also added detail normal mapping which looks great when you get real close to the terrain. Here's a teaser to show what I've accomplished thus far:
Like I said, needs lot of improvement, but I think it was a worthy first attempt. For comparison, here's some offline renders I made a number of years back for the Star Trader planet surfaces before I decided to convert to realtime terrain rendering.
The terrestrial/lush planet surface:
And the desert planet surface:
Comparatively the results aren't that different and I'm pretty sure I'll be able to achieve similar results once I get a sky and some aerial perspective in there.
One of my main goals for the terrain renderer was to allow for very high-polygon throughput. That shot for instance is pumping out over 1 million triangles brute force at about 60 frames per second on a Radeon x800 running at 1280x1024 with 6x MSAA. To achieve this kind of performance it really helped that I used triangle strips to keep the number of vertex indices down to a minimum. Another thing I made sure to do was keep the vertex size as small as possible. Right now it's at minuscule 24 bytes used just for the vertex position and normal. Everything else, like the tangent vectors and texture coordinates are synthesized on the GPU computationally.
I know this may sound counter to traditional thought but the main reasoning behind this is that while graphics cards have greatly improved their ability to compute complex data, bus speeds for transferring data to the GPU haven't really improved at the same rate. By maintaining a "skinny" vertex size I'm able to improve cache coherency as well as maintain instruction parallelism (since less vertex fetches are required). This is a much bigger deal on the next-gen consoles but is still very relevant in the PC world as well.
Now that I'm relatively happy with the performance I plan on moving on to sky rendering and aerial perspective, probably using the technique described by Preetham in "A Practical Analytic Model for Daylight", which is pretty easy to implement with incredible results. After this I want to finish up the per-pixel splatting, then I'll start integrating the prototype code into the main Star Trader codebase.
BTW, if you have any experience with Terragen or World Machine and would like to help with Star Trader, drop me a line. I'll be needing terrain for the variety of planet types which include Terrestrial (earth like), Ice, Water (underwater), Desolate/Barren, Desert, Mountainous, Volcanic, and Forest/Swamp.
I received my copy of ShaderX 5 yesterday and I must say they did an incredible job. As usual Wolfgang Engel has done an amazing job of editing the whole thing; quite frankly, I don't know how he does it.
My two contributions this year were 'Per-pixel lit, Light Scattering Smoke', and 'Post-processing effects in design'. I'm very happy with the end result and I hope people enjoy reading them as much as I enjoyed writing them. For those who read the article I should mention there was a minor issue where two figures where mixed up; On page 290, figures 5.2.2 and 5.2.3 are reversed. Where I say the light is behind the particle the figure obviously shows it in front, and vice-versa. It's a minor issue that is hopefully easy to figure out after reading the text.
So to go along with the planetary combat stuff I talked about last time I've decided to show some screenshots from Master of Orion 2. Their combat is a lot more simplistic than what I described but the visual look and style is very similar.
This first screenshot shows a drop ship landing on a planets surface. In MOO2 this represents a founding new colony. For STO this is more what I envision the marine drop ships looking like although I do plan to have a similar animation for planet colonization as well.
This shot shows off MOO2 planetary combat. I want to come pretty close to something like this.
Not bad huh? They really took advantage of pre-rendering back then to achieve such a high quality look but I'm completely certain I can make it look better today in real-time.
Posts
