Sci-Fi Citizens: Behind the Scenes

I decided to write up a little history on where these models came from, and paint a picture of the community of olde. In the second half of this write-up, I talk about the more technical side of things with the current release, in terms of how, in about 10 steps. Intertwined are my opinions and personal approaches to things like private/public releases, and end-user accessibility. I also offer some offhand tips of the trade, specifically in unwrapping and texturing, as well as some things I learned in this project.  If you want that, you might want to skip this first part, but I feel the purpose is as important as the technique. Also, word of caution, this is a technical article. If you don’t know terms used in source modeling, it might get a bit into technobabble.

the first shot of the white dress uniform

The first shot of the white dress uniform featured in Version 4

History – Versions 1-3

Genesis

It started back in 2009. I had just begun to build textures from scratch (vs. crude recolors), and my focus was making content for comics made in garrysmod. To understand the model, though, you need to consider the year in which it was made. Spacebuild and Half Life 2 roleplay were becoming giants, darkRP was in development.  In gmod comic making, 2009 was a decent year. It wasn’t quite the boom of 05-07, but there was quality work still being made. There were new, full-featured, story driven comics coming out every week or so. Most of them were based around HL2; more important to this project, there were plenty of very ambitious ones focused around hard sci-fi. Model porting from other games was still very much in is infancy; there were maps that were available to these authors as well as a few scant models, but generally, you were stuck with generic citizen skins, combine or palette swap recolors of them. (Unless you were -or were buddies with- a model hacker, then you’d just show off all your cool custom models from other games)

Given my newly developing texturing skill, I decided that it wouldn’t be a bad idea to make a generic looking science fiction outfit. The color schemes and cloth patterns were designed to just look spacey. I’ve had a lot of people come out and say that it looks a lot like uniform X from show Y, but really, I just copied the general tropes. I recycled resources from other projects; generic military badges, ribbons I had made up, shoes I had edited for Star Trek outfits. I created and released the entire pack of hexed males in under 3 days, complete with normalmaps and phong.

The short lived basic citizen reskin

The short lived basic citizen reskin

V2

V1 isn’t the version people got riled up about though, and most don’t even know it exists. The best thing they did was draw the interest of a model hacker, Taggart. This was when model hacking as a form was still new-ish, and most everything was slapped together from some mesh from the base game, Half-Life 2. Taggart had seen the work and sent me a picture of a model hack he thought could improve the design, a citizen torso with parts of a metrocop. Being ambitious, I told him he could combine anything he wanted and I could match the textures to make it all look like it belonged together. What we ended up with was one of the first ragdolls that used modular body grouping, and used bits and pieces from citizens, the g-man, metrocops, combine soldiers, and Barney.

The first musings of something beyond reskins

The first musings of something beyond reskins

I’m still proud of the work we did. They were well rooted in the HL2 design scheme, but it wasn’t some run-of-the-mill reskin. That release took about a month from v1.

Version 2

Version 2

V2.5

After a warm reception, we both had ideas to expand the project, and began immediately on improvements. We also added more bodygroup options and even a helmet from Fallout 3, c/o  Bloocobalt. A new release at that ping was an enhanced physics skeleton from nexus_elite, which this implemented for the males. I also got off my butt and textured female versions. This was a solid release, and we both moved on to other projects.

Version 2.5 was a solid step up

Version 2.5 was a solid step up in terms of options

V3

We didn’t make another version until another year passed, but v3 is the one that got the most mainstream use. People had brought up valid problems with v2.5, and there were always more bits and pieces that could use work, more little ideas. Taggart and I worked on this as a slow burn, adding a few things here, improving a few things there.  Between this and 2.5, Bloocobalt released the first version of enhanced citizens. They had some vastly improved physics, and featured new body and skingroups. We combined forces, and Bloo assisted us in implementing the new physics of his release into ours. Worth mentioning in the texturing front was the inclusion of a second color scheme and newly designed outfits. The texturing centerpiece, though, was the complete re-work of the metrocop vest. That was a project in of itself given the poor quality of the mesh, and I still see that work used in derivatives on RP versions of the metropolice and even worked its way into packs released as late as last year.

the project of projects

The project of projects

We added a retextured helmet from halo, another mainstay of sci-fi props in the custom model toybox on most peoples’ computers. We added berets with badges from mirror’s edge. When completed, the new version fit the role of ‘model amalgamation’ from several games. For this version, I convinced another friend of mine, Nirrti, to join in and model out a shoulderboard for ranks. All in all, it was a solid release pulling from 8 base models over 4 games plus custom work. It also opened the gateway to the most recent version of the combine officers, a paired down version with new textures and a more HL2 theme.

V3's dark color scheme and bodygroups

V3’s dark color scheme and bodygroups

Work on a version 4 did continue into 2011, but it slowly died down as I looked for more ambitious models to hack from. I wanted to scrap the HL2 meshes entirely, and implement newly discovered features like color enabled textures. I even prototyped a straight up reskin of the admirals from mass effect 2, but it faded into the background as Taggart and I focused on other projects. I had resigned to the fact that there would likely never be a v4.

A vision of the future of the project, here testing color enabled textures

A vision of the future of the project, here testing color enabled textures

The Present – Version 4

The Sci-Fi Citizens project has always been close to my heart, though. It’s not mimicking anything in particular and not following rules of canon for some show, and with that freedom, it was the testbed that I used to hone my skills and try new things. When I started to teach myself how to model hack, I asked myself what better project to do it on then with a new version of the sci-fi dudes?

Just because I internalized all of the labor doesn’t mean I didn’t get help along the way, though. Anyone that’s made a decent body of hacks that I’ve worked with got some steam chat message asking “how do I do this” or “why isn’t this working” or “can I get the source files to x.” As I developed the models and showed them off, a few people even came to me with good ideas and heads to add, and I’ve built a huge library of content to work with.

Over the last 3 years, the project undoubtedly developed its own style uniform and feel. Internally, to me, it developed project tenants:

  • Grab from as many sources as you can to achieve the look. Unified aesthetics are key. Work with people that do hacking already, you’ll never achieve as much doing everything completely yourself.
  • Keep the design generic and reusable. Backstories are ok, but it’s about what the end user wants it to be, not what you want. This is especially important in projects designed for community use at the core.
  • Keep it targeted to standards. Make it friendly to machinima, comic makers, roleplay, and anyone who’d like to use it to create their own story. If it’s obtuse to use for everyone but veterans in the field, it’s not because you’re too cool to stoop down to the level of beginners, it’s because you’re too lazy to go the extra mile for the average user.
  • Experiment and improve your craft. If you just churn out more of the same, square in your comfort zone, you’re not going to improve.
  • Deliver a quality product. “I did it real quick at 2am” just means you’re wasting your time. Always shoot for the top of your skillset or better or you’ll never improve.
  • Work smarter, not harder. Reuse what works, and don’t reinvent the wheel. Despite everything I’ve done in this project, I still use layer styles from the first version because they still look good. Just because you get something from a friend doesn’t mean you need to redo the work, it might be better than what you’ll be able to pull off anyway.
  • Start a project with the intent to finish it. You can do all the work in the world and it then rots, locked up on your hard drive until you reformat, what good have you served the community?

Using these tenants, I’ve tried to incorporate everything I could, and I think you’ll see where all of them come into play. I think these can be applied to most projects, though, and are good guidelines to follow, in my opinion.

1.  Source scouting

I decided to start from scratch. If I had the skill, I’d just model everything myself. I’m confident in simple modeling and am very experienced in all forms of texturing, but I don’t quite have the ability to do organic modeling, yet (v5, anyone?). Given this, I still wanted to deliver something of quality, and working from a base is never a bad thing, as long as you’re not going to call it your own.

Given the post-v3 work, I still felt that the Mass Effect 2 tunics would be a good choice. I also had nebulous ideas about legwear; pants from Kane and Lynch a skirt from Jesse in Dead Rising, and some nice boots from somewhere. I wanted it to be valve biped compliant and use the enhanced citizen skeleton and physics. Although this would prove to be a challenge given that my base model used a custom skeleton, I saw it as a good opportunity to practice rigging. This would also insure that I could source hands from the enhanced citizens (I don’t want to practice that much).

Heads would include the default citizens, anything less would be abandoning the ‘citizens’ part in ‘Sci-Fi Citizens,’ but I wanted to expand on the concept by adding new heads. This would mean more characters, and also allow me to build up a library of valve compliant characters for future projects. I had a target goal of adding more females then males; the community as a whole focuses on them less. All of the heads were given to me by various authors over the course of the project, so thank you to those who donated.

early work with the male model

Early work with the male model

2. Model making

Like I said earlier, I’m more confident at hard surface modeling, and this project allowed me to do a little of that. I custom modeled and textured the badges and headpieces. This allowed me full control in the design, and I could match the visual style of my sci-fi universe at large. The headpiece was a few simple primitives modeled around a HL2 default head, and manually resized and repositioned to fit all of the characters, and textured in Photoshop. The badges started as vector shapes drawn over a picture in Adobe Illustrator and imported into 3dsmax. (A tutorial on how to do this is on the Autodesk homepage). The ribbons were another simple model job, a series of boxes.

 closeup of the headset

Closeup of the headset

the raw modeled badges, before scaling and shaping

The raw modeled badges, before scaling and shaping

3. Hacking

This is the real meat and potatoes, isn’t it? Hacking is a very appropriate term for the process; it allows you to destroy and hack apart a finished product to make another one that the original creators had no idea it’d be used for. The hacking process is relatively straightforward. Starting with an imported skeleton containing the default citizen body, hands, and head, I simply imported mesh after mesh into the scene in max. If it was rigged to the valve biped, I kept the skeleton, if not, it was re-rigged. Keeping in mind that I intended modularity through bodygroups, I split the mass effect uniform into just the tunic/coat. I tweaked the proportions and scrapped the hands, following the citizen mesh as a basic size guideline. I moved the skeleton to match the arms after a few attempts at editing the mesh to do the converse, and later reimported the skeleton after the coat was rigged, so the arms would be force into the generic t-pose. From there, I filled in holes and tried to clean up the mesh. I imported parts for the legs, and over the course of about 5 months, had a nice collection of parts that came up to the final model’s mesh. I also scaled and fitted my custom models at this stage, the collar badges and ribbons were shaped and bent to match the curve of the tunic. In order to keep my working viewport simple, I extensively used object hiding and a very tight naming convention that I propagated between the max object names and exported .smd files (f01_beret, f01_headset_boon_out, torso_tunic, torso_ribbons, pants_legs_skirt, etc). Anything I could do in notepad I did in notepad, most notably renaming textures for same mesh models after compile. Why have a second object in max, like the gloved versions of the hands, when I can just open up the compiled .smd in notepad++ and replace all instances “hands” to “hands_gloves”? I tried to do as much of this as I could before I started doing more heads. Every change to a minor detail meant propagating it through all the already compiled models, meaning that even small changes would become big issues.  Even with all the planning and standardization, I had ‘little issues’ right up until the end, and opening up my max file without an in-depth explanation would likely confuse anyone that’s not me.

an early idea to add a sash to the model. Thank God that was removed before rigging

An early idea to add a sash to the model. Thank God that was scrapped before rigging.

One thing I did on the project that I’ll never do again is add a hat and a mutli-bodygroup head attachment. Every head meant reshaping the beret with soft selection, moving the badge, and exporting. The headset, because of its multiple specifically aligned parts, meant copying 5 models, breaking their rigging, moving them as a whole unit, and rerigging them individually. It was a slow and tedious process. A learning process.

5. Texturing & Unwrapping

As someone that’s been working with textures way longer then models, I decided to really go all out on this project. Everything that is not skin was completely retextured from the ground up. I also tried my hand at unwrapping a few of the organically shaped models, most notably the tunic. If you look into the files, you’ll see the male has a much better job done then the female, as I improved my craft a bit between the two. There’s nothing special about the job done there, I exploded the mesh by face angle and essentially started from a jigsaw puzzle I did follow a few experience based rules of unwrapping though. Here are things to keep in mind:

Pixel density and stretching: Ideally, every square inch of the surface would have the same pixel density, but this can be difficult to pull off, especially with complex shapes. What you really want to do is keep it mostly similar, but use natural seams (say, the transition between arm and chest) to play with sizes. Stretching can also be fun to deal with in the texture phase, and can quickly force a texture artist to completely rethink a design. This is hard to minimize on models with surfaces skinned to bones, but you should do your best to minimize it on the uvmap in the default position. Max has the option to apply a checkerboard while you’re unwrapping, use it. A few tips here would be to use vertical and horizontal alignment tools when applicable, stitching edges or breaking them as needed, and even using equal spacing tools if they work.

Mirroring: Although useful when improving pixel density as a whole, I try and avoid it when I can. It can get very obvious very fast, especially on anything aged or organic. It also limits the texture artist and forces them to keep things looking relatively plain. Adding words and insignia that need to be ‘read’ is also completely out.

Compacting and orientation: Obviously making everything as large as possible and still fitting it on the same texture is always nice. This comes down to how you stitched the shapes though. Keep in mind that it’s best to have a logical layout, as well. If size permits, keep things on the left side of the mesh on the left side of the texture, make sure things are pointed up, important faces are easily accessible and easy to find on the map. This isn’t always possible, but it’s a good practice. I’ve turned down projects that I was asked to texture because the unwrap was indecipherable.

Stitching: The fewer seams you have to deal with, the better. Make your seams coincide with natural seams of the shape, and try and hide them when possible. The benefit is twofold: freedom for the texture artist to apply texture and aging, and less noticeable seams when dealing with lower mipmaps. You can stitch shapes that share common seams by using the weld tool when working in vertex mode.

A side-by-side comparison of pre- and post-unwrap

A side-by-side comparison of pre- and post-unwrap

As for the textures themselves, the goal was to keep a very common theme since it is supposed to be a uniform. I did the layer styles essentially once and duplicated them into other documents as needed. This is a method I’ve developed under the idea of working smarter. By starting with a basecolor of #808080 and essentially doing everything in layer styles, I can visit any psd I’ve made in the past 5 years and copy the exact look in a few short clicks. I still manually shade wrinkles, but again using true grey on overlay, I essentially turn that into a toggle-able, scalable, independent layer that does not damage the base layers. This also helps when I generate heightmaps and exponent maps.

Another photoshop productivity booster I recommend is investing the time to learn what layer comps are. Go ahead, look them up. These babies allow you to store multiple versions of layer styles in a single document, and hides unused layers between comps. With a click of a button, you can go from diffuse skingroup 1 to skingroup 2 to heightmap to spec mask to exponent map to phong mask on a single psd, and changing the design of one existing layer propagates to the others automatically.

I did do a bit of sculpting on this project, the female boots were exported to mudbox and turned into a high poly sculpt. The seams on the boots were UV restrictive, and since they are basically black, creating the diffuse using a sculpt ambient occlusion, supplemented with Photoshop, seemed fair game. I did the same with the female gloves for the same reasons as well.

Mudbox boot editing

Cutting-edge mudbox boot editing

I did a fair bit of editing for the citizen faces. Most of this work was grabbed from old fakefactory heads as these are already aligned to the head. With substantial retouching and reworking, they actually looked okay at the end of the day.

The eye textures are also custom made. After the release of the enhanced citizens, I found using ideal colors for eyes meant they lit up like headlights when exposed to source lighting. Most of them are darkened and use custom color schemes via a grey base eye and a radial gradient map on top of a greyscale cornea for complex color.

I did intend for this release to utilize color enabled features, but that would kill transparency on hair and combine specular and phong masks.  Fear not though, every shader that I could pull off is in some way included in this release. (Diffuse, normal, spec, phong, masked rimlighting, translucency, self illumination, detail maps, exponent maps with albedo tinting, and complex eye shaders)

A color-enabled version, before the feature had to be scrapped

A color-enabled version, before the feature had to be scrapped

4. Working with flexes

So building facial flexes from scratch for custom heads was outside of the scope of this project. All of the heads are essentially donated, and only a few of them were actually placed on the valve biped skeleton. The common technique is to move the skeleton to the head vs. moving the head to the skeleton. While this does have its advantages (it does not break faceposing), it makes it a nightmare to maintain a single max scene for multiple models. To that end, I did some research into valve flex formatting and storage (.vta) files, and I came up with a simple tool that allows for translation of a mesh’s flexes in xyz coordinate space. In short, I move the head to the body, write down the values, and run a program that moves all the flex values in the .vta the same amount. This is an incredibly effective method for simple translation, but there are some caveats when you go the next step with reshaping the mesh. I found that if I edited the mesh (say neck or head shape) and those vertices were stored in the default flex (time 0, all vertices are indexed at their default spot), the compiler would make a half-successful attempt to move those edited vertices back to their initial positions. After some trial and error, I found that removing the ‘defaultflex‘ flex frame fixed the issue, and did not negatively impact the rest of the flexes. Furthermore, if I attempted to edit the vertices that are moved by standard flexes, some of them simply would no longer work.

the 'default' flex was deforming the mesh after export to source.

the ‘default’ flex was deforming the mesh after export to source.

As I dug deeper into the final polishing stages, I found many of the imported source heads I had access to had flexes for blinking, but it simply did not work. After talking a look at what the decompilers had thrown, I found that the functionality was still there, the .vta files had not been truncated or corrupted, but the .qci on export had simply not accounted for the corrent eye flexes. The L4D models had a ‘winking’ problem, where one eye would retain full functionality but the other would be unchangeable. This is because both eyes were referencing the same .vta frames of a single eye instead the separate ones for right and left. Once I selected the correct frames, it worked like a charm, and because those base flexes are used in calculations for other flexes related to eyebrows and cheek movements, once one started working, they all started working. Citizens had a similar problem, the eye flexes for those were in external, single flex .vta files, but the .qc was not properly set up to ‘extract’ them. A few misplaced brackets had reduced the functionality to nothing.

Because of my goal to release this project, it wasn’t feasible for me to implement TF2 style HWM flexes. The Left 4 Dead heads and Half-Life 2 citizens can still use reduced functionality HL2 style phoneme extraction in SFM, but the custom heads simply do not have that capability at all. It would be a huge undertaking to implement HWM at this volume,  but that would be a good goal if I were to pick up this project again.

6. Rigging

Rigging was a learning experience for me. I had never touched it in depth before this, and I must have rerigged that tunic 4 times and asked for help more than once. I spent time culling layered faces you could not see and occasionally poked out during valve standard animations. In the end, I ended up going to a few people for help, and it got four additional re-rigs from three people. I’d like to give credit to Ninja_Nub and FloaterTWO for their attempts, and Bloocobalt for coming in and saving the day.

at least I'm not the only person that has trouble, I gave three people a headache with these models

At least I’m not the only person that has trouble, I gave three people a headache with these models

man dude rigging is hard

Man dude rigging is hard

7. Building a filesystem

On a project of this size and scope, it’s important to reduce filesize whenever possible. The best way is to clean up and optimize textures and paths. In this case, every compile pointed textures to a few directories, including ‘shared’(storing things like eye textures, general masks and phongwarps, unisex clothing like the beret and ranks) ‘(fe)male’(skirts, tunic textures,  female boots and pants, hand textures for example) and the specific textures for the head in a subfolder of its own. Is an adapted technique from Squiddy, thanks buddy.

On texture compression, just do it. DXT1 for textures without masks, DXT5 for textures with them. Small textures (128×128 or less) don’t need to follow these rules rigidly, but larger ones do. Uncompressed textures are really only acceptable when they are critical resources and smooth gradients and true greys needed.  Also consider the size of the texture, generally 1024×1024 is good, critical textures, like the tunic in this project are allowable at 2048, and smaller, less important textures that don’t need a large pixel space can easily go with 512×512. Also remember normalmaps compress poorly in source and have the most obvious artifacts. If you can’t spare the space but can’t loose the quality, go down the next power of 2. Even cutting every edge I could, the uncompressed size for these 27 models was 300MB. That said, I could easily top 1GB if I simply didn’t optimize a thing.

8. Added functionality and optional features

If you’ve ever released a ragdoll on the workshop (or toybox or garrysmod.org) you know the first and most asked question is about NPCs and playermodels, followed by requests to literally port entire games, and occasionally for more sexually explicit versions. Most of these people are -quite frankly- stupid, self-entitled, and have no understanding of how much work goes into projects.

Scripted NPCs are spawnable non-player characters that use the LUA scripting language to drive actions and responses, and trigger animations. Generally, these are very poorly implemented in gmod, I have yet to see anything for standard ragdolls that is more then a poorly reskinned version of a generic/follower enemy that does nothing unless it is shooting at something. I’ve got no intention to work for months on a project only for someone to make a 10 second lua copy/paste and re-release the models as part of their own addon. There are two routes you can take with this: hunt down and destroy unauthorized repacks (which I’ll talk more about in the last section), or meet people half-way with the features you feel are a waste of time.

In light of that, I took the time to create custom viewmodel hands for playermodels, and added the required steps to make them fully compatible as gmod playermodels. On my end, it wasn’t that hard, just recompile the existing model with the appropriate animation $includes and under the ‘models/player’ path, plus 3 lines of lua code per character.

Four lines of .qc and one extra compile, and you turn those complaints into praise.

Four lines of .qc and one extra compile, and you turn those complaints into praise.

Playermodel arms were also pretty painless to author once I got past the initial frustration, (I had made a typo in the lua that wasn’t drawing the model initially. (Remember to explicitly write ‘.mdl’ when referring to models in lua.)) The resource examples for player arms attached to the garrysmod wiki include a lot of optional features like baked procedural bones and a truncated skeleton, but I found that exporting with a full skeleton worked fine, and although nice, learning the process to bake procedural helper bones (like the wrist, in this case) would add a great deal of work for very little improvement. Ideally, it’d be best for me to create or re-choose high resolution hands, texture those, make a high-poly sculpt of the forward arms and use that for the best quality. The people that would appreciate viewmodel hands, however, aren’t going to care if they’re 5 poorly textured polygons, just that they exist to the point where I can say “…and playermodel hands!”. Using the hands I made for the project gives enough to keep immersion, and is still way further then most people go for projects like this. More importantly, it’ll mean less comments complaining about the lack of it. A few hours of work before release could have potentially saved me the same amount of time responding to complaints.

9. Testing, hype, and Private Releases

So obviously there have been at least a few hundred iterations of these models tested across multiple branches over the last 6 months. I targeted release for SFM with backwards compatibility in gmod, and included everything needed to make them playermodels. Testing them independently also gave me ample opportunity to create promotional media, but an early release for additional promotional images and testing among trusted friends is also an acceptable way to increase a pool of release media. Other people can also comment on last minute bugs and help catch the kinks before the general public does. I recommend limiting the amount of private distributions to the last phase, though; seeing private models in the hands of anyone other than the creator(s) of the model is often infuriating and frustrating to the community. It doesn’t help anyone and only sows dissent and creates drama. A few days can build hype and excitement but a few weeks or months makes it look like you’re turning your work into vaporware or a private release for your friends.

a garrysmod test shot featuring the BLR skingroup

a garrysmod test shot featuring the BLR skingroup

10. Release

Release what you have worked so hard to achieve and release it in as many places you can find. This project is targeted for SFM and gmod workshops. The userbase in gmod’s workshop is pretty putrid, but it’s the best way to easily and legitimately share content and promote your work. Moreover, authors that make a popular mod -and don’t work to make it public and easily accessible- invite unsanctioned uploads and straight up theft. Pirates will never claim they made your work if you already have it well published and available in the same location. Releasing something to the public always invites theft, no doubt about it, but the key is to accept that, minimize it by being a better publisher, and stopping it when it does start to seed. Keep in mind though, that if you take down an upload, and it is not replaced with the same thing, all you’ve done is deprive the end users from an avenue to your work.

Try and maintain a consistent style to the release, be informative, clearly state what is and is not in the scope of the mod, take good pictures, and show off some of the unique features you worked on. Take videos if you can. If you have multiple branches (i.e. SFM and gmod) be sure to take pictures in both and focus the media on the version from that branch. If the features vary, don’t confuse the two.

IN CONCLUSION

I hope you both read this and learned something from it. It was a fun ride and in no means the end of anything. A release is an opportunity for community feedback and improvement, and with these out the door, I can pave the way for combine officer versions, and improvements to the enhanced citizens.

I have no problem giving out tips and tricks to the community, as it generally improves the quality of work of my peers. I know some of my suggestions come off as dogma and opinion, but I hoped you could tolerate it.

There’s a great deal that goes into a good release, and I’d like to take the time to once again thank the following community members for their assistance, and the following games for their source material.

Taggart – male_01 texture, male hands, partnership in the older versions

Wraithcat – pants/skirt/boots, kit head, additional heads

BlooCobalt – Skeleton, physics, female hands, final rigging

FloaterTWO – Generic female hair meshes, rigging

Nirrti – epulettes, citizen mouth texture

Squiddy – Female heads, phongwarps, file system architecture

Ninja_Nub – additional custom heads, rigging

-Rusty- – citizen head textures

Simkas –K&L porting backend

Haxxer – ME2 officer ports

Plasmid – female skirt/legs (DR Jessie)

FakeFactory – head texture base files

Dean – Comedic relief

———

Half Life 2 – base skeleton, Mossman’s hands, base eye shaders, citizen pants

Dead Rising – Female legs, pumps

Eve Online – Skirt, female boots

Kane & Lynch – male pants

Mass Effect 2 – Tunic/Coat

Mass Effect 3 – Female hair meshes

Dragon Age 2 – Hawke Head

Sin Episodes – Jessica head mesh

Final Fantasy XIII – Fang head mesh

L4D – Beret, heads

L4D2 – Ellis’s hands, heads

Max Payne 3 – Male heads

Battlefield 3 – Heads

Here’s some pictures:

a late development promotional shot

A late development promotional shot

a mid development promotional shot

A mid development promotional shot

And a link to the downloads, of course.

http://steamcommunity.com/sharedfiles/filedetails/?id=173932955

http://steamcommunity.com/sharedfiles/filedetails/?id=173932955

One Response to “Sci-Fi Citizens: Behind the Scenes”

  1. Wish you released those v3 models, the security looks nice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: