JeuxOnLineForumsPlusConnectés : 355 (sites) | 1425 (forums)Créer un compte
Star Citizen
Le point de Lagrange
Partager Rechercher
Avatar de Le Vagabond
JOL Le Vagabond
Alpha & Oméga
Avatar de Le Vagabond

[EN] explication technique détaillée des méthodes de création 3D utilisées sur SC

Citation :
Star Citizen is pretty impressive tech-wise, but I think that what exactly makes it impressive is sometimes misinterpreted and misunderstood by some fans. I work in the industry (not on SC though) and I sometimes see posts requesting other developers to "add PBR to make things detailed like in Star Citizen", or describing unsatisfactory content with "this is not PBR yet", or referring to ship detail being crisp because of "8k textures", misunderstanding the reasons behind lack of AA in the current releases, or attributing smooth shading on the ship surfaces to high res normal maps and so on and so on.

I think it would be interesting to let you know some real answers both for the kick of it (who wants to know how their favorite ship really works art-wise?) and to improve the outreach of this community - after all, if you're a fan of some other game and are attempting to ask a developer to implement something sweet and similar to Star Citizen, or arguing with someone about merits of SC, it might be good to actually understand how Star Citizen works so that people won't instantly dismiss you based on a technical misunderstanding you have.

So yeah. I'll try to cover some topics I have time for in the OP, and I invite you to ask anything you are curious about in the comments. **To reiterate, I'm not affiliated with SC**, I'm just familiar with workflows used by the artists there, especially since stuff like that is openly discussed in the industry communities like Polycount and at GDC.

**I will use lots and lots of images, so scan the text carefully, there are lots of hyperlinks to the images scattered around, illustrating almost every single point.** To make links easier to notice, I'll mark them with ▲ symbol. Shame reddit won't allow embedding of images, would've been easier to read all this then.


**I guess we can start with the ships**. Why are ships in SC looking so crisply detailed, exactly? What is their difference to ships from, say, Elite, or planes from DCS, or some other assets from some other games?

Well, it mostly comes down to two things (and nope, 8k textures aren't involved anywhere). The trick is the use of chamfered geometry with manually tweaked (face-weighted) normals, and the use of decals.

Let's recap how assets are done traditionally (crude simplification here, not touching stuff like LoDs and so on, but will show the point well enough):

* Author [high-poly mesh with all the detail ▲]( (like seams, rivets, panels, vents and so on)
* Author [low-poly mesh you want to use in the game ▲](, crudely representing silhouette without any surface detail
* Author texture mapping (UV layout) for your low-poly mesh by [unwrapping it's faces into 2d space ▲](
* Calculate and project ("bake", as it's called) some information from high-poly mesh to low-poly mesh, like normals and ambient occlusion, and [author final texture maps using that foundation ▲](
* Voila, [enjoy your asset in the game ▲](

Notice anything problematic? I wouldn't, it looks nice. Well, except for the fact that we have just delegated texture space to every single detail of that object. You can stack repeating elements, like that artist (Jake Oliver) did with stuff like wheels, threads and suspension, of course. But if you need to add another exhaust, another gun, another headlight, wings, wheels, whatever else, you are taking texture space from other elements.

Your UV layout will start [simple and innocent ▲]( for small props like this [air compressor ▲]( (by Marc Bolak), but it will grow more and more complex, harder and harder to author as you move to more complex hardsurface objects. For example, here is [UV layout ▲]( for a [Ka-50 helicopter model ▲]( (by Patrick Sutton). And then it will grow [yet more complex ▲]( when you want to do [something more detailed like that gunship ▲]( (by Brian Burrell).

Notice how maps in those examples grow bigger and bigger to compensate for the shrinking size of the islands in the UV space. That's natural - after all, you wouln't want ten pixels of your texture to cover a meter of your ship surface, right? You want crisp detail, even when you rub your nose on the metal in FPS.

Except at some point blurry detail is exactly what you'll get even with 8K textures, and you will die from old age before you unwrap something like a Constellation with such an approach. You can split your ship into a dozen of separate maps, but imagine wrangling such an amount of work within reasonable timeframe and imagine dedicating that much memory to textures of one ship. Even high-end loving SC artists wouldn't want to do that.

Wait a minute, though. Games routinely feature surfaces far bigger than those tanks and air compressors I posted above - for example, buildings. How do surfaces on those stay crisp? With tiling textures and slightly different approach to texture mapping, of course. I'll try to simplify the idea:

* Author a tileable (that is, seamlessly wrapping) set of textures (like [this one ▲]( by Hugo Beyer)
* [Map surfaces using it ▲](, with no real regard for any overlaps and tile boundary.

If you stick to one specific UV tile scale (e.g. 2x2m), you get nice results - your get evenly sized bricks, wood, metal or whatever else nicely covering both 100m long walls and 10cm long walls. Area makes no difference, you get the same texel density.

So that's what Star Citizen ship artists did. Here are all the materials used for the Gladiator, for example (taken from art post by Matthew Trevelyan Johns on Polycount): [link ▲]( So, the whole ship is split into areas covered with separate materials like those. You get [perfectly crisp surface detail ▲]( no matter the size of the ship, and if your surface is, for example, relatively smooth metal, you can get away with textures of laughable resolutions, like 512x512 or even 256x256. Nobody would notice if tiling maps are authored nicely.


That leaves just one problem. Take a good, long look at those shots of the Gladiator:

* [example A ▲](
* [example B ▲](
* [example C ▲](

It's covered with detail. Seams, rivets, vents, panels, bolts and lots of other stuff. It's all in textures, with exception of that big cutout in the second shot. It's impossible to get such a crisp detail by unwrapping all ship surfaces into an atlas and "baking" detail into it. And we already cover those places with our tiled maps. But where the hell would that detail come from?

Decals! And not just traditional decals that probably spring to your mind: blood splatter on walls in Counter-Strike, logos slapped onto cars in Forza, bullet holes in UT, forest moss slapped onto terrain around the trees in Skyrim. It's pre-modeled decals, specifically crafted to coved the ship geometry from a specially prepared atlas full of detail, with some interesting shader trickery I'll cover a bit later. First, let's take a look at the idea on more simple example. I prepared a few models.

* First, we decide what details we would need on our ship. As we have seen earlier - panels, rivets, vents, whatever else.
* [Then we model it, without sparing any polygons ▲]( This never goes into the mesh, so we can afford to make the detail as smooth and elaborate as we want.
* [Then we arrange the details into an atlas, and bake all that high-poly detail into a set of maps ▲]( We get ambient occlusion in the depressions, we get cavity map from, uh, cavities, we get normal map that allows us to light the surface as if high-poly geometry was there, we get height, curvature and so on. Lots of useful maps. [Here is an example of the normal map "baked" from my simple model above. ▲](
* Then we create a material with those maps, and write a special shader that can selectively blend components you want with the underlying surface. We configure the material according to our goals. Want to get bolts covered with paint from the underlying surface? Overwrite only normals and don't output anything else. Want to make scratch decal that makes some surface shinier from wear? Configure the material to overwrite only smoothness/specular/albedo. And so on. As far as I see, in Star Citizen ships, decals overwrite ambient occlusion and/or cavity and normals of the underlying surfaces, while preserving specular/albedo/smoothness.
* Then comes the fun part - we create isolated faces on top of the ship and map them to the decals! [Here is a simple example with some door detail mapped to various parts of another decal atlas ▲]( (from Polycount user Obscura), and [here is a simple example ▲]( from me. [And another one. ▲](
* Export into the engine, assign the materials we have created, boom, done! [Here is how that door looks ▲](, and [here is how my test model looks ▲](

This is incredibly versatile approach, one of the best you can come up with for hardsurface geometry like ships or modular level pieces. Probably an ill fit for characters, but for hardsurface stuff it's godly. Some advantages:

* Fidelity of detail is completely independent from the area of receiving surface. Even Idris, with it's, I don't know, square kilometer of hull surface? - it can get perfectly crisp 1cm rivets and tiny seams anywhere if artists want to place them.
* Detail is only authored once. If you want to redesign something - like, I don't know, change the number of sides on a bolt cap - you alter **just one** texture, the decal atlas, and get that detail instantly updated on every single object in existence. Good luck getting that iteration time with traditional models baked from manually decorated high-poly source - you will be spending weeks updating everything.
* You are using very little texture memory, which means you can use it in more fun places like UI or character unwraps or fancy explosions, instead of wasting it to draw 10000 blurry rivets. Really, with this, you never ever need 8K ship texture maps some people insist SC will use heavily.
* You get insane versatility from combining decals with tiled surfaces. You don't need to separately author rivet-on-red-paint, rivet-on-blue-paint, rivet-on-steel, rivet-on-plastic and whatever else combination of detail and eventual receiving surfaces, selective blending of PBR components in the decal shader allows you to use just one area of the texture for any surface imaginable.


But that's not all they have done. We have removed the need to use unwraps with normal maps for most of the surface detail, but there is one last use left: smooth edges. Everyone loves smooth, life-like edges on hardsurface objects. Sharp, aliased, hard edges shouldn't really exist. Usually, you get them by baking normals of smooth-edges highpoly model into a normal map of your runtime model. We don't have a normal map anymore. So what do you do?

Well, there is a solution, notably used in pretty much every single asset in Alien: Isolation and in most assets I see in Star Citizen screenshots. It's chamfered geometry with so-called face-weighted normals. I won't drag the post out with detailed explanation of that technique, I guess - just take a look at this simple illustration I have prepared:

* [Chamfering and face weighted normals (or why Star Citizen and Alien Isolation have the nicest wall panels in the universe) ▲](


Face weighted normals, liberal use of chamfering, use of premodeled deferred decals, and use of basic tiled textures on the underlying surface is, in my opinion, and incredibly versatile and fun approach to hardsurface modeling. I've been trying it out for the past month, and it's been an absolute breeze to work with. Nothing can compare for hardsurface objects of arbitrary surface area (hello, barrel, and hello, Idris, you get the same rivet today!), and almost nothing can compare in terms of iteration speed (slapping tiled materials around takes no time at all, authoring and mapping decal geometry is trivial) - you can shift the seams around, arrange detail in dozens of variations, experiment freely with the surface materials and so on.

This is all pretty great practice and I'm glad that Star Citizen (in particular, if I'm not mistaken, Foundry 42) artists are spearheading this amazing workflow. It's not totally novel, but they have demonstrated how to achieve incredibly great results with it.

Feel free to ask any questions in the comments, I'll try to answer them to my ability.

c'est assez super comme explication, je trouve

Connectés sur ce fil

1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés


Recherche avancée

Le wiki Star Citizen RSS

© JeuxOnLine / JOL. Tous droits réservés. - Conditions générales d'utilisation - Conditions d'utilisation des forums - Politique de confidentialité - Utilisation de mes données personnelles - ! Signaler un contenu illicite