Rendering Smaller Sprites/Art Discussion

[svero]

So say I have a nice 3D model of some spaceship or something and now I want to put a nice final render of it animated into a game where the resolutions are pretty low and the final sprite won't actually be all that large. Lets say for instance the final ship will be 80x50 pixels roughtly. Maybe some artists who work in 3D would care to comment on how they approach this. Specifically Im interested in how one goes about keeping a nice level of clear detail on the shrunken model. For instance.. one problem you get shrinking stuff is it tends to blur. Here are some basic questions...

1) Is it better to have your 3d Renderer render out the sprite small or to render it out large and shrink it using a 2D algorithm?
2) If you render it small directly are there rendering or lighting or shading techniques that help keep the model clear?

I would be interested to hear how you approached this and whether any one method gets better results.

[Farmergnome]

Just make sure you use the sharpest rendering filters n settings you can, stay away from blury lighting efects etc, if your realy worried load it up in photoshop/whatever and pixel it up a little more, play around with some sharpen filters, or anything similar that grabs your fancy, pixeling it is probably my fav, but all depends how many frames of this models you need to render out.

[Sysiphus]

Well, I worked in a prerrendered comercial game years ago, for pc. Usually was used no antialiasing rendering. But depends a lot on the final sprite size, which often depends on whole screen resolution, etc.

It also depends a lot on the rendering package. In Max, you have a load of methods for antialiasing,(ie: catmull, etc) and differs a lot on which you choose. A bit of trial is recommended till u reach a point you are happy with.

The size of the sprite/tile is VERY important. There are like barriers, and from a size and down, is not worthy to use 3d...but pure pixel art, imho. The same, from certain size and up, it is a bit crazy to paint the stuff, but as allways, depends on the number of frames to do, etc.

Yep, often is better to do a render in big, and then use a good resizing method. I experimented a lot and found some specific numbers to do pixel art stuff which was worked in paper in huge quads. A crazy experiment, resizing with no resmapling.

usually that'd be crazy. A good resampling can be Adobe PhotoShop CS bicubic sharpened resample (or bilinear, depends on teh graphic, but bicubic+unsharp usually better) , and then apply carefully setting the good settings of an unsharp mask filter, in filters menu.

In Irfanview ( www.irfanview.com ) a lanczos resample is really good, too. That plus its simple sharpen, with very slight value.

Is trial and error.

If is a lot of frames, maybe even using something like Irfan Batch filter to apply a certain sharpen level to your perhaps 70 80x50 sprites at a time can be more clever.

If I have an spaceship of 64x64, I personally prefer 2d pixelling it from scratch, but that's me. I can do 3d or 2d, but I am liking more pixel art, lately. (and I tended to hate it! lol)

I personally love pixel art, I'd do the Leper's task he demanded with joy if I had the time (for money, of course) But sad thing is can't ensure easily any timeline, these days...argh.

[Sharpfish]

I had that trouble once on a shoot-em-up prototype I was working on for a gameboy advance game (not intended for commercial release, just a test project ).

Rendered the frames LARGE (1024x1024) then resized in photoshop (batch). The gfx for the then - intended PC version stayed sharp at I think 64x64 in 800x600 but on the gba they ended up looking like very poor attempt at pixel art (16x16 IIRC). Either way I would render them at high res and keep them as masters in case you want to use bigger sprites in future. And then just experiment.

[electronicStar]

better to render it large and then rescale/sharpen/blur it in a paint program.

[Fost]

Pretty much everything in Starscape has an unsharp mask filter at 1 pixel, 75-100% applied to the final rendered textures.

All the art in that game was built for being seen top down though - in fact, the texturing process was more akin to making a 2d hand-drawn sprite: planar map the model from above, and then draw onto it keeping its destination size in mind. That's maybe not something you can do using off the shelf models, or models that spin round an axis other than the 'into the screen' axis.

[Sparks]

In LightWave3D, I tend to either use one of the AA filters or the good old WaveFilter image filter plugin, which is quite good for post effects...
using the "spriteedger", I can do AA and still get a sharp edge.
Anything below 64x64 needs quite a bit of touchup, though, which means pixeling...

[James C. Smith]

In the games I have worked on we always try to render to the final resolution using the 3D rendering package. We usually use 3D Studio Max and render to a 32 bit image at game resolutions. It is very rare to ever “touch up” art in PhotoShop or any other program. I would try to avoid rescale/sharpen/blur in a paint program whenever possible. Let the renderer do that stuff using the full detail of the whole scene rather than just manipulating a limited amount of rendered pixels.

Real time antialiasing in your game engine can make a big difference with this kind of stuff (small pre-rendered sprites.) The most recent games I worked on all used 32 bit frame buffers. But even when I was working with 16 bit and 8 bit frame buffers, I still kept an 8 bit alpha channel for every source pixel and did realtime blending of source with dest for every pixel of every sprite. (With some obvious optimizations to not store alpha for the completely opaque pixels and not do a blend when drawing them. )

I know your question was more about what to do to the source image (not the engine) to make it look as good as possible. But sometimes improving the alpha capabilities of the engine is the best thing you can do to make your source images seem better.

[Optigon CG]

I render out of Max using the Catmull-Rom filter. This seems to be the best for rendering out small sprites. I've actually done comparison studies between 2 sprites rendered out of Max at actual size and one at double the scale and resized in Photoshop. The results were clearly sharper in the sprite that was rendered out at the actual size.

I also find it helpful to change the background color to a middle grey value rather than the default black. This helps judge the lighting and contrast and usually saves me from having to redo sprites because they were too dark or light. When rendering against black your eyes will tend to percieve things to be too bright when they really aren't. Just make sure to change it back to black before you do your final render otherwise you might get a slight grey outline on your sprite.

Jim

[svero]

I looked into the anti-aliasing options in Softimage and found some settings that produce a pretty good sharp result with small renders. There's no Catmull-Rom filter but there's something called Lanczos which works fairly well.

[oNyx]

I found that lanczos produces by far the best results if you really need to resample.

But rendering directly at the final resolution with insane quality settings should yield the best results obviously. With pov ray for example you can use ridiculously high quality antialiasing (eg recursivly up to 256 samples depending on the color differences of individual samples).

[James C. Smith]

I also find it helpful to change the background color to a middle grey value rather than the default black.

That reminds me of an interesting issue. When 3D Studio Max does edge anti-aliasing, it always blands the edge pixels with the background. This means that if you have a black backgrounds, all the edge pixels are blended with black. If your engine does not use the alpha channel to do real time blending and anti-aliasing then you probably want to set the background to some kind of neutral color that is similar to the background the sprite will usually appear on in the game. But if your engine does to real time blending using the alpha channel, you would think the background color used for the render wouldn’t matter. But it does matter since the edge pixels get blended with the background during the render. So our art processing pipeline (the code that impors a TGA into our game engine) has a stage that “unblends” the edge pixels, and any other pixels that are translucent. In other words, if a pixel’s RGBA color is (180,100,150,191) that would mean that the pixel is 75% opaque and 25% transparent. So we would assume that the RGB colors were blended with 25% of the background color. We always make sure the background color is black so that it is easy remove the background. In this case our “unblender” would change the RGBA to (240,134,200,191). Now if we draw this pixel over black at run time, it will blend in 25% black and end up looking liek the output from Max again. But if we render it over a white background, it will end up getting blended with white and none of the black from the Max rendering will be included.

I have tried to find a setting to make Max output 32BIT TGAs with the alpha stored in the A but without the RGB channels having the blending with background applied. I have never found a way to do it so we always just assume the image was blended with back and remove the back as the TGA gets loaded. Setting the background to grey wouldn’t really help since blending would still occur and it would be handed to try to “unblend”

[soniCron]

I have tried to find a setting to make Max output 32BIT TGAs with the alpha stored in the A but without the RGB channels having the blending with background applied. It sounds to me like you're using pre-multiplied alpha. I've found that saving a 32-bit TGA with pre-multiplied alpha turned off does the trick, no problem. However, it is important to render on a black background, for some reason.

[James C. Smith]

You’re right. “pre-multiplied alpha” is exact what I am trying to avoid. It was many years ago that we tried disabling that option in Max and it didn’t work correctly. I believe that option is been improved in new versions of Max but we never messed with it again since we have out “unblender” (un-pre-multiplier) working.

[soniCron]

Here's a scene created in 3DS Max 7, rendered with a black background, saved as a 32-bit TGA without pre-multiplied alpha, converted to PNG with Imagemagick*, opened in Photoshop, duplicated, and placed upon a background with the upper half filled black and the bottom half filled white.

*The only reason it was converted to PNG is because Photoshop won't open the TGA while preserving the alpha channel. Bit for bit, however, the image channels are identical.