Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Benadiba Laurent, posted on October 17, 2001

Image Description, by Benadiba Laurent

Here is a screenshot of my new cartoon rendering based engine ( k- Engine).

The engine currently features : Cartoon rendering, shader system with mesh deformation, multi - layers effect, texture animations, landscape ( with really low memory usage , and dynamic deformations ), skinning, animation, exports from MAX using FlexPorter, D3D8 TnL support, console, profile, debug, memory management systems, effects system ( particles, halos ), Anti Aliasing ...

The cartoon rendering, as you can see in the wireframe shots, use a fatter and black object precalculated at the load time and drawn with inverse backface culling.

This fat object contains only vertex buffer with the FVF XYZ ( without normals, and so on), so it is only 30 % more memory usage than using only the normal mesh.

The fat object is precalculated using the normal of each vertex, instead of an uniform scale wich does not give correct result for angles. The rendering is done using the ZBias function as mentionned before, to avoid Z Fighting, and can involve Anti Aliasing for nicer borders.

The shading is a two layers shader, with the texture and an environment mapped texture on it,

If you want to participate to the engine, just tell me, I like to work with other programmer !

Thanks !

Benadiba Laurent

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

October 17, 2001, 10:20 PM

Take that carrot out of your ass or I'll take it out for you.

I found the gamedev article useful. More useful than your insipid comments.

Rob Santa

October 17, 2001, 10:36 PM

Ahhh, quite the gentleman. :) Actually, you're all sort of off base. Call it what you will, "toon rendering" or "cel shading", but it's actually just a subset of imaging tech called "Non-Photorealistic Rendering". This cartoon style of rendering is just a small piece of the whole area of study. In fact, it's probably the easiest typ of NPR that one can do. There's not much to the concept either. There's the shader, the silhouette/outline renderer, and any sort of hatching that you see fit to use. Except for the generating a silhouette/outlines, there's nothing intensely CPU expensive about it.

You can all find TONS of information regarding NPR, including the cel/toon variations, here:

Rob Santa

October 17, 2001, 10:44 PM

No offense, but that's a rather silly remark. Then again, maybe it's just me. :)

IMHO, there's plenty of room for "realistic" cartoons in addition to the tradtional silly & bouncy varieties. Were that not the case, adult targetted animated movies such as Akira would not exist. I'd like to hope that the same holds true for game oriented "toons". It'd be a shame to waste this rendering technique on 1,000,001 Looney Toons or Power Puff Girls games. There's absolutely nothing that says that MORE realism makes for a better game. Gameplay's the thing. Know what I mean? That's one of the reasons why I look forward to playing the new GC Zelda game. (I know that many, MANY people will disagree with me on this.)

Rob Santa

October 17, 2001, 10:54 PM

Want theory? Here's nearly all you'll ever need on the topic:

Be aware that the most difficult issue of cel/toon sytle rendering is probably the silhouette/edge detection and drawing. In practice, I've seen a number of methods to handle this, some good & some bad. Included in this list are backface & z-buffer tricks, quad, line strips, edge buffers, sphere mapping, cube mapping, stencil trickery, or some combination of techniques.

The bigger issue is to get as much of it running in 3D hardware as possible and use as little CPU power. That's tough, but not impossible. Just as a footnote, anybody who tells you that you can get 100% "free" silhouette drawing for is lying to you. That includes NVIDIA and their environmental approach, which is dirty & looks like garbage in practice. You're best bet is just to devise a hybrid approach. You won't get the effect for free, but if done properly it'll use as few CPU cycles as possible. I've generated a hybrid technique for my 3D engine. I won't give away my algorithm, but just play with a combo of the above stated techniques and find what works best for you.

Rob Santa

October 17, 2001, 11:10 PM

Here's something else to consider.....

As you guys already stated, at a certain distance the object get smaller and thus starts to look like a "black blob" that no man can discern. Here's a potential set of solutions:

1) Since color and shape become ways to easily identify a far away object, why not totally eliminate the silhouette & detail edges once the object gets a certain distance away from the camera or when it becomes too small. Instead of just eliminating just one or the other. That's certainly a valid approach and there's a valid logic to it too. First, it would help to conserve CPU cycles since you'd otherwise waste them on a barely important feature set (at that point at least). Lastly, the human eye first uses color and shape to identify an object. Toby Guard wrote a Game Developer Magazine article relating to this some time back. Detail features are secondary and come into play only after a person identifies the basics. Because of this, the outlines are of particularly little importance for distant objects. Just take a look at how comic books handle very distant objects. Typically, they are just colored shapes with very little internal detail. It's stylized to be sure, but it's an optically friendly solution. You will be able to identify them even better perhaps since the introduction of a silhouette would merely obfuscate and taint the target object.

2) Another approach would be to design a LOD-based silhouette system where the detail & thickness varies according to distance. This is nice, but require a more intelligent algorithm for generating the outlines.


October 17, 2001, 11:27 PM

It would probably look something like this.



October 17, 2001, 11:30 PM

You could just use the DooM/Heretic approach and fade everything to black or a white mist in the distance, before Z-Buffering becomes an issue.
Or you could (God forbid!) use prerendered sprites like Wolf3D/DooM/Heretic when the distance is such that each pixel in the sprite is equal to or less than a pixel on the screen.
The sprite approach would be very CPU (GPU?) inexpensive, and in my experience, well done sprites can look as good (if not better per CPU cost) as textured meshes, so long as the resolution of the sprite is equal to or exceeds the screen resolution. In my opinion, the same rule should apply to textures: always make sure that bitmapped textures are higher res than the screen and use anti-aliasing - It makes it look VERY real. I use that technique (super-hi-res textures) in Adobe Atmosphere, and I end up with very real looking scenes.

Rob Santa

October 17, 2001, 11:46 PM

"The sprite approach would be very CPU (GPU?) inexpensive"

You are correct on BOTH accounts. CPU-wise, instead of processing tons of polygons and determinine visible edges you just have to determine when to push a sprite and which. That cuts the pipeline down drastically.
GPU-wise, instead of pumping out a 10,000 poly mesh you're just drawing a 2 triangle (or 1 quad) mesh. That'd translate to either 4 or 6 vertices, depending on whether you stripify or not. For obvious reasons, 2 triangles is much cheaper than 10,000.

"always make sure that bitmapped textures are higher res than the screen and use anti-aliasing - It makes it look VERY real. I use that technique (super-hi-res textures) in Adobe Atmosphere, and I end up with very real looking scenes."

That makes for a BIG problem though if you're trying this in real-time. Suppose you have 10 moving characters on screen at once. You're going to run out of texture space very, very quickly. It's nice in theory, but in practice it's really only suitable to image comp-ing in something like Photoshop. Keep in mind that the average user barely has a 3D card with more than 32mb of RAM. In fact, many still only have 16mb boards as a result of the great fragmentation in the 3d hardware market. You'll be putting a massive burden on the system with ultra-high detail textures. For creating the actual sprites, ultra high detail textures like 5120x5120 are okay's just a sprite.

Also if you're at the point where a sprite is necessary instead of the actual mesh then the chances of needing a high detail sprite are close to nil. You'll waste detail otherwise.


October 18, 2001, 06:37 AM

This looks very neat.
Seems very suitable for manga stuff.

That algorithm of yours is clever indeed, I'll try to remember it.

Good luck with your 3D engine.


October 18, 2001, 10:30 AM

Does the fat mesh really look that much better than the switch backface and redraw as thick lines method?


October 18, 2001, 11:36 AM

thing is, is a whole other mesh the best way to go for the outline, cpu wise? the way i did it was to draw the same mesh twice. again probably not the best way :/

in fact drawing another mesh does seem to give you a better quality outline, but what about shearing and intersecting? is it noticable? (obviously it would only be on the edges, what with the front culled on the mesh background)

the way i did it was to render the same mesh again with an outline, and the first with multtexturing to let me use 1D textures at the same time ( if you didnt see it the first time around in may/june or so :)

Rob Santa

October 18, 2001, 01:03 PM

My _guess_ is that it might not be too much of a problem .... as long as you flatten the so-called "fat" mesh Z-wise. If all you're using it for is the silhouette then Z detail soesn't matter, just Z & Y. Any incidental popup should be fairl minimized, relative to this method I suppose.

This is NOT the best method for drawing an outline though. It's clever to be sure, but it's CPU/GPU expensive. Automatically, you cut your potential scene detail in half since you're essentially drawing the mesh twice.

There are other methods available that seem just as valid. Last night, I was reading about one that involved the stencil buffer. Basically, it proposed "burning" the shape into a stencil and then expanding the stencil image to a desired thickness. It really seems to be a variation on the stencil-based shadow technique, which itself is clever. On 3D cards that support hardware stencil buffers that could actually be pretty fast. The only thing about this method though is that you'd have to be in 32-bit color mode. The GeForce2, for example, supports hardware stenciling, but only in 32-bit color mode (24-bits of color + 8-bits of stencil). In 16-bit color mode the stencil would be software only (i.e. slow). Still, in 32-bit color mode it should be pretty fast I suppose. The only thing to worry about then would be the interior detail, probably taken care of quickest with a sphere map.


October 18, 2001, 01:32 PM

FYI: Check out Gooch & Gooch's Non Photorealistic Rendering for the low-down on cartoon rendering.


Lars Birkemose

October 18, 2001, 01:32 PM

Looks cool, but Im not really impressed with the technique.
The models have a really large polycount for this use, and I guess lowering the polycount makes the black outline look weird when the model moves around.
How about billboarding the model instead, that would give you the black outline no matter what the polycount is.

Sami Hamlaoui

October 21, 2001, 06:35 PM

Ghost Face Killa: thanks for plugging my articles!

oh, and "Cell-Shading" is the correct spelling for those of us living in the UK (as someone pointed out to me in an e-mail).

i'm working on another cel-shading article soon (still not sure where to post the damn thing, although it will probably end up on yeah yeah stop yer booing) which will cover stuff like multi-texturing, multiple lights, and anything else i can think of. tell me if you have any ideas or features you would like documented.


This thread contains 45 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.