I was curious, after looking at DBFZ does anyone know how much of a difference it makes creating a cell shaded game over a more realistic game? The two obvious differences are a more limited colour pallet, characters being comprised of fewer colours and thus less after work needing done, and then there’s the calculating of the pencil outline of each character, which I could imagine being quite intensive having to make sure that they’re outlined from every angle, as opposed to the same from all angles with no work required.
Does the smaller colour pallet save processing time and memory? Or do the intricacies of cell shading make it a much more intensive task for the console?
Cel shading takes considerably less of a toll on resources than realism does for a number of reasons. To keep it simple, it shows a lot less than a realistic game would.
The process to render outlines is done in a few ways. A really quick way to do it is to use the camera to determine where outlines should be based on the direction each polygon is facing. If a polygon is facing a certain angle that is perpendicular to the cameras angle, it renders a line. That is a grossly simplified explanation, but there you go. Games that want more control over where the lines are placed create special maps to add or block them. They also may paint lines directly into a texture. It’s weird to think of it this way, but cel shaded outlines are a post process (typically) similar to camera blur or bloom.
The trade off here is making a good looking stylized game in general takes a lot more labor than a realistic one does. Games aiming for realism can walk outside, take some pictures of real work textures, and apply those in game. They can also use fairly generic looking human characters and use mocap for animation. Stylized or cartoony games have to do everything from scratch. The interesting is that some cel rendered games can require more system resources but not necessarily because of the process to make them cel rendered. More often than not, in order to make a cel rendered game truly look like its a 2D game (like the DBZ game) you have to have a very large poly count on your models to keep them looking smooth. You can’t really use normal or displacement maps on cel shaded stuff the same way you would on a realistic model.
Cel shading is really easy to do. Most graphical programs come with presets for it, and it barely takes any memory at all. Even the N64 and PSX could do cel-shading and the technique itself hasn’t changed much since then. But it’s also really difficult to make cel-shading look good and like something you’d actually want in a game.
Most of the time, early forays into cel-shading lead to a garish, brightly colored mess. All textures and materials lose detail and you’re just left with something that looks quite awful and lacks any detail, looking like a clear plastic toy with thick black outlines and no easing into each shade of color. That happened with some early celshading tests I did for GigaMaidens.
ArcSys’s artists work their asses off to produce decent-looking cel-shaded games. If you look closely you’ll notice that the characters in Xrd don’t actually have much texture detail, mostly just shapes and lines that give the impression of texture detail. This is why every single thing on a Xrd character (belts, buckles, shirt buttons, fringes, etc.) are fully modeled geometric shapes. Most games would just handle certain details like those by just making them bump-mapped textures.
The the case of Unreal Engine 4, there is no cel shading preset. Between the programmers, and the technical artists, someone actually has to create the code for “cel shading”. This is why GGXrd uses UE3, because it was much easier to create shaders that are non-PBR (non-physically based render).
But seeing how this new Dragon Ball game uses Unreal Engine 4, it’s clear that they’ve had enough time to work on emulating their UE3 shader in UE4.
There are some caveats to this though.
Low resolution textures aren’t very noticeable in PBR, but in cel shaded games where they have to emulated line art on the textures, low resolution textures are horrible to look at because of compression pixelating all the strokes to look like blocks being faded and blurred.
This is why ASW developed a really strange solution to this, by restricting the UV mapping layout into quad-shaped islands, which makes detail textures sort of immune to compression artifacts.
As for the black edge outline, the PostProcessing method you described has some overhead to it for real-time applications, the fastest method is to actually duplicate the mesh geometry (assuming they’re a reasonable poly count for this), and invert it so all the normals point inward. This unfortunately doubles the poly count per character, and is memory intensive as a result (this method was used in all the Budikai and the Tenkaichi games). But as stated, it’s less overhead for the GPU compared to Post Processing methods.
Actually yeah that’s a good point and it’s something I definitely didn’t really get into in my post.
Honestly, with how powerful GPU’s are today, I’d much rather put more on the GPU than load a bunch of stuff into memory. That way, I can get shorter load times. Additionally I’m not terribly concerned about overusing the GPU in a cel rendered game. I will say that the method you described is essential if your game is low poly or if your platform doesn’t have a moderately powerful GPU. I guess it really depends on your platform in the end.