august 1998latency in online gaming by optimizing packets, setting bandwidth limits, accommodating...

V

AUGUST 1998

G A M E D E V E L O P E R M A G A Z I N E

If you were in the early stages ofdeveloping an Internet-basedgame last year, and you heardabout a company that “provides

game and simulation content develop-ers with a software solution to buildand deploy stand-alone and network-based applications that make full use ofinteractive 3D graphics,” would youinvest in it?

Apparently not too many people did,because Newfire Inc. — whoseCatalyst/Torch products supplied theabove marketing quote — died a quietdeath last spring. Maybe I’m overlysentimental, but I was disappointedthat the company couldn’t stick it out.I really want to believe that there’sroom in the industry for a game enginecompany.

In the wake of its passing, I’ve beenconsidering whether a company likeNewfire can be successful. I’ve spokenwith a number of game developers aswell as employees at various tool com-panies on this subject, and it’s beeninteresting to hear the different takes.While I haven’t come up with a pat for-mula for success (like I’d still be heretyping if I had), I have some observa-tions to share.

I think the biggest hurdle that gametool companies have to clear is the “notinvented here” (NIH) bias that manygame developers harbor. And it seemsthat the more core functionality a toolattempts to provide, the more skeptical-ly it’s viewed by developers. There’s apervasive attitude — which is notentirely unfounded in my opinion —that shrinkwrapped game engines can’tcut it at the core of a game. A tool com-pany trying to sell such a product along road ahead of it.

First, there’s the credibility issue thatthese companies have to overcome withgame developers. Developers ask, “Whoare these people providing this technol-ogy, and why should I pay so muchmoney to them instead of coding thefunctionality myself?” A pedigree ingame development or a related field isnecessary to even be considered.

Second, the solution needs to solve aproblem that developers want a solution

to. I’m assuming you, a Game Developerreader, are passionate about game devel-opment and enjoy working on your pro-ject. Would you want to hand off a goodportion of your game’s core functionali-ty to an off-the-shelf solution? Itdepends, right? Management might beinterested in purchasing a product if itcan shave some weeks or months off of aschedule, but if the tool upsets the devel-opment team and causes some talentedpeople to bolt, those considerations canweigh in against the investment.

Third, developers need to see a proofof concept. Epic MegaGames, id,Monolith, and others can get away withlicensing their engines for hundreds ofthousands of dollars because theirgames say more about their enginesthan any salesperson or datasheet could.Newfire, which was selling for a fractionof the cost of these engines, couldn’tcompete because there weren’t any titlesto hold up and say, “Here’s what it cando when put into the hands of a client!”

Finally, to make matters tougher for acompany like Newfire, there’s thealways contentious issue of pricing. Theluxury pricing of the QUAKE and UNREAL

engines not only provides great addi-tional revenue for their developers, itensures that only a top developer will beable to afford to license it, that thosethat do will be heavily incented to dogreat things with the engine, and thatthe engine won’t be seen in too manyother titles. To put this in a differentlight, I think Newfire would have beenequally in trouble had it further loweredits price (it was already a fraction of theQUAKE and UNREAL engines) and suc-ceeded in licensing out its engine tohundreds of companies. Would theselicensees (or the gaming public) behappy with a slew of games that lookedstrikingly similar? I’ll wager that thefolks at Newfire considered these possi-bilities and had contingency plans toupgrade their engine or increase pricingif demand picked up, but nevertheless itpoints to the fragile nature of theirproduct’s economic model. ■

G A M E D E V E L O P E R A U G U S T 1 9 9 8

4

P L A NG A M E

Requiem for a

Game Engine Company

EDITOR IN CHIEF

MANAGING EDITOR

DEPARTMENTS EDITOR

ART DIRECTOR

EDITOR-AT-LARGE

CONTRIBUTING EDITORS

ADVISORY BOARD

COVER IMAGE

PUBLISHER

WESTERN REGIONAL SALESMANAGER

EASTERN REGIONAL SALESMANAGER

SALES ASSOCIATE

MARKETING MANAGER

AD. PRODUCTION COORDINATOR

DIRECTOR OF PRODUCTION

VICE PRESIDENT/CIRCULATION

ASST. CIRCULATION DIRECTOR

CIRCULATION MANAGER

CIRCULATION ASSISTANT

NEWSSTAND ANALYST

REPRINTS

CEO-MILLER FREEMAN GLOBAL

CHAIRMAN-MILLER FREEMAN INC.

PRESIDENT/COO

SENIOR VICE PRESIDENT/CFO

SENIOR VICE PRESIDENTS

VICE PRESIDENT/PRODUCTION

VICE PRESIDENT/CIRCULATION

VICE PRESIDENT/ GROUP DIRECTOR

SENIOR VICE PRESIDENT/SYSTEMS AND SOFTWARE

DIVISION

Alex [email protected]

Tor D. [email protected]

Wesley [email protected]

Laura [email protected]

Chris [email protected]

Jeff [email protected]

Josh [email protected]

Omid [email protected]

Hal Barwood

Noah Falstein

Brian Hook

Susan Lee-Merrow

Mark Miller

Naughty Dog Inc.

Cynthia A. [email protected]

Alicia Langer(415) [email protected]

Kim Love(415) [email protected]

Ayrien Houchin(415) [email protected]

Susan McDonald

Dave Perrotti

Andrew A. Mickus

Jerry M. Okabe

Mike Poplardo

Stephanie Blake

Kausha Jackson-Craine

Joyce Gorsuch

Stella Valdez(916) 983-6971

Tony Tillin

Marshall W. Freeman

Donald A. Pazour

Warren “Andy” Ambrose

H. Ted Bahr

Darrell Denny

David Nussbaum

Galen A. Poss

Wini D. Ragus

Regina Starr Ridley

Andrew A. Mickus

Jerry M. Okabe

KoAnn Vikören

Regina Starr Ridley

Miller FreemanA United News & Media publication

www.gdmag.com

Polygon DecimationRAINDROP GEOMAGIC is releasingthe geomagic Decimator in July, and isshowcasing it at SIGGRAPH 98.

Decimator is a polygon reductiontool designed to increase the renderingcapability of any machine by greatlyreducing the number of triangles in thesurface mesh of a 3D model. Duringthe decimation process, this softwarecan improve the quality of the surfacemesh while simultaneously preservingsurface curvature and proximity to theoriginal surface. The tool allows you toselect regions on a model to preservedetail or reduce complexity. The inter-active decimation command allows

you to press a button and watch thepolygons disappear, one by one, in realtime. Features include the ability toimport and export 3D model formats:.STL, .OBJ, .3DS, .VRML, .DXF, .WRP;selective or global real-time polygonreduction; editing capabilities; flat andsmooth shading; wireframe and shadedviewing options; surface improvementwith refine operations; and add-and-move-points operations.

Decimator works on Windows 95,Windows NT, and Silicon Graphicsworkstations. The suggested retail priceis $295.■ Raindrop Geomagic Inc.

Champaign, Ill.

(800) 251-5551 / (217) 239-2551

http://www.geomagic.com

G A M E D E V E L O P E R A U G U S T 1 9 9 8 h t t p : / / w w w . g d m a g . c o m

6

BIT BBBB LLLLN E W S F R O M T H E W O R L D

P O R T A L S I T E S on the web just awoke tothe luring power of games. Excite andInfoseek announced alliances with TEN tooffer Java-based multiplayer parlor games.Both sites now offer Spades, Euchre,Hearts, Chess, Checkers, and various wordgames, with more on the way. Excite plansto use TEN’s automated ranking system andhost tournaments as well. S E G A O P E N E D I T S K I M O N O andrevealed details about its upcomingWindows CE-based Dreamcast console,which launches in the fall of 1999 inAmerica. The 128-bit console features aHitachi RISC processor, PVRSG graphicshardware, a Yamaha 3D sound chip sup-porting 64 audio channels, and has built-innetworking features. An interestingDreamcast feature is its visual memory sys-tem, a console memory card that doubles asthe world’s smallest LCD-based portablegame device. P A R R Y I N G S E G A ’ S A N N O U N C E-

M E N T , VM Labs let out some informationabout Project X. Project X is essentially anembedded technology which will belicensed out to consumer electronics com-panies for use in devices like home DVDplayers, digital satellite receivers, and set-top boxes beginning in 1999. Motorola has anon-exclusive license to develop, manufac-ture, and sell semiconductors and systemsbased on the VM Labs technology. Toshibaand Thompson Consumer Electronics (mak-ers of GE, RCA, and ProScan brands) willincorporate Project X technology into prod-ucts next year, and Activision, Capcom,Psygnosis, Hasbro, and Berkeley Systemsare working on content. P E T E R L I N C R O F T , a senior programmerfor Totally Games who worked onLucasArts’ X-WING VS. TIE FIGHTER, X-WING,and TIE FIGHTER has left to form AnsibleSoftware in Berkeley, CA. Ansible will spe-cialize in the science fiction genre, and

I N D U S T R YW A T C HI N D U S T R YW A T C H

b y A l e x D u n n e

Massively Multiplayer SDKVR•1 INC., a developer of massivelymultiplayer online entertainment,announced that its VR•1 Conductor SDKis now available.

The SDK, a component of the VR•1technology suite, allows you to buildmassively mulitplayer games on theVR•1 Conductor platform, which powersonline-only games such as MICROSOFT

FIGHTER ACE. VR•1 Conductor lessenslatency in online gaming by optimizingpackets, setting bandwidth limits,accommodating varying modem speeds,and monitoring client and server CPUand network performance. It also facili-tates network administrative functionssuch as game management, security, and billing. VR•1 Conductor SDK users canalso take advantage of VR•1’s Global Game Alliance, a strategy for partnering con-tent developed on this platform with online gaming providers around the world.The charter members of the Alliance are six network providers that have endorsedVR•1 Conductor technology: Sony Communication Network in Japan;Bertelsmann Game Channel in Germany; British Telecom’s WirePlay in England;Samsung SDS and DACOM in The Republic of Korea; and Videotex Netherlandsand KPN Telcom’s Online Service in the Netherlands. VR•1 expects to announcenew alliance members in the coming months. ■ VR•1 Inc.

Boulder, Colo.

(303) 546-9113

http://www.vr1.com

Cockpit view from MICROSOFT FIGHTER

ACE, which is powered by the VR•1

Conductor platform.

Geometry Box IIGEOMETRIC COMPUTING hasreleased the Geometry Box II SDK, areal-time 3D software development kit.The SDK contains three distinct ele-ments: the Geometry Box Architect IIDatabase Development Software, theGeometry Box InfiniteMotion II Real-Time Rendering and InteractivitySoftware, and the Geometry Box ClassLibraries II.

These components are used to pro-duce different elements of interactivesoftware applications. The Architectsoftware creates virtual worlds (databas-es) that players explore. You can place-actors in the world and apply pro-grammed behaviors to the actors. Youcan also use the Architect to store work-ing versions of databases, and to createoptimized, real-time ready versions ofdatabases that InfiniteMotion can loadand play back. The programminglibraries are used to customize differentaspects of InfiniteMotion, and to createplug-in behaviors that Architect canload. The key use for the programminglibrary is the creation of behaviors thatyou can apply to actors and execute inInfiniteMotion. Geometric claims thatGeometry Box streamlines the develop-ment process through its integration oftools and conversion processes withreal-time rendering. Geometry Box IIcan be used for PC and arcade develop-ment, and has a suggested retail price of$595 (plus $20 shipping). ■ Geometric Computing

West St. Paul, Minn.

(800) 334-8494

http://www.geometricom.com

K6-2 with 3DNow!AMD introduced the AMD-K6-2processor featuring 3DNow! at thisyear’s E3 in Atlanta.

The AMD-K6-2 processor combines3DNow! instructions and superscalar

MMX capability to increase 3D graphicsperformance. By improving the x86processor's ability to handle floating-point calculations, 3DNow! technologylessens the gap between processor andgraphics accelerator performance andeliminates the bottleneck at the begin-ning of the graphics pipeline. 3DNow! isa set of 21 new instructions that useSIMD (Single Instruction Multiple Data)and other performance enhancementsto clear out the bottleneck between thehost CPU and the 3D graphics accelera-tor card. The instruction set acceleratesthe front-end physics and geometryfunctions of the 3D graphics pipeline toenable full performance of the accelera-tors. This clears the way for improved3D and multimedia performance. TheDirectX 6, OpenGL 1.2, and 3Dfx GlideAPIs are all optimized for 3DNow! technology.

The AMD-K6-2 processor is currentlyavailable. The AMD-K6-2/333 is pricedat $369; the AMD-K6-2/300 at $281;and the AMD-K6-2 at $185, each in1,000-unit quantities.■ AMD

Sunnyvale, Calif.

(800) 222-9323 / (408) 749-5703

http://www.amd.com

h t t p : / / w w w . g d m a g . c o m A U G U S T 1 9 9 8 G A M E D E V E L O P E R

7

AAAA SSSS TTTT SSSSO F G A M E D E V E L O P M E N T

plans to release an action simulation titlein time for Christmas 1999. C R E A T I V E T E C H N O L O G Y ’ S R E V-

E N U E S and gross margins for its fourthquarter (ending June 30) fell short of ana-lysts’ expectations. Revenues for the quar-ter are anticipated to be about 10 percentlower than revenues for the same quarterlast year. Despite the strong demand for itsVoodoo2-based cards, the company saidthat the recent collapse of prices in thelow- and mid-range 2D/3D graphics marketreduced Creative’s margins and sales.T H E A C A D E M Y of Interactive Arts andSciences (AIAS), a sister to the Academy ofMotion Picture Arts and Sciences (thinkOscars) handed out its first-ever InteractiveAchievement Awards at E3 in Atlanta. Thebiggest winner of the evening was Rare’sGOLDENEYE 007, which received threeawards, including “Interactive Title of theYear.” Full IAA results are available atwww.interactive.org.A C T I V I S I O N just inked some nice licens-ing deals. First, it signed on Marvel’s X-MEN, which will debut next spring as a 3Dfighting game for the PlayStation. Next itlanded the rights to White Wolf’s“Vampire” role playing universe, which issecond only to AD&D in worldwide players.Nihilistic will turn that one into a 3D RPGfor release in the fall of ’99. Finally,Activision landed rights to the movie, TheFifth Element.T H E I D S A released an economic impactreport about the interactive entertainment(IE) industry. First, it states that the comput-er and video game industry (a subset of theoverall IE industry) racked up $5.1 billion inretail sales last year, and generated anoth-er $500 million on video game rentals.Second, the videogame and computer gameindustry grew over 35 percent in ’97, mak-ing it the fastest growing segment of theentertainment industry — ahead of records,movies, and books. Third, the IE industrydirectly employs at least 50,000 US workers(up 18 percent from two years ago) and17,000 abroad. Finally, total R&D spendingin the industry reached $2b in 1997, and theaverage company invested 30 percent of itsequity funding into R&D.

Correction. The Bit Blasts section of the

June 1998 issue contained an announce-

ment of the new Miles Sound System

4.0 from RAD Game Tools. The phone

number listed for RAD was incorrect.

The correct number is (801) 322-4300.

It felt to me as though games had real-ly hit the big time. I’m not talkingabout when the press declared a mar-riage between Hollywood and thegames industry a couple of years ago.That was just a brief, over-hyped flashof what was to come. What has reallyhappened since then is that gamedevelopment has become a major

force in computer graphics technologyand artistry.

For years, I’ve searched throughcomputer graphics literature trying toimprove my craft. Up until now, I’vegenerally found game graphicsbetween five and twenty years behindthe state-of-the-art in computer graph-ics. When we were using Bresenham’sroutines to scan convert a polygon,they were trimming NURBS surfaces.When we were applying an affine tex-ture to these polygons, they wereapplying specular lighting and bumpmapping to an alpha-blended, perspec-tive-correct textured micro-polygon.But we’ve been steadily catching up.

The Hardware

M uch of our recent burst of speedhas come from the consumer 3D

hardware market. Affordable, high per-formance 3D hardware has brought us

power that was previously only avail-able in the realm of the Reality Enginesand graphics supercomputer worksta-tions. This past year, we’ve seen theante upped time and time again. We arenow at the point where the Christmasofferings from all the 3D card manufac-turers should come very close to BrianHook’s dream in his September 1997

column (“All I Want for Christmas ‘98Is a Hardware Accelerator That Doesn’tSuck”). In fact, many of the offeringsfrom the card vendors are exceedingeveryone’s expectations.

Let’s take a look at the fall offeringsin consumer 3D hardware shown at theCGDC this year.

Z-Buffering

L ast year, we all agreed that a 16-bitZ-buffer was a reasonable baseline

for all 3D consumer hardware for 1998.But it was hardly ideal. Many applica-tions on the market suffer from Z-alias-ing artifacts even on these 16-bit Z-buffers. When you’re creating a gamethat requires resolution of near ele-

ments as well as distant objects, 16 bitsof Z (or even W) are not enough. So,what did the card manufacturers haveto say about this problem?

3Dfx was prominently displaying itsVoodoo2-based boards. This board stilluses 16 bits for the depth buffer.However, the buffer is now a 16-bitfloating point number, and 3Dfx hasadded the ability to use this as a W-buffer, effectively increasing the farview Z precision.

S3 was the surprise of the show. Aftertaking more lumps than the Presidentlast year, S3 came out with a shocker. Iwas one of the many who, when toldthat I needed to visit S3’s booth, said“Yeah, right...” I was then told that Ireally needed to check it out, and boy,am I glad I did. Their Savage 3D madequite an impression. The display ofTUROK running on a Savage 3D andbeating Voodoo2 in performance wasquite a sight. But what really interestedme was the support for 24-bit depth andcolor buffers. As of the CGDC, these fea-tures were not yet being exercised, but Ilook forward to seeing them in action.

Nvidia wasn’t showing the new TNTboard on the show floor (it was shownto selective people behind closed doors),but the numbers they were quotingcouldn’t be ignored. The full-featured24-bit Z-buffer should effectively elimi-nate most Z-aliasing problems.

Matrox was showing their new MGA-G200 card with a full 32-bit Z. However,they also were awaiting drivers to really

Looking Forward with a Backward

Glance at the CGDC

A nother Computer Game Developer’s Conference is over. I spent lots of

time talking to friends, checking out the hot new products, and gener-

ally catching up on the state of the industry. This year, I returned feel-

ing more enthusiastic than ever about the game business.

b y J e f f L a n d e rG R A P H I C C O N T E N T


8

I’m not talking about when the press declareda marriage between Hollywood and the gamesindustry a couple of years ago. That was just abrief, over-hyped flash of what was to come.

Is coming up with new technology all that Jeff Lander and the crew at Darwin 3D doat their home on the Digital Riviera? Mostly. But Jeff can also be seen helping in therehabilitation of Marine Mammals along the So Cal coastline.

put the 32 bits through their paces. It’snot clear to me at this time if this carduses the full 32 bits for Z or if the Z-buffer is 24 bits with 8 bits for a stencil,like the Nvidia TNT.

The NEC Power VR SecondGeneration (PVRSG) doesn’t really havea Z-buffer, but it does use 32 bits of pre-cision to handle polygon sorting. Ihaven’t tried one of these boards outyet, so it’s tough to say how that willcompare with traditional Z-buffering.

Color Buffer

W e’ve seen the 16-bit color bufferbecome the standard for con-

sumer hardware this year, but it hasproblems. Anyone who has rendered ascene with smooth gradients has wit-nessed the banding problems associatedwith 16-bit graphics. But a hidden prob-lem is the one associated with multipassrendering. As fill rates increase and two-pass texturing becomes more common,alpha blending will be used more andmore. With only 16 bits of color preci-sion, severe quantization errors canoccur. An increase to 24 bits for colorreduces this effect tremendously.

Another problem with 16-bit colorbuffers is that there is nowhere to storealpha information per pixel. This meansthat in order to render alpha-blendedscenes correctly, the polygons need tobe drawn in the correct order. All alpha-blend textures must be drawn after anypolygons behind them. Two passesthrough your polygon database aresometimes necessary to get this ordercorrect. If several alpha-blended texturesoverdraw each other, those polygonsmust be sorted in order to be drawn cor-rectly. By storing 8 bits of alpha in the32-bit color buffer, these considerationsare eliminated.

There is good news on this front aswell. The S3 Savage 3D and NEC PVRSGcards allow a 24-bit color buffer, and theNvidia TNT and Matrox G200 cards sup-port 32-bit buffers with full 8-bit alphabuffering. Figures 1A and 1B demon-strate the difference between a 16-bitimage with 1 bit of alpha and a full 24-bit image with 8 bits alpha, both on theNvidia RIVA 128.

Image Quality

B ilinear filtering is now the normfor 3D accelerated hardware. The

Voodoo2, Matrox G200, and S3 Savage3D all add single-pass trilinear filtering.The Nvidia TNT and NEC PVRSG addanisotropic filtering for even betterimage quality and less texture distor-tion in polygons viewed at an angle. Allthese cards now support per-pixel MIP-mapping. Lack of per-pixel MIP-map-ping was the most noticeable graphicsproblem with the Nvidia RIVA 128, andthankfully, the TNT corrects this.

The display resolutions are also goingup. Game developers can really start toconsider much greater resolutions.Cards were displaying acceleratedimages at as high as 1,600×1,200 in 32bits of color.

Texture Compression

A GP has allowed greater access totexture memory then ever before,

but it’s still not as fast as storing texturesin chip VRAM. In order to maximize thenumber of textures that can stay inVRAM, some hardware cards have cho-sen to implement hardware texturedecompression. Both the Voodoo2 andthe Matrox G200 cards support forms ofhardware texture decompression. S3supports a texture decompressionmethod that has been accepted for usein Microsoft’s DirectX. However, it’sunclear to me how this would become astandard, as S3 is seeking a patent onthe technique. I don’t see any greatincentive for any other hardware com-pany to support their standard. As adeveloper trying to make everything

work on every card, I would hate to seeeach card manufacturer implement acompletely different compressionmethod. Unfortunately, right now,that’s the way things are shaping up.

Texture Restrictions

I t seems that restrictions on the sizeof textures may soon be a thing of

the past. Both the Nvidia TNT and S3Savage 3D support textures up to2,048×2,048 textures with no sizerestrictions. Is anyone else out therestarting to think real-time film resolu-tion? I know I am.

Multitexture Support

Q UAKE has started everyone think-ing quite a bit about multipass

rendering. Hardware companies are tak-ing this very seriously. They’re squeez-ing out the maximum fill rate possiblefrom their chips in order to handle theoverdraw necessary for multipass.

The 3Dfx Voodoo2 was first out of thegate supporting two-pass rendering of asingle polygon in hardware. By allowingtwo textures to be combined in onepass, not only does it eliminate vertextransformations, but it also effectivelydoubles its fill rate. These calculationsare actually done internally in 32-bitprecision, eliminating the quantizationerrors that can occur when textures areblended in a 16-bit color buffer.

The Nvidia TNT is the second con-sumer card to announce two-pass ren-dering, with an even faster fill rate thanthe Voodoo2. This, combined with itsdeeper color buffer, should allow the

G R A P H I C C O N T E N T


10

F I G U R E S 1 A A N D 1 B . A demonstration of the difference between a 16-bit

image with 1 bit of alpha (1A), and a full 24-bit image with 8 bits of alpha (1B)

both on the Nvidia RIVA 128.

creation of tremendously compellingimages.

DirectX 6, which was released theweek of the CGDC in beta form, con-tains API support for multitexture ren-dering. Developers can detect if thehardware supports rendering of multi-ple textures in a single pass. You can seea sample image of multitexture render-ing in action in Figure 2.

As multipass rendering in consumerhardware becomes common, developerscan start to exploit the rendering possi-bilities. Multipass rendering can make adifference in your application. Take alook at the images in Figure 3A andFigure 3B. Figure 3A is a scene lit with-out shadow maps and Figure 3B showsthe maps applied. The resulting changeof mood in this scene dramaticallychanges the player’s experience. Lookforward to effects such as shadow maps,environment maps, and detail texturesshowing up all over the place. DirectX 6even supports what they Microsoftterms “bump mapping” by using multi-pass techniques. This green light fromMicrosoft has caused all the hardwarevendors to add “Hardware BumpMapping” to their product sheets. I’msure this technique is nothing like whatJim Blinn had in mind when he coinedthe term in 1978. Still, this “embossedtexture mapping” is quite effective. You

can see a sample 3Dfx demo of the tech-nique in Figure 4.

Programming API

B oth Direct 3D and OpenGL werevisible all over the place at the

CGDC. Questions regarding card man-ufacturers’ support for OpenGL wereclearly addressed by all the driversshown, either through a mini clientdriver (MCD) or full installable clientdriver (ICD). I can only hope that thesedrivers will put an end to the constantdiscussion of Direct3D vs. OpenGL inthe development community. It seemsthat, finally, the choice is completelyup to the developer, at least untilFahrenheit rears its ugly head again.

Geometry Acceleration

A ll of the next-generation 3D accel-erators are moving what is called

triangle setup into hardware. These arethe triangle calculations that the cardmust make before applying the texture.The addition of full triangle setup hasimproved speed quite a bit, however,the cards still rely on the on-board CPUto handle geometry and lighting pro-cessing.

In order to speed this up, geometryand lighting will need to move to hard-ware as well. We saw our first glimpseof this happening at the show. Whileit’s not a consumer card, the 3DlabsGLINT GMX board demonstrated thecomplete OpenGL pipeline acceleratedin hardware. The board handled full-view frustrum clipping, 16 dynamiclight sources, and support for allOpenGL rendering primitives com-pletely in hardware.

This method of allowing a coproces-sor to handle all the transformationand lighting calculations is fairly con-troversial in PC programming circles.Questions linger about the need for ageneral lighting model or the transfor-mation speed in the era of ever-expand-ing CPU performance. However, theconcept of a transformation and light-ing coprocessor is familiar ground forPlayStation developers. Certainly, theoption is attractive assuming the pricedrops into the consumer’s grasp.

The other benefit of committing thetransformation and lighting model tohardware is that it opens the door to atrue Phong shading model and bumpmapping in 3D accelerators. Theseeffects require that the hardware havethe camera matrix and light informa-tion. The 3Dlabs GMX really addressesnone of these issues, but certainlyopens the door to the possibility. Itshould make us all consider what it iswe want from the next generation of3D hardware. Which brings me to...

The Software

N ow that SIGGRAPH is here again,it will be interesting to see how

SIGGRAPH compares to the CGDC.This year’s game conference reallypushed the envelope with discussionsof new computer graphics technology.The freedom brought by the new waveof hardware will provide an unprece-dented amount of bandwidth in gamesfor new techniques. It really seemed tome that the theme of the CGDC, atleast from a technology standpoint, wasscalability — providing the richest,most realistic experience possible on alllevels of end-user hardware.

G R A P H I C C O N T E N T


12

F I G U R E 2 . Multitexture rendering in

action with DirectX 6.

F I G U R E 4 . Embossed texture map-

ping from the 3Dfx Voodoo2.

F I G U R E S 3 A A N D 3 B . 3A is a scene lit without shadow maps, 3B has shadow

maps applied, both on Nvidia TNT.

Why is this necessary? Well, hard-ware is moving ahead so quickly, gamescannot keep up. Consumers are buyingnew hardware to run the latest games,and there’s no way for them to makethe experience any better. 3D games arerunning on today’s hardware at as highas 1,600×1,200 screen resolution, in 32-bit color, with all features turned on at60 frames per second or more. Thismeans that the game has failed at beingable to provide a better experience forplayers on these new systems. It’s notenough to run the game at higher reso-lution and color depth at faster framerates. Games should be customizable tothe point that they can drag any hard-ware down to its knees. This is whatwill give a game legs to stay on the cut-ting edge through more than one hard-ware production cycle.

So how do we do this in a real-time3D game? Scalability. First of all, youneed to represent your 3D models insuch a way that they can scale to thehardware dynamically. The concept oflevel of detailing (LOD) in 3D modelshas been around for a while. Many ofthe games out there today have mod-els in several LODs to aid performance.But to make the game truly scaleable,you need many levels of detail. Inorder to avoid the popping effect(when models change from one LODto another), it’s necessary either toblend between models, or to provide aform of continuous level of detail. Thegame community seems to accept thisconcept. At the CGDC, there were atleast five sessions on forms of continu-ous LOD generation of 3D models.They seemed to fall into one of twocamps — multiresolution modeling orhigher-level primitives.MULTIRESOLUTION MODELING. With mul-

tiresolution modeling, a mesh is madein the highest resolution and is algo-rithmically reduced as needed to thedesired level. The work Microsoft hasbeen doing in progressive meshes, ledby Hughes Hoppe, has brought thistechnology to the attention of gamedevelopers. At the CGDC, StephenJunkins of Intel gave a very good talk.He spoke about another method for cre-ating these meshes based on the workof Michael Garland and Paul Heckbert.Intel has teamed up withMetaCreations to define an open fileformat for multiresolution models. It’sunclear to me what they mean by

“open” exactly, but a standard formatthat could be used by tool vendors, aswell as developers, would be very help-ful. MetaCreations was also demon-strating a tool that could be used to cre-ate these models. You can see a sampleof several LODs generated from thistool in Figures 5A, 5B, and 5C.

In my opinion, the biggest drawbackto this technique is the lack of artisticcontrol as the algorithm reduces themesh. This leads to a situation where,given the same polygon budget, a talent-ed modeler can create a much betterlow-polygon mesh than the algorithmcan generate. However, it seems to methat these routines can be modified toallow artistic guidance in the tools. I willexplore this idea more in a future issue.

HIGHER LEVEL PRIMITIVES. The other bigarea of discussion was “Is it time toabandon polygons?” That is, in order tocreate truly scaleable environments, isit necessary to create these worlds andobjects out of a higher form of primi-tive? Several sessions were devoted tothe topic of creating worlds withNURBS and other surfaces, and thenconverting these to polygons (tessellat-ing) at run-time to the desired LOD.Michael “Sax” Persson of Shiny dis-cussed a method of converting a polyg-onal character to a collection of primi-tive cylinders for MESSIAH. Creatingmodels of higher-level primitives that

can be quickly converted to polygons istricky. This is clearly an active area forresearch in the game industry, and Iwill be looking into these techniques,as well as many others, in the comingmonths.

Enjoy SIGGRAPH, and we’ll get backto coding some of this new technologynext month. ■


13

For information on the 3D cards men-tioned, contact the manufacturers.www.3dfx.com

www.metastream.com

www.nvidia.com

www.powervr.com

www.s3.com

www.real3d.com

www.matrox.com

www.3dlabs.com

For software scalability information checkout:www.metacreations.com

www.shiny.com

http://www.research.microsoft.com/re

search/graphics/hoppe/

Michael Garland’s web page athttp://www.cs.cmu.edu/~garland

Paul Heckbert’s web page athttp://www.cs.cmu.edu/afs/cs/user/p

h/www/heckbert.html

FF OO RR FF UU RR TT HH EE RR II NN FF OO

F I G U R E S 5 A , 5 B , A N D 5 C . High, medium, and low LOD models generated

with the MetaCreations tool.

It’s not enough to run the game at higher res-olution and color depth at faster frame rates.Games should be customizable to the pointthat they can drag any hardware down to itsknees...

If you didn’t read last month’s column, this one may betough slogging for you — that’s why there’s a review sidebar(“What is Texture Blending?”). Once we’re prepared, we’llstart with a technical introduction to texture blending proce-dure in OpenGL, then work through the OpenGL 1.2 specifi-cation itself, line by line. After that, we’ll tackle some exam-ples, and finish with some applications for all of thisknowledge.

Texture Blending in OpenGL Simplified

I n general, textures are blended in three steps: fetchingthe textures to blend, setting the blending method, and

causing the blended texture to draw. Simple, right? Here’s alittle more detail about how the blending method is con-trolled in OpenGL. First, grab a pixel from each of the twotextures we’re going to blend. Add the two pixels after multi-plying each one by its own translucency. Then put theresulting pixel on the screen.

The second step is where the realaction is. We artists want to know howthe blending method is controlled, andhow the math works inside it. The play-ers are the two input pixels (named ssoouurrcceeand ddeessttiinnaattiioonn), their personal factors(named ssffaaccttoorr and ddffaaccttoorr), and an out-put pixel. Here’s the Sacred BlendFormula that relates these:

oouuttppuutt__ppiixxeell == ssoouurrccee ** ssffaaccttoorr ++ ddeessttiinnaattiioonn **

ddffaaccttoorr

What’s sacred about this formula? Asidefrom the fact that it’s part of the OpenGL1.2 specification, the magic is speed. Ifyou’re working on a hardware-accelerated3D game, the 3D accelerator chip can cal-culate this formula. Hardware calculationmeans that you can use the Sacred BlendFormula all over the place without slow-ing down the game. However, the calcu-lation is being done in hardware, so it’sessentially hard-wired, and so unlikemost formulas, we can’t simplify it.

We must use all the players in the for-mula because they’re hard-wired, but we

can work around them by making them useless. For exam-ple, if we want to add but not multiply, we set ssffaaccttoorr andddffaaccttoorr to 1. We want to do that during an additive blend, forexample. Say we have a light gray pixel (80 percent white)and a dark gray pixel (10 percent white), and we want toadditive blend them. In this case, we set ssffaaccttoorr and ddffaaccttoorr to1, and then run the formula:

oouuttppuutt__ppiixxeell == 8800%% ** 11 ++ 1100%% ** 11

oouuttppuutt__ppiixxeell == 8800%% ++ 1100%%

oouuttppuutt__ppiixxeell == 9900%%

Wow, that was easy! No problem! Let’s do a multiplyblend. For this, we want to eliminate certain terms and mul-tiply pixel values.

oouuttppuutt__ppiixxeell == 8800%% ** 1100%% ++ 1100%% ** 00

oouuttppuutt__ppiixxeell == 8800%% ** 1100%%

oouuttppuutt__ppiixxeell == 88%%

b y J o s h W h i t eA R T I S T ’ S V I E W


14

Josh White runs Vector Graphics, a real-time 3D art production company. He wroteDesigning 3D Graphics (Wiley Computer Publishing, 1996), he has spoken at theCGDC, and he cofounded the CGA, an open association of computer game artists.You can reach him at [email protected].

Advanced Texture Blending

T his month, we artists aren’t going to mess around with vague analogies —

no, we’re going to get to the heart of the matter. If we’re going to claim to

be experts, we must sneak onto the programmers’ turf, climb down into

the mechanical heart of the beast, and grasp the 3D API specification itself.

T exture blending is

the combination of

two textures on a

3D model. QUAKE

lighting, translucent textures,

glowing light-sabers — these

are all uses for texture blends.

Figure 1 is my standard exam-

ple of texture blending.

As last month’s column

explained, blending is best

understood by looking at what

happens to a single pixel. For each pixel in an alpha blend, the computer checks if the

alpha channel is white. If so, it outputs the pixel from the foreground bitmap. If not, it

discards the foreground pixel and doesn’t output anything, which leaves the back-

ground pixel unchanged.

What is Texture Blending?

F I G U R E 1 . Texture blending combines two

bitmaps.

Devious, eh? We used the second pixel’s value (10 per-cent) where the ssffaaccttoorr went before. Now that we’re feelingcocky, let’s jump into the deepest end we can find.

ggllBBlleennddFFuunncc Explained

T he function ggllBBlleennddFFuunncc is at the heart of texture blend-ing. If you can understand exactly how it works, then

you can understand the lowest level of texture blending pro-gramming. Now we’ll tour the OpenGL 1.2 specification.The first line reads

vvooiidd ggllBBlleennddFFuunncc(( GGLLeennuumm ssffaaccttoorr,, GGLLeennuumm ddffaaccttoorr ))

If you’ve never seen C code, you’ll be confused by thatline. The word vvooiidd means that the function doesn’t returnanything; it just runs without reporting back. The stuff inparentheses tells us that the function takes two inputs, ssffaacc--ttoorr and ddffaaccttoorr. The word GGLLeennuumm before ssffaaccttoorr and ddffaaccttoorrmeans that they are a type of data called “enumerated.”

Here’s how the OpenGL 1.2 specification describes thisfunction:

ggllBBlleennddFFuunncc defines the operation of blending when it isenabled. ssffaaccttoorr specifies which of nine methods is usedto scale the source color components. ddffaaccttoorr specifieswhich of eight methods is used to scale the destinationcolor components.

Note that this passage has introduced some interestingterminology. “Scale” means modifying a color’s RGB values.If it had said “scaling down,” it would have meant darken-ing the color.WHAT IS ENUMERATION? Enumerated means an ordered list ofnames. For example, eennuumm ccoolloorr == ((rreedd,, ggrreeeenn,, bblluuee)) coulddefine color to be one of three color-names. Enumerateddata types aren’t really smart; they’re just dumb lists. If weset ccoolloorr==rreedd,, there wouldn’t be any connection betweenthe word “red” and RGB 1,0,0; it just stored as the firstitem in the enumerated list. So why not just store a num-ber instead of a name? Names provide clarity in coding.Enumerated data types are there for the convenience of thecoders.

So what are these possible enumerated types? Here’s whatthe specification says:

ssffaaccttoorr:: Specifies how the red, green, blue, and alphasource-blending factors are computed. Nine symbolicconstants are accepted: GGLL__ZZEERROO,, GGLL__OONNEE,, GGLL__DDSSTT__CCOOLLOORR,,

GGLL__OONNEE__MMIINNUUSS__DDSSTT__CCOOLLOORR,, GGLL__SSRRCC__AALLPPHHAA,, GGLL__OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA,,

GGLL__DDSSTT__AALLPPHHAA,, GGLL__OONNEE__MMIINNUUSS__DDSSTT__AALLPPHHAA,, and GGLL__SSRRCC__AALLPPHHAA__SSAATTUU--

RRAATTEE..

So, it says that alpha is being treated like a fourth colorchannel. That’s interesting, because it’s not quite how Iexpect artists to conceptualize alpha channels. To me, analpha channel is more like a separate image that is associatedwith the colored image rather than a fourth color. This isimportant because it points out a difference in artistic think-ing that is happening at the code level. Artists should be

involved in designing this techie stuff so that they haveinput on the architecture in which they work.

For ddffaaccttoorr,, the same types are listed, except thatGGLL__SSRRCC__AALLPPHHAA__SSAATTUURRAATTEE isn’t included. It’s an interesting list, andwe can guess a few meanings just from the names, but it’snot definitive. Let’s keep going with the specification.

[There are] eleven possible methods... Each methoddefines four scale factors, one each for red, green, blue,and alpha. In the table and in subsequent equations,source and destination color components are referred toas ((RRss,, GGss,, BBss,, AAss)) and ((RRdd,, GGdd,, BBdd,, AAdd))..

Note that color components are like what we call “chan-nels” in Photoshop. That wasn’t so bad, right? Don’t worry,it gets harder:

They are understood to have integer values between zeroand ((kkRR,, kkGG,, kkBB,, kkAA)), where kkssuubbcc == 22^̂mmssuubbcc -- 11 aanndd ((mmRR,, mmGG,,mmBB,, mmAA)) is the number of red, green, blue, and alpha bit-planes.

Wow, that’s a heck of an explanation there. It’s as preciseas you can get in English, but it leaves a bit to be desired ifyou’re not a coder. Translated to casual English, it meansthat each color is a number between 0 and a maximum. Themaximum depends on the color depth of the pixel.WHAT’S COLOR DEPTH? Color depth refers to the idea that animage has a thickness or depth, measured in bits. More bitsmean more accurate colors in the picture (and more memoryused). Here are some examples: if we have 32-bit color, we’vegot 8 bits for red, green, blue, and alpha. With 8 bits for red,we can have 255 unique values, from 0 to 255 (as opposed to-127 to 128 or something weirder). Here’s another example:if we’re working in 16-bit color, we could have 4 bits for eachchannel, which is known as 4444. With 4444 color, we have16 separate alpha values that range from 0 (fully opaque) to15 (fully transparent). There’s another kind of 16-bit colorcalled 5551, which gives 5 bits for each color channel, butonly 1 bit for alpha. So if we had 5551 16-bit color, our redchannel would have 32 possible values (0-31), but our alphacould only have two possible values, 0 and 1.

Now I’m sure you’re wondering, what about 8-bit color?It’s special because 8 bits would only allow 2 bits (four colors)per channel, it uses a palette or index system instead of sim-ply storing the RGB values. In fact, it’s so special that blend-ing can’t handle it at all. The specification says so in thenotes section: “Blending affects only RGB rendering. It isignored by color index renderers.”

Still following along? We’re getting to the good part here.

PPaarraammeetteerr ((ffRR ,, ffGG ,, ffBB ,, ffAA ))

GGLL__ZZEERROO ((00,, 00,, 00,, 00 ))

GGLL__OONNEE ((11,, 11,, 11,, 11 ))

As you probably guessed, GGLL__ZZEERROO and GGLL__OONNEE are simply theminimum and maximum values. You can think of GGLL__ZZEERROO asa fully transparent, black pixel, and GGLL__OONNEE as a completelyopaque, white pixel. You detail-obsessed people should notethat these values range from 0 to 1, not 0 to 255.

A R T I S T ’ S V I E W


16

GGLL__SSRRCC__CCOOLLOORR ((RRss // kkRR ,, GGss // kkGG ,, BBss // kkBB ,, AAss // kkAA ))

O.K., here’s a real one to study. What the heck is that lineof gibberish? Being artists, we’ll start with some guessing.First, we’d guess about the name. SSRRCC__CCOOLLOORR probably meanssource color, right? Let’s see. RRss is the red channel of thesource image. kkRR is the maximum value for red. If we dividethem, we get the red channel converted to a numberbetween 0 and 1. For example, let’s say we had a blue-purple24-bit pixel with a 50 percent alpha. Its RGBA channels are16, 0, 255, and 128. If we divide the red channel, 16, by itsmaximum value, 255, we get 0.0625 for red. Green is obvi-ously zero, and blue is 1, and alpha is 0.5. So GGLL__SSRRCC__CCOOLLOORRwould give (0.0625, 0, 1, 0.5) for our pixel. What a boringfunction, huh? All it does is translate our pixel’s values intoa 0 to 1 range. The color hasn’t changed. Just you wait; itgets trickier.

GGLL__OONNEE__MMIINNUUSS__SSRRCC__CCOOLLOORR ((11,, 11,, 11,, 11 )) --

((RRss // kkRR ,, GGss // kkGG ,, BBss // kkBB ,, AAss // kkAA))

This one’s a little more interesting. It inverts the pixel,including the alpha channel. You can see that the secondcomponent is the same as GGLL__SSRRCC__CCOOLLOORR, so we have the RGBAin a 0 to 1 range, and then we subtract each value from 1.For example, our blue pixel’s RGBA of 16, 0, 255, 128 getsconverted to (0.0625, 0, 1, 0.5) as before. Then we subtracteach part from 1 to get an inverted color: 1 - 0.0625 = 0.9375for red, 1 - 0 = 1 for green, 1 - 1 = 0 for blue, and 1 - 0.5 = 0.5for alpha. The result is (0.9375, 1, 0, 0.5), which is a lovelyshade of yellow.

In this example, the alpha channel didn’t happen tochange, but normally we would find that opaque objectsbecome transparent as well as opposite colors. This is weirdfrom an artist’s point of view; when we think “invert,” we’reusually thinking of color, not visibility. Again, I say this isan argument for artist involvement in low-level architecturedesign.

GGLL__DDSSTT__CCOOLLOORR ((RRdd // kkRR ,, GGdd // kkGG ,, BBdd // kkBB ,, AAdd // kkAA))

GGLL__OONNEE__MMIINNUUSS__DDSSTT__CCOOLLOORR ((11,, 11,, 11,, 11 )) --

((RRdd // kkRR ,, GGdd // kkGG ,, BBdd // kkBB ,, AAdd // kkAA ))

These two functions, GGLL__DDSSTT__CCOOLLOORR aanndd GGLL__OONNEE__MMIINNUUSS__DDSSTT__CCOOLLOORRare the same as above, but for the destination pixel. Does itseem strange to distinguish source and destination so care-fully? You might wonder, “Why not just haveGGLL__OONNEE__MMIINNUUSS__CCOOLLOORR and forget about separating source and des-tination?” The answer is that we have more control if we canidentify which pixel gets inverted.

GGLL__SSRRCC__AALLPPHHAA ((AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ))

This function turns the alpha channel into a grayscalebitmap by copying the scaled alpha channel ((AAss // kkAA)) intoRGB.

GGLL__OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA ((11,, 11,, 11,, 11 )) --

((AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA))

GGLL__DDSSTT__AALLPPHHAA ((AAdd // kkAA ,, AAdd // kkAA ,, AAdd // kkAA ,, AAdd // kkAA))

GGLL__OONNEE__MMIINNUUSS__DDSSTT__AALLPPHHAA ((11,, 11,, 11,, 11 )) --

((AAdd // kkAA ,, AAdd // kkAA ,, AAdd // kkAA ,, AAdd // kkAA))

These three give us the variations on GGLL__SSRRCC__AALLPPHHAA, aninverted version, and the destination-alpha equivalents.

GGLL__SSRRCC__AALLPPHHAA__SSAATTUURRAATTEE ((ii,, ii,, ii,, 11 ))

ii == mmiinn ((AAss ,, kkAA -- AAdd )) // kkAA

Now this is the tricky one. Remember that it isn’t avail-able as a destination blend; it’s only possible for the sourcepixel. This function overwrites alpha to solid opaque, thenputs ii, which is some funky formula that seems to use alphavalues, in RGB.

O.K., let’s start deep inside ii:: kkAA -- AAdd is the maximumalpha minus the destination alpha, which is essentiallyinverting the destination alpha. The function mmiinn(()) returnsthe smaller of its two inputs. One input is the inverted desti-nation alpha, and the other is source alpha. The final divi-sion scales that to 0 to 1. So we’re getting the smaller of thesource or inverted destination, scaled 0 to 1.

We conclude that SSRRCC__AALLPPHHAA__SSAATTUURRAATTEE is used to convert analpha channel to a grayscale, using the brightest alpha avail-able, but we still don’t know what the heck it’s for. We’llneed more context to determine that.

I’ll spare you the accuracy issues that the specificationdescribes next. Instead, we arrive at a far more interestingsection: Examples.

Examples

N ow we get to apply some of this hard-earned knowl-edge. Under the Specification’s Examples section, we

find this little passage:

Transparency is best implemented using blend function(GGLL__SSRRCC__AALLPPHHAA,, GGLL__OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA) with primitives sortedfrom farthest to nearest. Note that this transparency cal-culation does not require the presence of alpha bitplanesin the frame buffer.

Recall the Sacred Blend formula we saw in the beginningof the article:

oouuttppuutt__ppiixxeell == ssoouurrccee ** ssffaaccttoorr ++ ddeessttiinnaattiioonn ** ddffaaccttoorr

This means that the specification is recommending thatwe do transparency blending like this:

oouuttppuutt__ppiixxeell == ssoouurrccee ** SSRRCC__AALLPPHHAA ++ ddeessttiinnaattiioonn ** OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA

Let’s use our familiar example of a blue pixel with RGBAchannels are 16, 0, 255, and 128, and let’s blend it onto agray background (RGBA 128, 128, 128, 255). So we know thesource and destination, but what about the factors? We fig-ure them out, just as we did earlier in this column. We sawthat SSRRCC__AALLPPHHAA is calculated by the formula

SSRRCC__AALLPPHHAA == ((AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ))

Plugging in our blue pixel’s alpha value for AAss and using



18

the maximum possible alpha value for kkAA, we get:

SSRRCC__AALLPPHHAA == ((112288//225555,, 112288//225555,, 112288//225555,, 112288//225555))

Dividing out the result gives us a reassuringly understand-able answer: 50 percent for everything.

SSRRCC__AALLPPHHAA == ((00..55,, 00..55,, 00..55,, 00..55))

We’ve got one factor done, so let’s do the second one.

OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA == ((11,, 11,, 11,, 11 )) --

((AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA ,, AAss // kkAA))

Recall that this is simply SSRRCC__AALLPPHHAA subtracted from 1. We’vealready figured out that SSRRCC__AALLPPHHAA is 0.5, so we see that 1 - 0.5= 0.5. In other words, OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA happens to be thesame as SSRRCC__AALLPPHHAA:

OONNEE__MMIINNUUSS__SSRRCC__AALLPPHHAA == ((00..55,, 00..55,, 00..55,, 00..55))

Now we have all the players in the Sacred Formula. Withthese values, we’re ready to hit the calculator.

oouuttppuutt__ppiixxeell == ((1166,, 00,, 225555,, 112288)) ** ((00..55,, 00..55,, 00..55,, 00..55)) ++

((112288,, 112288,, 112288,, 112288)) ** ((00..55,, 00..55,, 00..55,, 00..55))

oouuttppuutt__ppiixxeell == ((88,, 00,, 112288,, 6644)) ++ ((6644,, 6644,, 6644,, 6644))

oouuttppuutt__ppiixxeell == ((7722,, 6644,, 119922,, 112288))

Testing the Results.

W ow, we got an answer! Now we get to the hard ques-tion: is it a meaningful answer? How would we know

if we screwed some of that math up? This stage is critical tocementing our knowledge of the process. Our answer is justa random number unless we believe in it. So how do we testit? Here are two ways.

First, we reality-check with an artist’s eye. In general, whatwould you expect blue blended on a gray background tolook like? I would expect it to be gray-blue, at about thesame brightness, but less saturation, compared to the origi-nal blue color. After we make our prediction, we compare itto our calculated result by opening a paint program andactually creating an image filled with the calculated RGBvalue. Yes, the color is reasonably similar to our prediction.

Second , we’ll perform the actual blend process in a paintprogram. To do this, we create a new image filled with ouroriginal blue color, then paste it over a second gray imagewith 50 percent transparency (seeFigure 2).

We observe the result by using thecolor eyedropper tool and looking atthe resulting RGB values. When I didthis, I got RGB of (28 percent, 25 per-cent, 75 percent). If we normalize ourcalculated RGB pixel, we get Red: 72/255 = 0.282Green: 64/255 = 0.25Blue: 192/255 = 0.75Alpha: 128/255 = 0.50

That means our RGB values would be (28 percent, 25 per-cent, and 75 percent). Once again, we’ve double-checked ourcalculation and found that we’re on target.

Obviously, you don’t need to hand-check every pixel youblend, but if you truly understand what you’re doing, youwould be able to check any point, work through the math,and predict the results.

All this double-checking is very important when you startexperimenting with more complicated blending than a sim-ple 50 percent blend. Unless you understand and predictyour results from blending, you’re just guessing, and youwon’t be able to control your medium.

Getting Creative

N ow that you have all the basic tools to play with blend-ing, you’re ready to mess with innovative combina-

tions. Here’s how to do it. Plug various factors such asGGLL__SSRRCC__AALLPPHHAA into the Sacred Formula and figure out what theresults would be. Here is an additional example, taken froma recent project I worked on:

ggllBBlleennddFFuunncc((GGLL__ZZEERROO,, GGLL__SSRRCC__AALLPPHHAA));; //// MMoonnoocchhrroommee lliigghhttmmaappss

That formula gives us this:

oouuttppuutt__ppiixxeell == ((ssoouurrccee ** 00 ++ ddeessttiinnaattiioonn ** SSRRCC__AALLPPHHAA))

oouuttppuutt__ppiixxeell == ddeessttiinnaattiioonn ** SSRRCC__AALLPPHHAA

This simply darkens the destination pixel by the alphachannel of the source. The RGB values in the source areignored. Sounds useless, but it could allow you to hide alightmap inside a texture that doesn’t need its alpha. Youcould ignore the alpha and apply it as a normal texture,then blend its alpha as a lightmap on a different surface.

Granted, it’s not easy to figure out a really cool new appli-cation, but if you do, it should be fairly simple to implementbecause you’re using existing systems.

Now I know you’re not going to be satisfied until weaddress that strange factor SSRRCC__AALLPPHHAA__SSAATTUURRAATTEE. What’s it for?Anti-aliasing, apparently. Here’s what the OpenGL 1.2 speci-fication says about it:

Polygon antialiasing is optimized using blend function((GGLL__SSRRCC__AALLPPHHAA__SSAATTUURRAATTEE,, GGLL__OONNEE)) with polygons sorted fromnearest to farthest.. Destination alpha bitplanes, whichmust be present for this blend function to operate cor-


20


F I G U R E 2 . Double-checking a simple texture blend.

21

rectly, store the accumulated coverage.

What’s All This For?

A s you sneak back out of the belly of the beast with theknowledge safely stowed in your head and huddle in

your nice artistic hobbit-holes, you may find yourself won-dering, Why the heck did I bother? What can I do with thisnewfound knowledge?

For me, the most important reason to grasp this stuff is soI truly understand how my medium, real-time 3D, works. Byknowing what’s going on at a low level, I gain intuition andinsight into once-mysterious problems and occurrences thatI encounter. It makes my troubleshooting guesswork muchmore accurate.

Second, it’s a power thing. I find the thought of creatingmy own blend modes very inspirational, and get a littlewound up when I realize that I could suggest some newblend mode to my programmer, and thus actually advancethe artistic front into that foreign ground of technicalities alittle farther . PREDICTING OVERFLOW. Last month, we discussed the problem ofRGB limits or overflow. Pixels have a maximum brightness(100 percent) and a minimum brightness (0 percent). If weattempt to assign a value higher than the maximum, it’struncated to the maximum. This is designed into theOpenGL blending functions, as the specification states, “Allscale factors have range [0,1].”

We concluded that when our pixels overflow, we losedata. There’s nothing wrong with that. As long as we under-stand why it’s happening, we shouldn’t feel reluctant tohave blend overflow, but few artists are aware of it.

Overflow isn’t just a problem for additive (and its corol-lary, underflow for subtractive) blending. It can happen dur-ing the math for any of the blend modes. In fact, it’s a moresubtle problem for other modes because calculating theoverflow isn’t as simple as simply adding RGB values.

To understand and predict overflow with more complicat-ed blending modes, we follow the same process: pick a singlepixel, run the calculations (we added the RGB values in ourexample last month), and see if the resulting RGB values arewithin the 0 to 100 percent range. Of course, to do that,we’ll need to know what the math is behind these blendmodes. This column gave you artists the tools to actually dothat yourself. ■


SGI's OpenGL WWW Centerhttp://www.sgi.com/Technology/OpenGL/

The OpenGL 1.2 Specificationftp://sgigate.sgi.com/pub/opengl/doc/opengl1.2

/opengl1.2.pdf

The OpenGL Sitehttp://www.opengl.org


and platform issues really came to thefore. Part of this transitional period wasfueled by the decline of the 16-bit con-soles, the inability of 3DO and otherconsole wanna-bes to make an impacton the market, and the uncertainty sur-rounding Sony’s and Sega’s next-gener-ation platforms. During the same peri-od, the industry was witnessingheightened consumer interest in thehome PC, fueled in part by the promiseof multimedia. Today, Nintendo andSony tower over the console industry tosuch a degree that support for eitherplatform is more of a business decision,often dictated by the developer’s andpublisher’s relationships with eithergiant. The home PC market has flour-ished to the point that its high-end seg-ment, the hardcore games enthusiast, isnearly the sole motivator of power sys-tems purchases. The game developmentcommunity is now in the driving seat,and platform issues tend to be moretechnical and resource-bound thananything to do with the fear of support-ing a target machine that may not havean audience somewhere down the line

The platform has stabilized conceptu-ally, although the vicissitudes of the PChardware market still make for interest-ing research. Do I support 3D accelerat-ed-only products? Do I go for MMX?Some might think that’s about all thereis to ask about the state of the enter-tainment platform.

Not exactly. The economics of theconsole and PC markets are worldsapart, and as a result of continuedgrowth in both businesses, game devel-opers are likely to face even moreaggressive courting by the hardwareand publishing powers-that-be.

Everyone wants content, and while thebest content makes its mark across anumber of platforms, the pressure toput all your eggs in one basket is goingto increase as platform vendors jockeyfor position by paying for exclusivity insome form or another (Figure 1).

This jockeying for position is goingto take place at a macro level betweenthe likes of Nintendo, Sony, Sega, anderstwhile allies and competitors Inteland Microsoft. Throw into the mix thedesire of companies such as NEC and3Dfx to create a 3D graphics standard,

and you’re pretty much up to your eye-balls in conflicting sentiments as towhat constitutes a platform. Is DirectXa platform, or 3Dfx, or Sega’s upcomingDreamcast, which is based on WindowsCE?

To make matters worse, the numbersfor platform markets match up fairlywell — in other words, you aren’tgoing to worry so much about havingan installed base of users to target withso few participants. Furthermore, it’sworth noting that a PC games enthusi-ast is also likely to be a console owner,

Trends in the

Entertainment Platform Market

T here was a time when game developers would agonize over how much of

their precious time should go into supporting the Macintosh or the PC,

and over deciding among Sega, Nintendo, and Atari. During the period

between 1992 and the end of 1994, the game market was in transition,

b y O m i d R a h m a tH A R D T A R G E T S


22

Omid Rahmat works for Doodah Marketing as a copywriter, consultant, tea boy, andsole employee. He also writes regularly on the computer graphics and entertainmentmarkets for online and print publications. Contact him at [email protected].

1997 1998 1999 2000

50,000

40,000

30,000

20,000

10,000

0

PC Households

Online PC Households

Console & Gaming Devices

PC Gaming Households

Online PC Gaming Households

Source: IDC Research

F I G U R E 1 . The state of the entertainment platform.

while many general PC households,which tend to be homes with children,will also own alternative platformsbecause families tend to demarcatebetween the den PC and the televisionin the kid’s room or the living room.Unfortunately, most of the marketresearch on computing and game plat-forms tends to look at absolutes in buy-ing and usage patterns, approaching theproblem from a hardware point of view.Microsoft, Intel, Sony, and Nintendo areconcerned with singular domination ofthe entertainment platform, althoughthe reality is more abstract. Research onhow platforms coexist is sketchy at best.

The reason that it’s difficult to pin-point or define the entertainment plat-form in some meaningful way based onthe features of hardware or the supportfor a particular vendor is due to theway consumers perceive entertain-ment. Most of us experience entertain-ment, whether it’s interactive or pas-sive. We are motivated by theexperiences and emotions that contentcreates, and aren’t swayed by thepromise of a platform’s capabilities.There’s a simpler way of looking at theentertainment platform, and one thatwill increasingly come to resonate withvendors of consumer goods: developersneed to look at where and how peoplespend their money on content.

Segmenting the Platform

T he segmentation of the entertain-ment platform is an issue that most

platform vendors are loathe to dealwith, preferring to concentrate on howtheir own platform can dominate a par-ticular market. But as the stakes ininteractive entertainment increase, sodoes the interest of vendors with theclout and resources to define the mar-ket. We can point to Sony’s entry intothe console business with PlayStation asa good example of this. The followingplatforms probably constitute the maintargets for the games industry today:NINTENDO. It’s a mixed bag for Nintendo.N64 gets all the press, but the SuperNES is still out there generating rev-enues, and the Game Boy is about theonly significant hand-held product onthe market, taking in $125 million insoftware sales alone in 1997 (Source:NPD). The N64 is being outsold by thePlayStation at a ratio of two-to-one in

the first half of 1998 due to the N64’slack of titles and more competitivepricing by Sony. Nintendo’s relianceon the more expensive cartridge stor-age device keeps its prices high, butdevelopers for N64, of which there areonly a select few outside of Nintendo’shome-grown talent, reap extraordinaryreturns every time they release a titledue to the pent-up demand.SONY. PlayStation has the platformsales, internal and external title sup-port, and the pricing. It doesn’t have aMARIO counterpart, and the quality ofits titles is weighed down by their sheernumber. It’s also less expensive to be aplayer in the PlayStation market. Sonyis probably the only real cross-platformcompany in the business, having apresence in the set-top arena withWebTV, a console, and the Vaio PCbusiness, not to mention a host of digi-tal television and consumer electronicsproducts. And if that wasn’t enough,the company also owns a Hollywood

studio and is the brand to beat in theplatform business.SEGA. Sega still makes the best arcadesystems around, and the Saturn has alife of its own — just not much of onein North America. In the pipeline isDreamcast, the Windows CE-basednext-generation console. With amodem connection for the Saturn, andthe collaboration of Microsoft, Segahopes to put the game console into amore legitimate multimedia entertain-ment platform category — one of itsown making — and in anticipation ofpotential rivals in the digital televisionset-top box category.WINDOWS. Developers wrestle with thefiner points of Windows technologies,which never quite live up to expecta-tions. But a high-end PC, with all the3D trimmings, is about as good a gameexperience as you’re going to get. Still,the PC games industry suffers from ahighly fragmented distribution struc-ture. The complex value chain stalls at


23

1997 1998 1999 2000

$200

$190

$180

$170

$160

$150

$140

$130

$120

$110

$100

$90

$80

$70

$50

$40

$30

$20

$10

$0

TV Consumer Online

General Interest & Educational Software

Video Games

Movies

Pe

r p

ers

on

sp

en

din

g p

er

ye

ar

on

en

tert

ain

me

nt

Source:

Veronis, Suhler

and Associates

F I G U R E 2 . Per person spending per year on entertainment. These figures

relate to activities. Video games refers to electronic gaming in general, but

not arcade. Consumer online refers to home Internet activity.

the store-client interface every time apiece of software or hardware crashesthe precious family Quicken machine,and there are no profits but for a veryselect few vendors. To further add tothe confusion, 3D graphics vendorssuch as 3Dfx are trying to carve outtheir own subplatform category,adding to the already bewildering arrayof configurations in the market.Fortunately for 3Dfx, game developershave embraced the company’sapproach, probably out of frustrationat always having to target the lowestcommon denominator in this market.PC games enthusiasts have plenty ofmoney to spend on power systems (orso it seems), and they like the bleedingedge. All this favors the hardcore gamementality of the industry, and fuelsintense technical rivalries betweengame engine developers. Some mightsay that today’s entertainment PC isthe platform that Carmack built.

Despite the existence of these plat-forms, the entertainment platform forgames is only a small part of a muchbigger picture. Television, the movies,the VCR, recorded music, and evenprint are all, in their own ways, com-peting entertainment platforms (seeFigure 2).

Consumer spending on entertain-ment isn’t dramatically growing on ayear-to-year basis. It isn’t a double-digitgrowth market. In fact, it varies andgenerally keeps up with inflation, orstays just ahead of it, depending on howconfident the mood of society is, or howmuch of a need there may be forescapism. People react emotionally tocontent, and the measure of their reac-tion is how they spend the finite pool ofcash that’s available for their leisure.

Counting the Pieces of the Pie

A s the game market continues tomature, and as the technologies

that created the industry find their wayinto the mainstream, the entertain-ment platform is going to become sosegmented that only highly specializedcontent will focus on only one seg-ment of the market. The entertainmentplatform is a heterogeneous environ-ment of PCs, consoles, and possiblyset-top boxes, not to mention hand-held gaming devices. The good news isthat games, despite having a smaller

overall audience than movies, forexample, get a significant per capitaspend. Compared to general softwaresales, games software has a significantpresence in the industry.

The real threat to the platforms thatgames support, at least traditionalgames as we understand them today, isfrom consumer online activity.Consumer online activity is, in its ownway, interactive entertainment.Granted, most online usage by con-sumers is devoted to e-mail, news, andinformation searches, but one can alsoargue that online entertainment is stilla virgin environment, waiting to findits own style and approach. Most of theexisting approaches to online enter-tainment have involved environmentsthat are more comparable to televisionthan computer games. YOU DON’TKNOW JACK is a classic example of apopular game that has successfullybridged the gap between populist gameshow themes from television and themore highly charged interactive envi-ronment of computer games. Does itsucceed because of its obvious debt totelevision? Perhaps, but it does showhow a smart developer can leveragecontent within the heterogeneoushome environment.

Developers are only just beginningto realize the clout they possess. As aresult, they may also be starting to getan idea of how interactive entertain-ment, and games in particular, fit intothe big picture. Console players oftengrow up into PC games players. Onlineactivity is on the up, and its entertain-ment potential remains largelyuntapped. Also looming on the hori-zon is the enigmatic Project X from VMLabs. Project X aims to put a powerfulmedia processor, one capable of sup-porting cutting-edge 3D games, intoconsumer DVD players. If a solutionlike Project X can successfully pene-trate the same market as VCRs and TVs,then counting seats is probably the lastthing any developer needs to do. If youare a games enthusiast, and most devel-opers tend to be games players as well,you'll know a good gaming machinewhen you see one. The trick is going tobe in courting people's entertainmentdollars — and not just the enthusiasts,but anyone who might be interested ingames. Games in all their glory, anddiversity. It's a big challenge for theindustry. A very big challenge. ■


Illustration by Robert Zammarchi



27

Mel Guymon just finished work as art director on Zombie's SPEC OPS (Panasonic).With several years experience as an

animator, Mel's background includes work at Eidos, BioVision, and MSH Entertainment. Mel is currently working at

Surreal Software, where he is the art lead on DRAKKAN (Psygnosis).

luid, realistic character animation is becoming

the benchmark for today’s real-time games.

Games such as TOMB RAIDER, SOUL BLADE, and

VIRTUA FIGHTER 3 have raised the bar when it

comes to character motion.FFB Y M E L G U Y M O N

As a result, today’s game players are moresavvy and expect better and more realisticeffects. Fortunately, the tools for attaining

this realism are becoming more capable,sometimes on a monthly basis. As thesoftware gets better and better, the barwill continue to rise, and it’s up to usanimators to meet, if not exceed, theconsumers’ expectations.Accurately deciding which animation

tool to use early on can mean the differ-ence between getting your product out byits ship date and finding yourself hittingthe bricks as your team suddenly losesfunding after missing it’s fifth milestone in a row. With personal experience in both

these categories, I can readily attest to thefact that the human element must beincluded when making this decision. If your game has characters — humanoid orotherwise — then it needs character anima-tors (a touchy breed to be sure), who, aside from needing the odd bit of foodtossed into their cubicles from time totime, require little maintenance if they’ve got a good pieceof software withwhich to animate.

Three premiere character animation

tool vendors are releasing major productupgrades this summer. These products are Softimage’s Softimage|3D 3.8,Alias|Wavefront’s Maya for Windows NT,and Kinetix’s 3D Studio MAX 2.0 withCharacter Studio 2.0. Clearly, there areother tools that have just as devoted followings as these, such as Lightwave,Electric Image, and Nichimen, but due to the fact that covering all of them would consume most of a magazine’s pages, this article focuses solely on thesethree new releases, in the context of theirreal-time 3D character animation facilities.

Each of the tools in this article was evaluated on basic functionality in the following categories:

Inverse Kinemation (IK)Constraint-Based AnimationClassical Hand-AnimationMotion Curve EditingInterface/Ease of UseWhile this is by no means an all-

encompassing list, I hope it gives youenough basic information to help towardsmaking an informed decision on which tool to use. See “Terms and Definitions” for detailed descriptions of these categories.

Kinetix 3D Studio MAX 2.0 withCharacter Studio 2.0

Used as the weapon of choice in thedevelopment of some of the indus-

try’s top games (such as TOMB RAIDER II,BLADE RUNNER, and DIABLO II), CharacterStudio is easily finding its niche withinthe games industry. It’s the secondWindows NT release of the company’scharacter animation system, which sup-ports motion capture, editing, andblending capabilities, plus traditionalkeyframe animation capabilities. Thenew version also has new skin deforma-tion tools and Character Studio’s foot-step-driven technique. The tool has theability to import motion capture files,and it comes with 150 motion capturefiles that you can edit and personalize.

Boasting over 100,000 users world-wide, MAX itself is one of the least

expensive and most widespread anima-tion tools used in the industry today. Itmay be surprising then to find out thatit’s also one of the most functionaltools available and, with the additionof the new version of Character Studio2.0, offers just as much basic function-ality as it’s more prestigious (andexpensive) cousins.

I queried various user groups on allthree platforms, and the feedback I goton Character Studio (CS) was that, whilethe interface left a lot to be desired,hand and IK animation using Biped wasexcellent. After trying out the new ver-sion of the product, I tend to agree. Ithink, however that the interface woesstem more from the button frenzyinherent to MAX, and less from anyproblems with the CS interface. MOTION FLOW MODE. Figure 1 shows thenew Motion Flow mode for CS2. I’vebeen waiting a long time for a tool

such as this, and it looks like CS2 hasfinally come through. In Motion Flowmode, .BIP files are combined usingvelocity-interpolated transitions to cre-ate longer character animation. First,you add clips and reference them to.BIP files in the Motion Flow Graphdialog. You can then select these clipsto create a script in the Motion FlowScript rollout, and use the TransitionEditor to adjust transitions between.BIP files. Reminiscent of PowerAnimator’s Metacycle function,Motion Flow provides a truly user-friendly interface for splicing togetherdifferent animations. The two windowsin the lower left-hand portion of thescreen let you load in individualsequences and overlap the transitionsbetween them with variable parame-ters. In the scene in Figure 1, the Bipedcharacter is transitioning from a spin-kick animation to a dance-step anima-


28

C H A R A C T E R A N I M A T I O N

CLASSIC HAND ANIMATION. While

IK- and constraint-

based sys-

tems offer

solutions to

most ani-

mation,

taking the

classic

approach

and animating individual

bones by hand can sometimes

give superior results. What

separates a good animator

from the rest of his or her

peers is the ability to combine

classical and IK animation to

generate nonrobotic motion.

Tweaking the motion by hand

is a tedious and time-consum-

ing process, and while a

smooth interface can easily

double an animator’s output, a

bad one can freeze the process

in it’s tracks. The ability to

easily manipulate bones and

set keyframes by hand, then,

is crucial in any good animat-

ing software.

MOTION-CURVE EDITING. Both

classical and

constraint-

based IK

animation

ultimately

generate

keyframes that

define the properties of an

object over time. Motion

curves can be generated for

everything from rotation,

translation, and scaling to

color, surface tension, and u,v

coordinates. With a good

curve editor, an experienced

animator can set keyframes on

the first pass and finish tweak-

ing the animation entirely by

hand using the resulting

motion curves. When using

motion capture, animators

work almost exclusively within

the curve editors; it’s safe to

say the your ability to use

motion capture is linked

directly to the functionality of

your curve editor. The bottom

line is that a good curve editor

is critical when it comes to

providing animators with a

smoothly flowing interface.

INVERSE KINEMATICS (IK).Probably the most

important tool

available to ani-

mators today, IK

is a skeletal-

based system

that solves for

joint motion automat-

ically. For instance, if

you want to animate a charac-

ter’s hand to swing a sword,

you simply drag the characters

hand to the position you want,

and the IK system will solve

the joint motion of the fore-

arm, bicep, and shoulder

bones automatically. It’s actu-

ally as simple as it sounds,

and with a little preparation

setting up your skeletons, you

can get remarkably smooth

motion on the first pass. Even

so, raw IK data is always dis-

cernable from motion capture

simply due to the smooth

nature of the transitions the

software generates; many of

the subtleties of natural

motion are lost. However, IK

can get most of the work done

for you, allowing the animator

to spend his time tweaking the

motion to get a realistic, life-

like result.

CONSTRAINT-BASED ANIMATION.Constraints

are inherent

to both clas-

sical and IK-

based ani-

mation. All

of us anima-

tors can

remember

the first walk cycle we ever

generated, and how frustrat-

ing it was to try to keep the

character’s feet from sliding

on the floor. Constraints

largely remove these

headaches; they can be used

to limit the rotation of a joint

(that is, prevent the elbow

joint of a human character

from bending backwards), or

to glue a characters feet to the

floor (preventing the “moon

walking” effect). Directional

constraints can be applied to

keep a character’s head point-

ing forward during a complex

attack sequence, or simply to

keep the character’s feet

pointing forward during a

walking loop. Coupled with a

good IK system, constraints

are probably the second most

important tool used by anima-

tors today.

Terms and Definitions

tion. The great thing about this is thatyou get a visual representation of thetransition. As the time slider nears thetransition point, a red stick figureappears, going through the motions forthe animation to which the characteris transitioning. By interactively edit-ing the parameters for the transition,you can easily tweak the overlap toachieve a smooth result.

INVERSE KINEMATICS. Overall,MAX 2.0 has a solid IK system.I’ve always been a little put offby the joint-dialog interface —all that sliding up and down

with the mouse gets old really quickly.But the ability to toggle IK off and onwith a button is definitely a plus.

Add in CS2’s functionality and it’s awhole new ball game. CS2’s biped fea-ture provides an extremely easy way toset up a perfectly functional IK skele-ton, with rotational constraints andexpressions, giving a realistic form andbalance to the skeleton. This meansthat if you raise a the skeleton’s arm onone side, CS2 automatically shifts theweight of the other side of the body,allowing it to assume a natural pose. Asa result, your skeleton’s setup is prettymuch done already, and it’s physicallyaccurate to boot. Although unfamiliarwith the product at first, I had no trou-ble getting the hang of merging thefootstep-based biped skeleton with alittle hand-generated IK. Most of the

tweaking that I usually have to do toget the correct form and balance wasdone automatically.

CONSTRAINTS. There are goodand bad things to report onthis score. Again, the interfaceis clunky and prohibitive, and

you are limited to only two types ofconstraints: orientation and positional.By definition, Biped’s footsteps act ascombination positional and orientationconstraints, allowing you the freedomto choreograph the rest of the charac-ter’s motion without worrying toomuch about foot position or balance.

One nice facet of the program is theability to combine constraint-based IKanimation with the inherent dynamicsfunctionality in MAX. For instance, sayyou’re creating a death sequence foryour character, and you want her tocrumple to the ground like a mari-onette whose strings have just beencut. You simply apply motion dynam-ics to positional constraints set up onthe characters hands, hips, and head,and your character drops like a ragdoll. You can even set it up so that thehands and head bounce off the grounda few times, which is excellent.

CLASSICAL HAND-ANIMATION. Thissection deals largely with theinterface. If it’s easy to move,rotate, and scale an object, it

should be easy to animate using thesesame basic techniques. With MAX, Ifound this to be the case, generally.Swapping between the various view-points was quick and painless, which iskey when you’re animating by hand.Note that MAX is set up to run off themouse. It takes a little setting up, butwith the help of MAX’s keyboardshortcuts, I was able to set up a decentenvironment that made settingkeyframes by hand pretty seamless.

MOTION CURVE EDITING. MAX’sTrack View Editor providesfunctionality comparable to

the Dopesheet in Softimage|3D and theAction Windows in PowerAnimator.You can easily toggle between display-ing curves for single and multipleobjects, or simply display all animatedobjects in the scene. Changing theslope and inflection along a curve or ata keyframe is a single mouse-click away,and applying transformations such asscale and translation to entire sets ofkeyframes is straightforward. WithMAX, you can control object rotations


30


F I G U R E 1 . Character Studio 2.0’s Motion Flow mode.

KinetixSan Francisco, Calif.(415) 547-2000http://www.ktx.com

Recommend Hardware: Intel Pentium w/128MB RAMTested On: Intergraph TDZ 2000Software Price as tested: $4,000Pros: Humanoid animation with Character Studio 2.0 is a snap.Cons: The quirky, icon-intensive interface can be really annoying. No three-button

mouse support.Comments: Full functionality has finally been achieved in CS2, thanks to a combination

of good, basic animation tools, the added bonus of a physically correct skeleton, andlots of little touches specifically tailored for character animators.

3D Studio MAX 2.0 with Character Studio 2.0

with several different controller types,which generally change the behavior ofan object between keyframes and dur-ing transition states. I was thoroughlyconfused by this feature and ended upsetting my defaults to Euler rotation atevery step.

One thing MAX supplies that Ihaven’t seen in other tools is the abili-ty to interactively modify the functioncurves as the animation is playingback. I was able to make slight modifi-cations to the position and slope ofseveral keys while the animation waslooping in real-time. No more startingand stopping to view the resultantmodifications.

Alas, here again I found a good, solidtool that’s been cluttered with a lot of“neat” extras that aren’t necessarily veryuseful. As you can see in Figure 2, thereare some thirty or so buttons just hav-ing to do with the Track View mode,and there are different keyboard short-cuts for when the mouse is in the TrackView window and when it’s out of it.

Overall though, it appears as thoughKinetix’s intent was to avoid limitingthe animator choices of functionality;and I think it achieved that. I couldn’tcome up with any single importantfunction that was missing from theequation, and after awhile I got used tomost of the interface hang-ups thatwere bothering me.

INTERFACE/EASE OF USE. This ismostly a judgment call thathas to be made by individual

animators. When 3D Studio MAX firstcame out, it was vastly different fromits ancestor, 3D Studio. The folks atKinetix decided to fill up the whitespace in the interface with icons andbuttons, which, in my view, severelyclutter the working area. This is mybiggest bone to pick with Kinetix. Byabandoning the modular format of 3DStudio (which, like Softimage, had sep-

arate modulesfor modeling,animation,and texturing),it tried to fiteverythinginto one inter-face. It’s inter-esting toobserve thatwhile MAXhas aban-doned the

modular format to allow every featureto be animated, both Softimage andAlias|Wavefront are migrating toward amore modular format, providing acleaner, less cluttered workspace.

Another complaint I have with MAXis the lack of three-button mouse sup-port. In my mind, the mark of a trulygood interface is that you can keepyour hands largely in the same spotson the keyboard and mouse without alot of dancing around. The interfaceshould disappear. Of all three plat-forms, I found myself hunting andpecking over the keyboard the mostwith MAX, while the combination ofmarking menus and hot keys inSoftimage|3D and Maya allowed me tobasically become one with themachine. At some point, Kinetix willrealize that if you’re going to force the

user to rely so heavily on the mouse forinput, the logical step is to support athree-button mouse.

Overall, MAX is useful. While curveediting was surprisingly fluid despitethe button frenzy, I still found theinterface to be overly cluttered.

Softimage|3D 3.8

A lthough it’s probably used morewidely in the film industry than

by game developers, Softimage has gar-nered a dedicated following in thegames industry. Psygnosis, LucasArts,and Squaresoft are among the manydevelopers who have helped Softimageentrench itself in the gaming world.

Softimage’s leadership in the field ofcharacter animation is widely recog-nized in the gaming industry. For thepast several years, the mantra of thegame developer has been, “Model inAlias, animate in Soft.” An ever-increasing number of users are stayingloyal to Softimage over time due to it’ssuite of solid animation and modelingtools, which fill a niche greatly neededin the gaming industry.

Of all the animation products on themarket, Softimage|3D was the newestto me. However, it’s fast becoming myweapon of choice for character anima-


32


F I G U R E 3 . Softimage|3D’s Dopesheet and Animation Sequencer.

F I G U R E 2 . Track View Editor in MAX.

tion (narrowly winning overPowerAnimator). The best part aboutanimating in Softimage|3D is probablythe most intangible. The interface sim-ply feels right. ANIMATION SEQUENCER. One of the newfeatures in version 3.8 is a high-levelinterface for character animation(Figure 3). It allows users to work withgroups of animations called “Actions,”which can be managed independently.You can define groups of Actions forany character in a scene, then sequencethem together on a timeline, whichmakes managing complex characteranimation much easier. Similar infunction to CS2’s Motion Flow mode,the Animation Sequence offers feweroptions with respect to transition andoverlap. In fact, at present, each Actiongoes in to the Sequencer in a very lin-ear fashion, without any overlapallowed. But without a lot of extra fea-tures, the interface stays clean, allow-ing the work area to remain clear whileretaining the necessary functionality.

In addition to the Sequencer, audiotrack support is now available in theDopesheet. Similar to the Audio Trackfunction available in 3D Studio MAX,the tool displays a waveform for theaudio information, which can then besynched up with character animationto provide correct verbal cues in asequence.

INVERSE KINEMATICS. Soft-image|3D’s character anima-tion suite is built around afundamental IK system that isas good as any on the market.

Although the solution solver is not asversatile as Maya’s, here again, it’s sim-plicity is it’s strength. Two basic flavorsare available, the 2D and 3D chains.Skeletons can be composed of one orboth types, the main difference beingthat where 3D chains provide IK solu-

tions based on any axis of orientation,2D chains provide solutions generatedin a single plane of rotation. Becausemuch of the work in IK is training yourIK solver to keep only those solutionsthat look natural, limiting the numberof solutions can help you arrive theresooner. And, because the plane of rota-tion for the 2D chain is itself animat-able, it retains all of it’s functionality.

CONSTRAINTS. In conjunctionwith Softimage|3D’s IK toolset,users can select from myriadconstraints. Besides the normal

position, direction, and orientationconstraints, users can also constrainbones to clusters or single points on amesh object. For instance, say you wantto animate a dragon, and you want hisshoulders and pelvis to remain rigid. By

creating the shoulder and pelvic jointsout of polygonal objects and constrain-ing the bones in the legs to points onthese objects, you can get an amazingeffect. The result is a naturally pivotingpelvic joint that mimics they way thejoint works in nature.

You can even assign multiple con-straints of a given type to a singleobject. Say you want the hips of yourbipedal character to always remainequidistant between its two feet.Previously, you would have had tocome up with an expression/equationthat defined the relationship betweenthe hips and the feet. Now you justassign each foot as a constraint to thehips, and the IK system automaticallykeeps the hips positioned between thefeet. As with most features inSoftimage|3D, the constraint systemmaintains the user-friendly tradition.

CLASSIC HAND-ANIMATION. It’s nolie to say that when I sit downto animate in Soft, I’m sittingat a customizable workstation.

Soft’s swiftkeys allow pretty mucheverything to become a hot key. It’sremarkably easy to set up your combi-nation of swiftkeys so that you cankeep one hand constantly on themouse and the other hand in the samebasic location on the keyboard. As inPowerAnimator, I found the perspec-


34


F I G U R E 4 . Function Curves and Schematic Views.

SoftimageMontreal, QB, Canada(514) 845-1636http://www.softimage.com

Recommend Hardware: Intel-based Pentium w/128MB of RAMTested On: Intergraph TDZ 2000Software Price as tested: $7,500 for base package Pros: Seamless, clean interface, solid IK, and basic animation tools.Cons: Function curve editing is too simplistic, and some basic functionality is missing.Comments: I feel this is still the best animating tool on the market for simple character

animation. It has just enough tools to get the job done, without any extra fluff.

Softimage|3D 3.8

tive window extremely useful for orbit-ing around my characters from differ-ent viewpoints, tweaking as I went. Theoverall experience is very fluid. Nocomplaints here.

MOTION CURVE EDITING. The areasI that felt were most lackingwere Softimage|3D’s Fcurve

(Figure 4, top center) and Dopesheet(Figure 3, bottom center) windows.You can readily display all or just theselected function curves for any givenobject or group of objects. Changingthe slop and inflection of a point isdone either with a procedural effect orby moving the Bezier-like handles onthe keyframes themselves. Having cutmy teeth on PowerAnimator’s actionwindow, however, I often found myselftrying to delete keyframes on morethan one curve at a time, or trying toscale the existing curves around a pointother than the origin. Neither of theseactions are possible in the Fcurve win-dow. Some of this functionality existsin the Dopesheet, but there remain afew basic tools for curve manipulationthat Soft just doesn’t have.

INTERFACE/EASE OF USE. Look atFigure 4; you’ll notice thatthere are no icons. Softimage

hasn’t succumbed to the dreaded iconmania that is so prevalent in today’swindows-based applications. The lastthing you need to do at 2AM the nightbefore a milestone is to hunt aroundyour interface for obscure little buttonsto push. Hopefully, at that point youcan still read (at least phonetically), andthe buttons in Softimage|3D’s interfacewill still be readable for what they do,each one with its name clearly marked.

The schematic window (Figure 4, bot-tom left) acts as a functional version ofPowerAnimator’s SBD window, allow-ing you to view and alter parametersassociated with object hierarchies, con-straints, and animation tracks. With afully operational skeleton in midse-quence, this view tends to get a bit clut-tered, but maybe that’s just a commenton how an animator’s mind works.

Maybe Softimage is just lucky, ormaybe its developers are just good lis-teners. Whatever the reason, they’vecome up with an interface that workswell. The interface seemed to disappearafter just a few minutes working withthe tools, and there don’t seem to bethat many hurdles to jump over to getto where you want to go. The bottom

line is that the work area feels right.WHAT’S COMING IN SUMATRA. Sumatra isSoftimage’s next-generation 3D system(Figure 5), which will include nonlin-ear animation capabilities (NLA). NLAwill allow animators to seamlesslyblend animations independent of thescene timeline. For example, you cansave out sequences for multiple anima-tions and then paste them back in toform a single sequence. What isunique to NLA is that the animationswill be added together graphically,allowing animators to easily view andmanipulate the transitions in thecurve editor. You’ll have the function-ality of MAX’s Motion Flow Mode,with the interface clarity of Soft-image|3D’s Animation Sequencer.

According to Softimage, Sumatra willbe have a fully-threaded architecture,which, while keeping the functionalcleanliness of the current modular for-mat, will fully integrate modeling, ani-mation, rendering, and compositingonto a single workspace. This will putSoftimage|3D on the same plane withMAX and Maya in the sense that youwon’t have to jump between modulesto model, texture, and animate.

I was hoping to get enough informa-tion on Sumatra to be able to do a fullsection about it. Unfortunately, mytiming was a little early. The people at

Softimage told me that Sumatra willlook and feel a bit different, will haveseveral added new features, but will notlose any of the simple functionalitynow enjoyed by current users.

As this article goes to print, Sumatrais still several months from shipping.Until that time, the much touted non-linear editing and seamless animationtools will have to wait. In the interim,Softimage is releasing versionSoftimage|3D 3.8 and Twister to pre-pare their customers for the new ani-mation environment.

Alias|Wavefront’s Maya NT.

A lias|Wavefront claims that inMaya, virtually everything is ani-

matable; that any attribute of anyscene component can be used to driveany other object’s attributes, includingposition, rotation, scale, velocity,color, transparency, and so on. With afully integrated working environment,you can set keyframes, generate pathanimation, and edit timing all in a sin-gle shaded and texture-mapped view.

Clearly the migration of Alias’s prod-ucts to the Windows NT platform isindicative of something: either to takeadvantage of the large Windows NTuser base or simply to grab a larger


36


F I G U R E 5 . The Sumatra interface.

share of the lower-end markets. Aliasmade a firm statement of commitmentto game developers when it announcedit’s intention to ship a native WindowsNT version of Maya. Full of new fea-tures and sporting a look reminiscentof an offspring of PowerAnimator and3D Studio MAX, Maya NT appearspoised to take the game developerworld by storm. MAYA EMBEDDED LANGUAGE (MEL). Whatsets Maya apart from other tools in theindustry is its scripting language, MEL.Here’s how it works: when you activatethe MEL Script window, every actionthat you take generates a MEL scriptequivalent in the window. Since theentire program was written using MEL,every action that you perform has aMEL script equivalent. Say you performa series of actions over and over, andnow you want to create a button thatdoes the same thing. In Softimage|3Dor MAX, you’d have to learn MaxScriptor the appropriate SDK, or depend on aprogrammer’s talents. With the MELScript window open, you simply per-form your actions, grab the equivalentscript, and drag it onto your menu bar.

Maya automatically creates a button onthe menu bar that contains the equiva-lent MEL script. Now all you have to doto execute your stack of scripts is clickthe button. It’s very simple. If you needto modify your button’s MEL script, allyou have to do is drag the button intothe MEL Script window, and you’ve gotyour original script back.

Compared to the poorly documentedand arcane MaxScript for 3D StudioMAX, I found MEL to be far superior.What it boils down to is this: whileMaya may not have every plug-in forcharacter animation that you need,with MEL and a little patience, you cancreate your own plug-ins.

INVERSE KINEMATICS. One of thetouted strong points of MayaNT is its powerful, multiplesolution-based IK systems.Part of a continued evolution

from the multi- and single-chain solu-tions in the PowerAnimator series,Maya boasts three different, config-urable methods for arriving at an IKsolution. Newest to the group, and byfar my favorite, is the IK-Spline solu-tion set. Basically, the user creates an

IK chain, and then constrains thechain to a spline. As the spline is bentand deformed, the IK chain bends anddeforms to keep up. It’s perfect for ani-mating long tails and neck segments,or for creating realistic motion in awhip-like tentacle.

CONSTRAINTS. Maya ships with anumber of constraints for usewith its IK systems. Point,Orientation, Aim, Scale,

Geometry, Normal, and Tangent are allincluded. The real power comes inwhen these are used in conjunctionwith MEL. A major part of the designphilosophy for Maya was the tiereduser concept, in which a single experi-enced user (Technical Director) gener-ates a digital puppet using IK, con-straints, and MEL. These digitalpuppets can then be handed off tomore junior groups of animators, whomay not necessarily have the knowl-edge or experience to generate therequired MEL scripts on their own.

CLASSIC HAND ANIMATION. Hereagain I think it will take sometime for the interface to sinkin and become widely accept-

ed, as some of the basic functionalityhas become buried under new features.Still, the basic functionality is there.The Channel Box has replaced thePowerAnimator’s Object Info window,displaying the properties, position,scale, and rotation of a selected object.When keyframes are set by hand, val-ues are stored only for those objects inthe Channel Box. So, for example, ifyou don’t want to generate keyframesfor an object’s position, you simplyremove the positional windows fromthe Channel Box.

Alias|Wavefront boasts that in Maya ,“Everything is a node, every node isanimatable, and every node can belinked to every other node.” Say, forexample, you want to copy the rota-tional information from one forearm toanother. You would simply go into thedependency graph (Figure 6) and drag aconnector from the rotational node ofone forearm to the rotational node ofthe arm that you want to animate. Nowboth arms share identical animation.

Most of us can grasp that — it’s justa modified version of cut and paste.But what if you want to do a littlenonlinear editing, say to blend twoanimations together to get a thirdunique animation? Even this is possi-


38


F I G U R E 6 . Dependency Graph.

Alias|WavefrontToronto, ON, Canada(800) 447-2542http://www.aw.sgi.com

Recommended hardware: Intel Pentium w/128mb RAMTested On: Intergraph TDZ 2000Software Price as tested: $10,000 for base packagePros: You can pretty much do everything with this program.Cons: You can pretty much do everything with this program.Comments: The new interface, Windows NT support, and some additional animation

features that PowerAnimator doesn’t have (such as a dopesheet, an interactiveschematic window, and MEL scripting) make the functionality of this product astound-ing. All of this is partially overshadowed by the fact that to do the simple things, youhave to jump through too many hoops.

Maya NT

ble. When I asked if Maya had anyability to blend animations, BradClarkson in Alias|Wavefront’s Seattleoffice had a handy suggestion. Byusing the color blend utility node, youcan link the transformation node ofthe first object to color 1 and thetransformation node of the secondobject to color 2. The resulting output,which is a blend of two colors and,therefore, a blend of two transforms, isinput to the transform node of object3. There you have it; an animationthat is the blended result of two com-pletely separate animations.

Finally, Maya’s expression windowfeatures a simple interface that evennonprogrammers can understand. The

expressions allow you to link oneattribute to other attributes using MELscripts and mathematical expressions.

MOTION CURVE EDITING. ThePowerAnimator’s Action win-dow has been replaced by the

Graph Editor (Figure 7, bottom center)and Dopesheet (Figure 7, top right). TheDopesheet can also globally editkeyframes, making it fairly similar toSoftimage|3D’s Dopesheet. The remain-ing functionality that was present inPowerAnimator’s Action window hasbeen given to the Graph Editor. You canmake changes to attributes in the GraphEditor and view the result in uneditableanimation curves. This is useful fordetermining how attributes change

when driven by expressions, dynamics,and set-driven key relationships.

INTERFACE/EASE OF USE. Withadded functionality, youinevitably get added complex-

ity. This often translates into a clut-tered workspace. However, Maya hasstriven to mitigate this complexity byusing a modular toolset format. Anadditional display window, called theHypergraph, allows you to examineand edit hierarchies, while theAttribute Spreadsheet (Figure 8) allowsyou to view and edit attributes for mul-tiple nodes in a table layout.Potentially one of the most usefuleveryday tools, it’s great for comparingor editing values across several nodes.

Clearly though, it’s the MayaEmbedded Language that makes theuser interface supremely customizable.With the ability to completely cus-tomize the work area and create theirown MEL-driven plug-ins, animatorswill soon be writing their own gameswithout the need for programmers,producers, game designers, or publish-ers. (O.K., perhaps not, but the MELScript toolset is pretty amazing!)

Maya NT promises to revolutionizethe way we think of Alias worksta-tions. With the potential for cus-tomization and the ability to run onboth SGI and Windows NT platforms,Maya is affirming Alias|Wavefront’scommitment to support the gamingindustry, while at the same time main-taining the options for ultra-high-endgraphics development.

Games such as FINAL FANTASY VII,RESIDENT EVIL, and TOMB RAIDER

demonstrate the success of virtual envi-ronments populated with real-time 3Dcharacters. As game developers try andmatch or exceed the standards set bythese games, more and more powerfultools are required. With the increasedcapabilities of these three tools, in thenext 18 months we will likely see areduction in the time it takes to devel-op better-looking, more complex char-acter animation. ■


40


F I G U R E 8 . Attribute Spreadsheet.

Thanks to Dan Kraus, David Free,Hayley Reed, Bob Bennett, Tristan Ikuta,Alex Dunne, Alex Walsh, Franca Miraglia,Jo-Anne Panchak, Brad Clarkson, MartinPreston, Olwen Nash, Lee Sullivan, andPorl Perrot.

Acknowledgments

F I G U R E 7. Dopesheet and Graph Editor.

directly access texture maps stored insystem memory, bus and memoryusage — as well as bandwidth — arestill very limited. A solution to theseproblems is texture map compression,which greatly reduces not only theamount of memory that a texture mapoccupies, but also the bandwidthrequired to fetch texture data.

S3 devised a compression schemespecifically for texture maps, calledS3TC, which yields benefits readily visi-ble to programmers while maintainingthe quality of artists’ creations (Figure1). Microsoft recently licensed this tech-nology and made it the basis of DirectX6’s texture map compression. As such,

this compression format should havebroad hardware and software support.

Taking Advantage of ReducedMemory and Bandwidth

T he speed at which texture data canbe accessed generally limits sus-

tained 3D fill rates, particularly whenhigh-quality filtering modes, such astrilinear, are used. With a given memo-ry or bus bandwidth, much more tex-ture data can be read with compressedtextures. The effective bandwidth withtexture compression is the actual datarate multiplied by the compression

ratio. So, for AGP-2x, where the maxi-mum theoretical bandwidth is512MB/s, the effective theoreticalbandwidth with six-to-one compres-sion is 3.0GB/s. By boosting the sus-tained fill rate, game performance canbe dramatically improved when textur-ing directly from system memory overAGP or when reading a texture out offrame buffer memory. Of course, themost obvious benefit to using com-pressed textures is that they require lessstorage space. This can be taken advan-tage of in a number of ways.BETTER TEXTURE RESOLUTION. Normally,texture storage requirements strain thelimits of available memory. With tex-


42

C O M P R E S S I O NT E X T U R E

DirectX 6 Texture MapCompression

b y D a n M c C a b e a n d J o h n B r o t h e r s

exture maps add visual detail to a scene without

increasing its geometric complexity. However, tex-

ture memory is a relatively scarce resource, forcing

game developers continually to tweak their software and art-

work to fit into the limited texture memory on the graphics

accelerator. Even with the availability of Intel’s Accelerated

Graphics Port (AGP), which lets the graphics accelerator TTDan McCabe has enjoyed working on computer graphics for the last 20 years. A significant portion of that time was spent at IBMResearch, where he worked on 3D rendering as well as dynamics simulation and the collision detection problem. Dan is currently a3D architect with S3 Inc., where he is defining key aspects of the next several generations of 3D hardware. Although S3 is headquar-tered in Santa Clara, Calif., Dan is based in S3’s Bellevue, Wash., office.John Brothers is VP of architecture and software development at S3 and has been instrumental in the design and development ofS3's recently announced Savage3D accelerator for the past two years. He is now working on future high-end 3D graphics platformsin development at S3 and is leading a great software group in putting out high performance, bug-free drivers.

ture compression, you can use higher-resolution (larger) textures, as well as agreater variety of textures at any giventime. Larger textures provide more sur-face detail on objects and can preventthe blurriness that’s often a conse-quence of overstretching small texturemaps. Larger texture maps also allowfor much more detail than would bepossible without compression. And youcan increase the number of texturemaps in use at any one time, enablingmore varied scenes.

Because the rendering surface is usu-ally stored in memory along with yourtextures, you can also increase the reso-lution of your rendering surface withthe additional memory made availableby compression. Needless to say, youmight not be able to increase your reso-lution in all aspects simultaneously,but having more memory availablegives you more flexibility and optionsfor improving your title. MIP-MAP USE. Increased amounts of tex-ture memory also make it easier to takeadvantage of MIP-maps. While MIP-maps require 30 percent more storageto house the down-sampled MIP-levels,texture compression easily frees up thisextra storage. Using correctly computedMIP-maps, you can efficiently eliminatealiasing artifacts that would otherwiseappear when mapping multiple texelsto one screen pixel. The correct way tocompute MIP-levels is with a low-passfilter, normally a box filter. ComputingMIP-levels with point-sampling to get“sharper images,” as one graphics chipmaker has recommended, completelyeliminates the intended benefit of MIP-mapping, which is to do high-qualitytexture antialiasing. Beware of comput-ing MIP-levels with point sampling.

As discussed so far, texture compres-sion can improve overall image qualitywithout impacting performance. In fact,texture compression should actuallyboost performance significantly. WhileMIP-maps were mainly invented toeliminate texture aliasing artifacts, theyalso happen to increase the perfor-mance of your rendering hardware quitea bit. With MIP-mapping, texture fetch-es are very localized. For that reason,your renderer can use a much higherpercentage of data read to generate sub-sequent pixels that will need texels fromthe same area of the texture. Also,because the texture fetches are localized,your application can read data in larger

bursts with fewer page breaks in memo-ry. Such an implementation increasesthe effective bandwidth over the AGPbus, system memory, or frame buffer —if the texture happens to be there.Without MIP-mapping, accesses to tex-ture memory become random, wreckinghavoc on bus and memory efficiency.

Data bandwidth, particularly textureread bandwidth, will often be the limit-ing factor in achieving high, sustainedfill rates. Getting around these limitingfactors and achieving high, sustainedfill rates is what we’re all really after, ashigh paper numbers don’t do much tospeed real applications.TRIPLE-BUFFERED RENDERING. Texture com-pression also frees up memory that youcan use for triple-buffering. If you'redouble buffering to synchronize bufferswaps with vertical retrace to avoidtearing, you're probably aware of theengine stalls that this method causes.Triple buffering can eliminate theseengine stalls. Triple buffering can alsoboost frame rates, especially as framerates increase and the cost of synchro-nizing buffer swaps with verticalretrace increases. While switching totriple buffering can result in a 30 per-cent frame rate increase, it does so atthe expense of increased frame bufferrequirements. But if you’ve compressedthe texture data, you should already

have this memory available.IMPROVED SUSTAINED FILL RATE. The amountof memory that your graphics enginecan transfer in a given unit of time isbounded by system design. One of thefactors limiting sustained fill rates isthe speed at which textures can befetched from memory. Compressedtexture maps consume less bandwidth(only 25 to 33 percent of the band-width required for uncompressed data)and therefore can be fetched faster. Thebottom line is that compressing texturemaps will result in faster rendering.

How It Works

S 3TC compresses textures to a fixedsize of 4 bits per texel for opaque

textures or 8 bits per texel for texturesrequiring more than 1 bit of trans-parency. An image rendered with com-pressed textures is virtually indistin-guishable from an image rendered withthe original uncompressed texturemaps. This image quality is the primaryreason Microsoft adopted S3TC as thebasis for DirectX’s texture compression.

The compression scheme breaks a tex-ture map into 4×4 blocks of 16 pixels.For texture maps with just 1 bit of trans-parency or none, each texel is represent-ed by a 2-bit index in a 4×4 bitmap, for


43

Display

Frame Buffer

Graphics Chip

CPU

AGP

PCI

Chipset

System MemoryTexture 1Texture 2

Texture n

1 Compressed textures require 1/6 amount of memory

• Reduced memory requirements • Permits storage of larger and more complex textures

Disk Drive

Dramatically reduced traffic on AGP bus

Increased performance through on-the-fly texture decompression • Higher quality through more complex textures

3D games and applications store

compressed textures.

23

F I G U R E 1 . S3 Texture compression (S3TC) is the DirectX 6 standard.

a total of 32 bits. In addition to the4×4×2 bitmap, each block has two 16-bitcolors in RGB565 format. From thesetwo explicitly encoded colors, S3TCderives two additional colors, yielding afour-color lookup table. The systemthen uses these 2-bit indices to look upthe texel color in this table. In total, the16 texels are encoded using 64 bits, foran average of 4 bits per texel. The samescheme can also support 1 bit of trans-parency. When a 4×4 block includestransparent texels, the two encoded col-ors are swapped to indicate that theblock has just three colors — one of thebitmap encodings (11) indicates a trans-parent texel. The third color is deriveddifferently in this case. (Figure 2).

If your game makes uses of moresophisticated transparency, you canencode an additional 64 bits for trans-parency information in each 4×4 block.S3TC provides two mechanisms toencode complex transparency effects: iteither explicitly encodes the 4 most sig-nificant bits of each pixel in the alphachannel in a 4-bit-per-pixel bitmap, orit employs a linear interpolationscheme similar to that used for color

encoding. With the explicitly encodedvariant, you can capture additionaltransparency information by ditheringthe alpha channel prior to truncating itto 4 bits per pixel. One great thingabout this scheme is that the blocks arecompletely self-contained and no addi-tional data needs to be fetched todecode the 16 texels in a block. No codebook, for example, is required, as invector quantization schemes. Thisadvantage is important, because havingto do two fetches to decode a texel is aserious performance problem.Additionally, you won’t need to hasslewith managing code books or palettes.

Simple Decoding Hardware

D ecoding compressed textureblocks is a simple process and,

therefore, very inexpensive to imple-ment in hardware. This simplicitylends itself to very fast implementa-tions and a straightforward approachto replicating decoding logic in orderto decode multiple pixels in parallel.

S3TC’s simple decoding scheme isable to achieve high-quality results bycomputing a linear approximation ofthe color space in a small block. RecallTaylor series mathematics, which statesthat any function can be adequatelyapproximated over a small interval bythe first two terms in the Taylor series:the constant term and the linear term.This is precisely what S3TC does in thecolor space of the block.

Using S3TC Texture Compression

U sing S3TC texture compression inyour application is very simple as

it’s directly supported by DirectX 6.Your artists create artwork using thesame tools that they’ve used in thepast. You perform a one-time compres-sion as you create your distributionmedium. Then, when your softwarerun time loads the compressed texturemap, a simple modification of yourexisting code suffices to load the com-pressed texture.

Although decompressing the encod-ed texture map is a simple matter, com-pressing it properly is a complex taskthat can be time consuming if you wantthe maximum possible quality.Therefore, you’ll most likely be com-

pressing your texture maps when youcreate them (or at least, before youplace them on your distribution medi-um). To assist you with this conversion,S3 has made several compression toolsavailable on Game Developer magazine’sweb site. Even if you don’t use precom-pressed textures in your application,S3TC’s fast encoder can still deliver 95percent of the expected image quality.

If you use Adobe Photoshop to createor manipulate your artwork, you can usethe S3TC Photoshop plug-in (S3TC.8BI)to extract compressed texture mapsseamlessly from that graphics tool. Thisplug-in lets you open and save S3TC filesas if they were native to Photoshop. Thisapproach is the best one to take, espe-cially if you’re using a relatively uncom-mon image format for your textures.

On the other hand, if you’re using animage editor other than Photoshop, youcan create and view S3TC texture mapfiles with our standalone utility,S3TC.EXE. This utility accepts a numberof commonly used image formats, suchas .BMP, .JPG, .TIF, and .TGA. It alsoallows you to create compressed texturemap files with or without MIP-maps.With either the standalone utility or thePhotoshop plug-in, creating and viewinga compressed texture map is straightfor-ward and unobtrusive to your workflow.

If you don’t want to compress atauthor time, you have several alterna-tives. You can compress during yourgame’s installation, when the game isstarted, or when levels are loaded. Thesealternatives are possible, because DirectX6 will include an API to compress yourtexture maps at run time. Bear in mind,however, that run-time compressionisn’t as fast, so we encourage you tocompress off-line whenever possible.Lastly, because Microsoft will have anAPI to decompress textures very quicklyin software, there’s no danger of havingproblems with hardware that doesn’thave built-in decompression support.

Choosing the Optimal CompressionLevel

S everal variants of S3TC are sup-ported within DirectX 6, depend-

ing on the level of transparency sup-port that your application needs. Eachof these formats has its own Four-Character Code (FOURCC) that youuse to create the texture map surface.


44

T E X T U R E C O M P R E S S I O N

R G B

R G B

W00 W01 W02 W03

W10 W11 W12 W13

W20 W21 W22 W23

W30 W31 W32 W33

W00 W01 W02 W03

W10 W11 W12 W13

W20 W21 W22 W23

W30 W31 W32 W33

RGB 565 Extreme 0

RGB 565 Extreme 1

4x4 bitmap of 2-bit weights

F I G U R E 2 . A 4×4 pixel block encod-

ed as two 16-bit color extrema, and a

bitmap of 2-bit interpolation weights.

Microsoft has defined five newFOURCCs. If your texture map is com-pletely opaque, uses only 1 bit of alpha,or uses color-key transparency, youshould be using FOURCC DXT1. Thisformat is the most compact representa-tion of the new compressed texture mapformats. It lets you switch, at the blocklevel, between fully opaque blocks andblocks with minimal transparency. Eachblock of 16 pixels is encoded in 8 bytesfor an average of 4 bits per pixel.

If your texture maps have more com-plex transparency effects, you can useone of the DXT2, DXT3, DXT4, orDXT5 formats. All of these formats usean additional 8 bytes to encode trans-parency information, for a total of 16bytes per block or an average of 8 bitsper pixel. DXT2 and DXT3 explicitlyencode alpha information by capturingthe 4 most significant bits of the alphachannel. Dithering on the alpha chan-nel can also increase the effective num-ber of bits that are represented. Youwould use DXT2 when your trans-parency has premultiplied alpha

(which Microsoft is advocating for thelatest release of DirectX) and DXT3 forthe more traditional nonpremultipliedalpha representation. DXT4 and DXT5represent the transparency channelusing a 3-bit linear-interpolationscheme similar to that which encodescolor information. Again, use DXT4 forpremultiplied alpha and DXT5 for non-premultiplied alpha. DXT1 is by far themost useful format because it com-presses down to 4 bits per texel andprovides excellent color resolution and1 alpha bit. The entire texture mapmust be classified by a single FOURCCcode. Allocating a compressed texturemap surface couldn’t be simpler — dowhat you’ve been doing previously, butuse the new FOURCC code instead.

Helpful for Internet-based Games

T exture-map compression is usefulwhenever memory size or band-

width are an issue (all the time). Oneobvious application of this technology

is transferring texture maps or imagesover the Internet. If you’re creatingVRML worlds for walkthroughs on theInternet, you’ll want to use texturemaps to provide visual detail to theobjects. While the bandwidth of a localgraphics system is already a concern,network bandwidth of Internet applica-tions is an even more critical considera-tion. Using compressed textures in yourVRML world will increase their userfriendliness and increase the acceptanceof VRML for your clients. And withMicrosoft’s Chrome project racing tocompletion, you can expect to see moremixing of 2D and 3D graphics on thesame web page for a unified look acrossall graphics elements. Expect to benefitfrom texture compression in this envi-ronment as well.

Texture compression saves memoryand bandwidth, and you’ll find thattaking advantage of S3TC withinDirectX 6 is trivial. You can easilyimplement its simple decoder in hard-ware, so you’ll likely be seeing thatfunctionality on chips soon enough.Regardless of the hardware support inthe short term, the support for fastdecompression built into the DirectX 6API makes this format a reliable solu-tion. It will work on all platformsbeginning with DirectX 6.

Sample Code

S ample code to load and use com-pressed S3TC textures in DirectX is

presented in Listing 1. With that code,you’ re locked and loaded. Use this tex-ture surface anywhere within yourDirect3D game or application. Checkthe S3TC web site for more informationabout how to use S3TC in DirectX 6and in the OpenGL S3TC extensions. ■


46

T E X T U R E C O M P R E S S I O N

Step 1: Load compressed texture from the file.

{{

DDDDSSUURRFFAACCEEDDEESSCC ddddssdd;;

DDWWOORRDD ddwwffiilleeccooddee,,ddwwBBooddyySSiizzee;;

BBYYTTEE** bbooddyy;;

FFIILLEE** FFpp==ffooppeenn((““tteesstt..ss33tt””,,””rrbb””));;

ffrreeaadd((&&ddwwffiilleeccooddee,,ssiizzeeooff((DDWWOORRDD)),,FFpp));; //// SSkkiipp tthhee ffiilleeccooddee

ffrreeaadd((&&ddddssdd,,ssiizzeeooff((DDDDSSUURRFFAACCEEDDEESSCC)),,FFpp));; //// LLooaaddeedd tthhee ssuurrffaaccee ddeessccrriippttoorr

ffrreeaadd((&&ddwwBBooddyySSiizzee,,ssiizzeeooff((DDWWOORRDD)),,FFpp));; //// GGeett tthhee ssiizzee ooff tthhee tteexxttuurree

bbooddyy == ((BBYYTTEE**))mmaalllloocc((ddwwBBooddyySSiizzee**ssiizzeeooff((BBYYTTEE))));; //// aallllooccaattee tteexxttuurree mmeemmoorryy

ffrreeaadd((bbooddyy,,ddwwBBooddyySSiizzee,,FFpp));; //// RReeaadd tthhee bbooddyy

}}

Step 2: Create the texture surface.

{{

LLPPDDIIRREECCTTDDRRAAWWSSUURRFFAACCEE llppddddss;;

//// AAssssuummee tthhaatt yyoouurr DDiirreeccttDDrraaww iinntteerrffaaccee iiss rreepprreesseenntteedd bbyy llppDDDD

llppDDDD-->>CCrreeaatteeSSuurrffaaccee((&&ddddssdd,,&&llppddddss,,NNUULLLL));; //// NNoott eexxaaccttllyy -- vveerriiffyy

//// FFaallllbbaacckk ssttrraatteeggyy ÐÐ

//// IIff CCrreeaatteeSSuurrffaaccee ffaaiillss dduuee ttoo llaacckk ooff vviiddeeoo mmeemmoorryy

//// OORR tthhee DDDDSSCCAAPPSS__NNOONNLLOOCCAALLVVIIDDMMEEMM ffllaagg ttoo ddddssdd..ddddssCCaappss..ddwwFFllaaggss

//// ccaallll CCrreeaatteeSSuurrffaaccee aaggaaiinn ttoo ccrreeaattee tthhee ssuurrffaaccee iinn AAGGPP mmeemmoorryy

}}

Step 3: Load the compressed data onto the texture surface.

{{

llppddddss-->>LLoocckk((NNUULLLL,,&&ddddssdd,,NNUULLLL,,NNUULLLL));;

mmeemmccppyy((ddddssdd..llppSSuurrffaaccee,,bbooddyy,,ddwwBBooddyySSiizzee));;

llppddddss-->>UUnnlloocckk(());;

}}

L I S T I N G 1 . Handling S3TC compressed textures.

S3 Inc.http://www.s3.com

DirectX 6http://www.microsoft.com/directx/

pavilion/default.asp

Intel’s AGPhttp://developer.intel.com/pc-supp/

platform/agfxport/AGP_FAQ.HTM


to improve the quality of interaction inother ways. According to the MotionFactory, the missing ingredient is rich-er, more realistic characters (Figure 1).

Think about what it would take tocreate a computer simulation of your-self. With readily available technology,we could make an elaborate physicalmodel, and we could animate it con-vincingly with motion capture data.We could program the character topursue a goal and to respond to partic-ular stimuli. If we’re good enough pro-grammers, we could even convey a

fleeting illusion of intelligence, creativ-ity, or sense of humor.

Now imagine inserting that characterinto a simulation of a subway station atrush hour. Will the illusion hold up? Ofcourse not. The environment is toorich, the potential interactions tooplentiful. The difficulty of managingcharacters forces us to set our games incontrolled environments — and bydoing so, we may be missing out onsome intriguing designs.

The Motion Factory’s first product,officially called the Motivate Intelligent

Digital Actor System, makes it alot easier to build complex char-acters. Motivate combines tech-nologies used to controlmechanical robots withadvanced techniques for animat-ing 3D models. Characters —both player-controlled and inde-pendent — can be assignedhigh-level tasks, such as “walk tothe door”; the Motivate run-timeengine will sweat the details.

Although Motivate would beuseful for animated 2D titles,this version works with 3D char-acters only. Motivate doesn’tlimit you to humanoid or

bipedal characters, but if your characterswill roam freely in space, they won’t beable to use the path generation feature;real-time path planning is a difficultcomputer science problem in just twodimensions. I guess you could say thatMotivate works best with 2.5D titles.

Inside the Box

M otivate is a product that doesn’tfit into a single niche. Its value

lies in four basic areas:• Modeling behaviors using hierarchi-

cal finite-state machines (HFSMs).This paradigm for defining player AIis very robust and scales gracefullyfrom simple to complex behaviors.

• Editing jointed 3D models andkeyframe animations. AlthoughMotivate’s Actor and Skill Editors arenot its most unique feature, they arevery capable.

• Real-time motion synthesis. Besidesanimating models with inverse kine-matics (IK), Motivate can blend andoverlay animations, so characters canmove more realistically.

• Performing real-time collision detec-tion and path generation. The pathgeneration allows actors to solve sim-ple navigational problems on theirown, even under changing conditions.The full package consists of the

Motivate run-time engine in redistrib-


48

R E V I E WP R O D U C T

Motivate 1.1: ItÕs AboutCharacter

b y D a n T e v e n

e game developers are guilty of following a

content formula, encouraging an arms race in

hardware, and being obsessed with technical tricks.

And we’re in danger of burning out our audience.

Once stunning graphics are taken for granted, we’ll haveWW

Dan Teven inflicted DOS/4GW on the game industry. For the past four years, he’slived off nuts and berries while struggling to come up with an even better acronym.He can be reached at [email protected].

F I G U R E 1 . A party scene created with the

Motivate authoring tool.

utable form; an authoring environ-ment based on the engine; a SoftwareDevelopment Kit with the expectedinclude files, class library, and samplecode; documentation; and two days ofhands-on training.

Plug-ins are used to support differentvideo and audio renderers, to importgeometry and motion data from differ-ent file formats (Figure 2), and toextend the scripting language that con-trols the run-time engine. You’ll usethe SDK to control digital actors andother Motivate classes from C++ code,and also to write new plug-ins.

Motion Factory has a multi-user run-time engine available, but I didn’t get achance to review it. Motivate should bea good fit for multiplayer gamesbecause you can use very concise com-mands to direct actors.

According to Motion Factory, every-one who buys the product goes throughthe two-day training session. Not every-one gets the same level of technicalsupport, however; buyers can purchasethree levels of technical support pack-ages separately. Support personnel usu-ally responded the same day to e-mailand always had an answer for me.

Motivate is hardware-locked withHasp, so you have to attach a dongle toyour parallel port before the authoringenvironment will start up. I hate copyprotection and hardware-lock schemesbecause they always seem to createmore problems than they solve. Sureenough, when I installed Motivate onmy NT 5.0 alpha, the Hasp driverscrashed and left my system unbootable.I never got around this incompatibility;I used Motivate on Windows 98 instead.

Learning the Product

I got up to speed in the authoringenvironment very quickly, in part

because of the training and in partbecause the environment is genuinelywell-designed. Learning the SDK is nodifferent than learning any other classlibrary, so it takes time. There is a lot ofinteresting sample code, includingexamples of each type of plug-in.Project files are included for MicrosoftVisual C++.

The documentation is in the midstof being made more task-oriented. Theuser’s guide appears to have made thistransition, and it’s excellent; the SDK

reference has not done so, and it’s mea-ger. I would have liked a more thor-ough overview of how the componentsand classes in the system interact — orat least a good index so I could be sureI hadn’t missed something. I wouldalso have liked longer discussions oferror messages and of delivering a fin-ished title using Motivate.

Behavior Modeling

F inite state machines are taught infirst-semester programming class-

es, so they’re not exactly break-through technology. On the otherhand, using them for behavior model-ing is clever, and Motion Factory hassucceeded in making them both prac-tical and accessible.

FSMs are ideal for creating charactersthat respond gracefully under all condi-tions because they force the author toplan for all possible combinations ofbehavioral states and events. The draw-backs to FSMs are that the number ofstate/event combinations can get verylarge and that their logic is fixed.Hierarchical finite state machines, asimplemented by Motion Factory, areFSMs in which states are allowed tocontain substates and procedural codecan be attached to state entry, exit, andtransitions (Figure 3). Also, states can

contain variables (which are also visibleto their substates). These propertiesreduce the number of states in an HFSMand allow it to adapt to changing envi-ronments. For example, you can reusethe same states for “hunting with thebazooka” that you used for “huntingwith the rifle,” and the transition codefor the “fire” event can worry aboutwhether you have enough ammo left —if you do, you can come back to thesame state, and if you don’t, you gosomewhere else. (If you hit anotheractor with your shot, then its HFSM willhandle the event; Motivate executesHFSMs for each actor simultaneously.)

HFSMs are created in the BehaviorEditor using a visual interface similar toa flowchart (Figure 4). States are repre-sented by rectangles, transitions byarrows. The hierarchy of substates isobvious becauserectangles cancontain other rec-tangles. Clickingon a state or atransition letsyou edit its prop-erties. Thoseproperties caninclude procedur-al code written inMotivate’s script-ing language,Piccolo.


49

F I G U R E 2 . The Import Actor

dialog for 3D

Studio Models.

A space is just a container for

objects that can potentially interact. A

space might correspond to a room or a

level in your game.

Actors are the fundamental objects in a

space: almost everything that happens is

an actor “acting” in some way. Actors

have properties such as jointed, hierar-

chical geometric models, skills, and

behaviors. Some actors (sets or props, to

continue the stage metaphor) may have

no skills or behaviors.

Skills are short sequences of animation

describing an actor’s most basic move-

ments. Think of skills as a vocabulary; the

parts of speech are locomotion (for exam-

ple, go to), manipulation (grasp, touch,

and place), and gesture skills. These may

be combined in various ways to generate

sentences (complex movements). You

can also create compound skills involv-

ing more than one actor — for actions

that must be tightly choreographed.

Behaviors are the “intelligence” in

intelligent digital actors: goals, respons-

es to stimuli, states of mind, and so on.

Actually, they’re programs implemented

as hierarchical finite state machines.

Finite state machines (FSMs) are sys-

tems that can be in a fixed number of

distinct states and that can change to

different states only in accordance with

predefined events. Because the states

and state-to-state transitions are

defined ahead of time, FSMs are perfect-

ly predictable.

Inverse kinematics (IK) is a way of

interpolating between keyframes in an

animation. IK allows some of the nodes

in a jointed model to be constrained and

adjusts the positions of the others as

necessary.

A Motivate Glossary

Let’s go over a few quick definitions.

Piccolo is a typeless, garbage-collect-ed language like JavaScript. The texteditor that’s built in for editing Piccolocode is very basic, but it doesn’t needto be more powerful, because most ofthe Piccolo functions you’ll write willbe just a few lines long. Small func-tions are also easy to debug, and there’san integrated debugger that’s morethan adequate.

Piccolo has hundreds of predefinedmethods. You can view their returnvalues and parameter lists from a helpwindow, no in-depth information isavailable within the environment.Fortunately, the manuals are includedon the CD in Adobe Acrobat format.

In the Behavior Editor, you canzoom in or out, so the userinterface scales up to handle bigHFSMs. However, the interfaceisn’t as polished as those of theActor and Skill Editors. It tries tocram too much informationonto the screen at once, soyou’ll have to do a lot ofscrolling in screen resolutionsless than 1,024×768. Therearen’t enough on-screen cues toexplain what all the toolbar but-tons do, or what the elements ofan HFSM diagram mean; a“What’s this?” tool would benice. And the few bugs Iencountered while testing theproduct were in this area.

Despite these minor com-plaints, the Behavior Editor is

good enough that you can buildHFSMs with hundreds of states and notfind yourself fighting with the tool. It’seven good enough to be used by teamsin which the game designer isn’t a pro-grammer. He or she could simply mapout the state diagram, leaving behindcomments that a programmer wouldeventually translate into Piccolo.

Editing Models and Animations

M otivate is not a 3D modelingtool, so you begin creating an

actor by importing a model created byanother package. Motivate accepts.3DS, VRML, and .DXF file formats.

(You can use models in another formatif you use the SDK to write a plug-in forthat format.)

The models must be made of rigidlinks; deformable meshes aren’t sup-ported. The geometry must be segment-ed, so that each body part to be animat-ed is a distinct node. Still, you don’thave to define the hierarchy in advance,and you can specify the handedness ofthe coordinate system at load time.Motivate supports both single- and dou-ble-sided polygons; perspective-correct-ed, lit, and filtered textures; and opacitymaps, but not bump maps or highlights(yet). Texture maps should be squareand a power of two in size.

After importing the model, you canedit it. This step can includeresizing the model, defining“up” and “forward” vectors,setting pivot points, con-straining joint movement,and rearranging the hierarchy— up to a point. You canrearrange nodes, removethem, paste in nodes fromanother actor, merge twonodes into one, or split anactor into two, but you can’tdivide a single node into two.

The Actor Editor has twowindows, with a renderedview in one and a hierarchygraph in the other (Figure 5).You can also use multiplemonitors. The user interface isintuitive, with good use of


50

P R O D U C T R E V I E W

x1

x1�

x2

x2

y

y

y

y

y

y2

y2

X1/Y1

X1/Y2

X2/Y1

X2/Y2

Y1/X1

Y2/X2

Y1/X2

Y2/X2

x

x

x

x

x

y1

y1

X1

X2

Y1

Y2

y

x

x1 x2 y1 y2

F I G U R E 3 . Conventional (left) and hierarchical FSMs describing the same system.

F I G U R E 4 . The Behavior Editor, with a state entry action

shown in the Piccolo Editor.

context menus (right-click), keyboardshortcuts, and the ability to work ineither window when it makes sense todo so. Basic operations, such as selectingan actor, are painless, even when theactor is off screen, small, or obscured.

Selecting an actor causes a transformmanipulator to appear around it. Themanipulator can be resized indepen-dently from the actor by pressing the[Tab] key, which helps make themanipulators unusually convenient touse. You can drag an edge to rotate anactor, or drag a handle (a “tab”) totranslate it. [Shift]+drag will scale theactor proportionally;[Ctrl]+[Shift]+drag will scale along justthe axis associated with the tab.

To create skills for an actor, you canstart from scratch, or you can importdata (3D Studio animations orBioVision motion capture data). TheSkill Editor is another two-windowview (Figure 6). One window plots thegeometry nodes against a timeline; theother lets you see the animation “live.”The basic idea is that you drag thegeometry into an orientation you like,associate it with a position on the time-line, and save it as a keyframe. To seethe skill animated, just click the Play

button or drag the time cursor backand forth to see what the actor lookslike at any instant.

Like the Actor Editor, the Skill Editoris painless to use. I have next to noexperience animating 3D models, butMotivate made it easy. My only com-plaint about the process is that Motivatedoesn’t come with any libraries of pre-built skills. A basic walk skill, forinstance, could be applied to any actorthat used a basic bipedal hierarchy.Why should I have to create one fromscratch just to get a prototype working?

Motion Synthesis

O nce an actor has been assignedenough skills, Motivate is able to

move the actor to account for chang-ing goals and obstacles. This flexibilityrequires motion synthesis, not justmotion playback. For example, if anactor has a walk skill, and is directed togo to a certain location, Motivate willloop the walk animation until the actorgets there; will adjust the animation ifthe actor has to climb up a set of stairs,making sure the feet touch the groundproperly; and will overlay other anima-tions, such as “chew gum,” as needed.If the actor is suddenly told to run inanother direction, Motivate will seguesmoothly from the walk to the run.

Although Motivate makes better useof animation scripts than any other

off-the-shelf game engine, and real-time IK is a powerful feature, it’s stillnot a general solution to the problemof motion synthesis. Real-time physicssimulation is the wave of the future; inanother year or two, we’ll start seeinggames in which joint movements arecomputed dynamically instead of inter-polated from keyframe data. Motivatelets you drive its actors with yourdynamics engine, but it doesn’t haveone of its own.

Path Generation and CollisionDetection

M otivate’s path-generation capa-bilities are another first for a

commercial game-authoring tool. Therun-time engine can determine an effi-cient path to move an actor from pointA to point B along any surface definedas a floor, avoiding both static andmoving obstacles. The path findingseems smarter than that used by mostgames I’m familiar with, but the algo-rithms can take a fair amount ofprocessor power. The computation isperformed asynchronously to mini-mize its effect on responsiveness.

Actors can also be sent from A to Busing a straight line, arc, projectile,spline, or sampled point path.Motivate uses these trajectories to pro-vide a full complement of cameramanipulation commands — and uses

52

P R O D U C T R E V I E W

T o validate my conclusions

about Motivate, I spoke with

Red Orb Entertainment, one of

the few companies that has

publicly announced a licensing arrange-

ment with Motion Factory. PRINCE OF

PERSIA 3D is an adventure-action game

set in ninth century Persia; rich in story

line and character development, it should

be a good fit for intelligent digital actor

technology.

According to Peter Lipson, chief tech-

nologist for PRINCE OF PERSIA 3D, the team

members happiest about Motivate are

the animators. The lead animator was

already familiar with Lightwave and 3D

Studio MAX, but found Motivate easier to

use. Because of Motivate, the team has

been able to use animators without a lot

of experience.

The PRINCE OF PERSIA team uses NDL’s

NetImmerse engine for rendering and Red

Orb’s own code for world management.

They are not using Motivate’s behavior

management because they already had

their own stuff working when they

switched over. According to Lipson, the

biggest integration challenge was

hybridizing the collision detection code

(since both NetImmerse and Motivate

want to do collision detection). He called

the integration “no harder than it ought

to be.”

Red Orb says Motivate is of higher

quality than tools they could have devel-

oped in-house, and it was ready when

they needed it. In short, they’re very

happy with the product.

Reality Check


F I G U R E 5 . Preparing to edit a joint

limit in the Actor Editor.

F I G U R E 6 . The Skill Editor playing

back a compound skill.

its path planner to prevent the camerasfrom being blocked. Smart cameras area real plus, but they’re almost an after-thought on Motivate’s long feature list.

For collision detection, Motivate usesthree different algorithms, dependingon the situation. Bounding volumesare used most of the time, with trian-gle-based checking used when veryaccurate results are required, such aswhen an actor moves along an irregu-lar surface or uses a manipulation skill.You can select a hybrid algorithm(intermediate in speed and accuracy)on a skill-by-skill basis.

Integration

M otivate’s diverse feature listmight make you a little nervous.

What if Motivate does too much, youask? What if it gets in the way of therendering code, or the physics engine,or the support for that cool subcuta-neous joystick you saw at the CGDC?

Motion Factory admits that it hadsome integration problems with theirrelease 1.0, but it has worked hard toopen up its architecture since then. Atpresent (release 1.1.2), the SDK givesyou the control you’ll need to adaptMotivate to your design: you can usethe class library to call Motivate fromyour own application framework, andyou can extend the authoring environ-ment by creating eight different typesof plug-ins.

The first type of plug-in is for videorendering. There are standard plug-insfor OpenGL, 3Dfx Glide, andRenderWare, with a Direct3D plug-inscheduled for this summer. The secondtype is for sound, althoughDirectSound3D is the only providedoption. You can also create plug-ins forimporting and exporting actors,importing motion data, extending thePiccolo language, editing custom prop-erties, and registering callbacks forimportant events.

Keep in mind that the plug-ins areused to extend the authoring environ-ment; you don’t need them in order toutilize Motivate classes in your C++code. If you use the SDK, your gamecan keep control of the main loop andtreat Motivate like a fancy animation orAI library. You don’t have to use everyfeature, but the interdependenciesamong the core components can be

slightly inconvenient. For instance, ani-mation depends on Motivate’s collisiondetection functions; collision detectionrequires an up-to-date object database;and therefore Motivate needs to knowabout every object in the world, eventhose you don’t intend to animate.

Performance

C ompared to the cost of rendering3D scenes, Motivate’s CPU

requirements are modest. However, itdoes need memory: the authoringenvironment allocated 30MB just start-ing up, and running a fairly basic demotook another 7MB. There is no built-inmeter that tells you exactly how muchmemory you’re using, so be prepared tospend some time adding instrumentsto your game to measure it. Version1.5, to be released soon after you readthis, is expected to need less memory.

And Now, the Bad News

O verall, I am extremely impressedwith Motivate. The quality of the

product is topnotch. Its features aregenuinely useful for developing a largeclass of games, and you won’t findthem in another off-the-shelf product.It’s being used for real game develop-ment, so it continues to improve (see“Reality Check”). It’s fun to use.

The bad news: the price puts it out ofreach of all but the largest developers.

Motion Factory offers two licensingmodels, each of which buys you tendeveloper seats for $25,000 andrequires a royalty buyout of $25,000 toship a title. In one model, the tendeveloper seats are for the entire devel-opment cycle of one title, and in theother, they’re for the life of a singlemajor version of Motivate. Whichmodel you choose depends on whetheryou’re developing several titles at once.

I won’t say this product is over-priced, because it would undoubtedlycost several times as much to developan equivalent product from scratch,but I could find a lot of other ways tospend $50,000. Has anyone elsenoticed that the acronym for MotivateIntelligent Digital Actor System isMIDAS?

If you’re weighing a Motivate licenseagainst the cost of rolling your own,

remember that you’ll own whateveryou develop yourself. You may be ableto reuse your technology for severaltitles; if you do a really good job, youmay be able to license it to others. Onthe other hand, Motion Factory did areally good job, and their solution isready now. Don’t forget that you’llspend considerable time developingactors, skills, and behaviors; if Motivatespeeds up your character development,it will pay for itself. ■


53

Rating (out of five stars):✪✪✪✪

The Motion FactoryFremont, Calif. 94538(510) 505-5151Fax: (510) 505-5150www.motion-factory.com

Price: $25,000 for the development kit,which includes ten developer seats.$25,000 when the title ships.

Software Requirements: Windows NT4.0, Windows 95, or Windows 98.

Hardware Requirements: Pentium with32MB RAM and SVGA; Pentium II with64+MB and hardware-accelerated 3Drecommended; 40MB disk space.

Technical Support: Three tiers of sup-port available, beginning at$1,500/year.

Return Policy: 30-day free evaluationperiod.

Pros:1. Hierarchical finite state machine para-

digm works well for modeling charac-ter behavior.

2. Powerful animation engine: real-timeinverse kinematics, motion blending,and composition.

3. A powerful authoring environmentwith a short learning curve.

Cons:1. Price puts it out of reach of indepen-

dent game developers.2. Fairly high memory requirements.3. No library of prebuilt characters and

motions for prototyping.Competitors: According to The Motion

Factory, the biggest competitor to thisproduct is the “Not Invented Here”syndrome. There are many productsfor 3D modeling and animation, suchas Kinetix’s Character Studio, but nocommercial alternatives for some ofthe other features.

Motivate 1.1.2

he number of people who have

had, and continue to have, an

effect on the development of racing

simulations at Atari is somewhat mind

boggling. In March 1974, GRAN TRACK

10, Atari’s first driver, featured a shifter,

a wheel, a pedal, and sound. Other nota-

bles were NIGHT DRIVER and SPRINT 2 in

1976 (SPRINT 2 was a two-player game that

was followed up by the one-player SPRINT 1

in 1978). POLE POSITION in 1982 was actual-

ly licensed from Namco but built by Atari,

and was followed by POLE POSITION 2 in

1983. SUPER SPRINT in 1986 and FINAL LAP

in 1988 round out the list, leading up to


AtariÕs SAN FRANCISCO RUSH:EXTREME RACING

TTb y C a m e r o n P e t t y

P O S T M O R T E M

54

the introduction of HARD DRIVIN’ in February of 1989,which was the first truly 3D driving simulation to be seenin the arcade.

Rick Moncrief led the stalwart crew of designers that createdHARD DRIVIN’. Some of these designers were members of theSociety of Automotive Engineers. The result of these develop-ment efforts, as history will attest, was a large contingent ofhappily addicted arcade goers, who stayed that way throughthe release of RACE DRIVIN’ in 1990 and even RACE DRIVIN’PANORAMA (with multiple, wrap-around screens) in 1991. (Anentirely separate division of the company was formed toadapt the driving model and market it as a police trainingdevice. I’ve been told that the police forces in question report-ed a marked increase in successful, first-time, high-speed pur-suits due to the training program.)

Eventually, Moncrief and crew, apparently not satisfiedwith the challenge of simulating a normal automobile,decided that their next game should feature an automobilethat also had retractable glider wings. Get up enough speeddown a hill, pop your wings out, and take to the air. Theyeven had a little fan in the top of the cabinet to blow air atyou when you got AIRBORNE (the name of the game). Theteam, known at that time as the Applied Research Group,did a fine job in the simulation, and once you learned tocontrol it, it was loads of fun. But it suffered from two prob-lems that proved fatal. First, it was too damn hard to fly (forwhich it picked up the fond nickname “Flyin’ and Dyin”and was the subject of many a late night lesson in crashlanding), and second, it missed out on a key trend in gamedevelopment at that time: texture mapping.

At almost the same time that AIRBORNE was being tested,Atari’s two main Japanese competitors in the racing gamemarket, Sega and Namco, came out with their own entriesinto the 3D racing realm. DAYTONA and RIDGE RACER bothstepped up the bar from the previous Japanese blit-based rac-ing entries and featured resplendent visuals due mainly totheir use of this newly emergent technology. So AIRBORNE dieda quiet death, the Applied Research Group faded away, andMoncrief and some team members left Atari to pursue a moredown to earth, but no less ambitious goal: creating a full-fledged, motion-platform-packing, monster-audio-blasting,driving simulation. The results can be seen now, or soon, in anumber of locations. Check out http://www.smsonline.comfor more up-to-date information.

I Left My Lunch in San Francisco

M eanwhile, back at Atari, gears shifted, and an internaldevelopment effort began to play catch-up to supply

3D texture mapping hardware. Two sets of hardware grewout of that effort — ZOID and TGS — neither of which eversaw the light of day. In addition, the reigns of the Atari dri-ving simulation effort were given to producer John Ray andthe “San Francisco Rush, or, I Left My Lunch in SanFrancisco” project was initiated to restore Atari’s lost posi-tion as the king of arcade racing simulations. This is aboutwhere I came into the picture. I had just finished up work asgame designer and associate producer on PRIMAL RAGE, and Iwas itching to get back into some 3D animation-orientedwork. After a few meetings, I was accepted onto the team as

associate producer and game designer. The core team origi-nally consisted of Master Ray, a few members of the formerApplied Research Group programming staff, and some artstaff from another recently disbanded project called METAL

MANIAX, a TGS-based, futuristic destruction derby.Marketing and sales were crying out for a DAYTONA-typegame, but the team was really looking to make its own mark.

We looked at DAYTONA carefully and tried to determine whyit was so much more successful than RIDGE RACER. We alsotried to learn from Eugene Jarvis’s CRUISIN’ USA, which sold awhole lot of units for Williams by overcoming weaker graph-ics with its pure fun factor and a dirt-floor price point. In theend, though, SF RUSH was directly descended from HARD

DRIVIN’ and used a variation on the same physics model. Thismodel not only simulated the engine and its effect on the


Cameron Petty has been alternately slaving and slacking atAtari Games since he entered the games industry in 1992. Hewas game designer and associate producer for both PRIMAL RAGE

and SF RUSH, and has immensely enjoyed seeing Atari Gamesgrow back into a cutting-edge endeavor. He's currently off in thewoods writing a sci-fi novel, but can almost always be reachedvia his laptop at [email protected]

55

A latter day incarnation of the RUSH team, from top to bot-

tom left side, then top to bottom right side: John Ray,

Spencer Lindsay, John Geraci, Gunnar Madsen, Steve

Riesenberger, Cameron Petty, Kirk Young, and Alan Gray.

wheels and, thus, the tire patches, but italso tracked the reciprocal forces backup through the drive train. This modelled to some key audio developmentsand enabled the sort of realistic force-feedback steering that made HARD

DRIVIN’ famous in the first place.RUSH took a long time to produce —

almost two and a half years. For theprogramming and hardware staff,much of that time was spent trying tobring up a new hardware system andcreate tools for it, or port between plat-forms. Alan Gray led the programmingeffort, focusing on the physics model.In the latter months of the project,John Geraci lent some key help withdrone AI, among other things. JimPetrick, Betsy Bennett, Forest Miller,and Dave Shepperd also contributed tothe programming, and there were toolscontributions and assorted otherefforts from several programmers fromother in-house teams (Bruce Rogers,Steve Bennetts, and Terry Farnham).Pete Mokris designed a new, cost-reduced force-feedback mechanismthat provided nearly the same perfor-mance as that used for HARD DRIVIN’ ata fraction of the cost. The hardwareteam is too long to list, but AndrewDyer and Steve Correll at Williams inChicago made key contributions.

Positive Developments

S F RUSH is, without a doubt, themost realistic simulation of San

Francisco that’s ever been done in agame. That’s not to say that there was-n’t a large dose of artistic license takenin the layout of the tracks; after all, a

fun race definitelytakes precedenceover an authenticsimulation in thearcade. Still, therewere a few key ele-ments of the pro-duction that standout as noteworthyand contributedto the success ofthe game.

1.SOLID

CONSTRUCTION

TOOLS. The art staffand the program-ming staff worked

extensively withfolks at MultiGen. We needed a versionof their MultiGen II plug-in RoadTools that generated a data structurewhich could be adapted to work withour driving model. As far as I know, thefolks in the Applied Technology Grouphad built their tracks for HARD DRIVIN’by placing each polygon individuallyin 3D space. The scale and variety ofthe worlds we envisioned for SF RUSH

would have made this approach pro-hibitive, so Spencer Lindsay, who hadworked with MultiGen on METAL

MANIAX, pushed through the effort toadapt Road Tools for our purposes.MultiGen had developed real-time sim-ulation databases for the military, sothe company’s tools were right up ouralley in terms of generating a datastructure optimized for real-time polyg-onal display. At the time, MultiGen IIwas one of few software packages avail-able that let us view our texture-mapped geometry in real time, almostexactly the way it would appear in thegame. The art staff was using mainlyIndigo 2 workstations, which wereupgraded to the Indigo 2 Extreme atsome point, and one Onyx with aReality Engine graphics head on it.Incidentally, this was before MultiGenII ran on any platform other thanSilicon Graphics. Additionally, each ofthe artists had a Macintosh Quadrarunning Photoshop 3.0 and other utili-ties, and a PC running 3D Studio R4,both of which were used almost exclu-sively for texture creation.

2.GOOD CHOICE OF SILICON. In 1995,parent company Time Warner

sold Atari Games to WMS Industries.This sale provided an tangential advan-tage to ’s development. At the time,

Williams happened to be working with3Dfx, a small start-up that had splin-tered off from Silicon Graphics. In acombined effort between Atari Gamesand Williams, the 3Dfx graphicschipset was integrated as a daughterboard into a proprietary developmentsystem known as “Phoenix.” Later, the3Dfx chipset was worked into a small-er, less expensive board solution forproduction. The 3Dfx chip gave usaccess to a number of nifty tricks,including vertex shading, two sets of(animatable) texture coordinates, MIP-mapping, and bilinear interpolation.

3.LOVE THOSE LODS. We made some ofthe most extensive use of levels of

detail (LODs) in the game communityto date. RUSH was, and still is for thatmatter, one of few games to create anenvironment with a naturally expan-sive feel. One of the art team’s man-dates was to avoid having geometrypop into existence out of a void, with-out having to resort to a fog or otherobscuring artifact. We also wanted tohave reasonably detailed geometryimmediately surrounding the track,however, which created a resource con-flict. All of the textures in SF RUSH weredrawn directly from the city itself via aperspective-correct lens on a 35mmcamera. Used in conjunction with ascanner and Photoshop, this approachgave a sense of gritty realism to theenvironments. We wanted to haveflower bushes, trees, and window boxesalong the road as players jumped theircars over the length of Lombard Street,but we also wanted to let players seeout over Coit Tower to the Bay at thesame time. We wanted players to beable to look down the entire length ofMarket Street, but if they were to stopand look down a side street, theywould see another vista, or at least analley. All this, while maintaining adecent frame rate, which we defined as30Hz, was no easy task. The solution,we found, was to extensively exploitthe use of LODs.

MultiGen was once again the tool ofchoice (and still is, for that matter, withCreator) for its ability to implementLODs, another concept that grew out ofthe military simulation industry.Everything in SF RUSH has multipleLODs, and all of the LOD switch rangesare finely tuned to create a sort of ani-mated facade. Geometry is switching injust around the corner and right under


56

P O S T M O R T E M

the player’s nose in SF RUSH, but they’reunlikely ever to notice it, unless theylook very closely or someone points itout to them. The fact that SF RUSH is aracing game aided our efforts in achiev-ing this effect. Following a race courselimits the number of routes that a play-er is likely to take through the city,which consequently limits the numberof angles/speeds at which you canapproach objects/locations in the game.Also, we spent a lot of time rebuildingsets of LODs that were too polygonheavy, in order to maintain the framerate once the final hardware was avail-able. In the end, an awful lot of handtuning and elbow grease was requiredto get right, but I think we were able tocreate a good sense of expansive spaceswithout sacrificing too much detail.

4.SWEET, SWEET MUSIC. I’ve heardreports that the musical selec-

tions for the consumer releases ofRUSH, which were taken directly fromthe coin-op version, were not appreci-ated by consumers. I have to apologizeto all the people who feel that way, butwe did that (almost) on purpose. Theentire team was of the opinion that themost important thing for the gameaurally was quality of the sound effectsas opposed to the sound tracks. Thatmeant that the engine sound was para-mount, closely followed by wind noise,road rumble, a proper Doppler shifteffect for other cars, and reverb (fortunnels and canyon-like city streets).The sound tracks were relegated towhatever time and resources remainedafter implementing the effects, whichis why the music on an optional switchin the cabinet, and the default settingis no music at all.

The intricacy ofthe driving modelmade it possible tocreate an enginesound that wastrue to life. Thetorque and loadparameters fromthe engine wereused to drive anaudio model thatthen acted upon aseries of samplestaken from variousautomotivesources. In-houseaudiophiles

Gunnar Madsen,Chuck Peplinski, and Todd Modjeskiteamed up with contractor DavidRiesner and the Atari Industrial Designteam (Mark Gruber, Ralph Perez, andPete Takaichi). They produced a quadra-phonic sound system design for the cab-inet, rounded out with a seat mountedsub-woofer, that would do justice to thegame’s detailed audio effects.

The one thing that really puts the SFRUSH experience over the top turnedout to be something we hadn’t antici-pated: the audio. The audio, in combi-nation with the rest of the elements ofthe game, increases your level ofimmersion in the experience. Theaudio experience is very evident in thegame when you get air going over hillsand off jumps. The combination of therealistic physics model and a full-weight car going well over 100 MPHmakes for long jumps in which the carseems to float. Perhaps due to theseintense physics, there was always asense of disconnection from the carwhen it was jumping. Then we addedthe road rumble, got the seat-mountedsub-woofer working, and actuallylinked the road rumble to the car’sposition on or off the ground. It’s anextremely subtle effect, and is more feltthan it is heard, but when a player goesover a jump and the grinding rumblebeneath him or her turns to a coarsewhooshing sound, it really sells thefact that the car just went airborne.The audio guys, naturally, wished theyhad a better audio hardware with moreresources to put towards the audioeffort, but I think they did a fine jobwith what they had, given our goals.

5.CENTRALIZED PLANNING. When I firstjoined the team, design meetings

were being held in conjunction withstatus meetings for the entire team andweren’t particularly functional. I wasthe new kid on the block, and despitemy best efforts, the meetings alwaysdegenerated into separate groups.Everyone argued and brainstormedenergetically, but never came to anyconclusions either. Can you say,“Dilbert?”

This disorganization went on for abit until a certain key member of theteam threatened to be off about hisbusiness if there wasn’t a change, andat his suggestion a core design teamwas formed. The core team was com-posed of John Ray as producer, AlanGray as lead programmer, myself asgame designer, and the art lead,whomever that happened to be at anygiven time. I suppose it’s easy for me tosay, because I was included in it, but Idon’t think anything would have evergotten done if we hadn’t implementedthe core team design meetings. Also,we made it clear that intelligent feed-back and suggestions for alternate solu-tions were more than welcome fromthe rest of the team. We needed toestablish initial priorities, however,and assign short-term tasks while start-ing to map out what was going to be ahuge effort. To me, it was at this pointthat we actually started making agame, as opposed to developing theunderlying technologies that wouldmake a game possible.

Stumbling Blocks

I n spite of the fact that we finishedSF RUSH on time, and that we

achieved nearly all of the goals that weset for ourselves, we did encountersome significant hurdles. In general,however, we were able to learn fromour mistakes, and we turned most ofthese impediments into advantages.

1.MOVING HARDWARE TARGETS. Thedevelopment of the hardware pro-

gressed slower than we had anticipated,and the hardware itself was slower thanwe had hoped. Think about it: we werebuilding some of the first consumer-level 3D hardware. The RUSH art effort,in particular, faced the inevitable prob-lem of trying to hit a moving target bycreating graphics for a hardware plat-form that kept changing.

The production hardware came in


58

P O S T M O R T E M


60

P O S T M O R T E M

The original city map, with potential routes drawn in colored pencil

The following five images are a series showing the evolution of Track 3

A hand drawn route interpretation with topographical info for Track 3

61


Just the road surface.

Half decorated

The final product.

The following three images show three top-down orthograph-

ic views of the track during production, with all objects show-

ing their highest LOD.

two flavors: “Seattle” was a single texture-memoryunit (TMU) version (used on MACE and GRETSKY 3DHOCKEY), and “Flagstaff” was a two-TMU version ofthat board that also included the Cage audio hard-ware, a proprietary audio board that provided 16channels of 16-bit sound. Switching hardware gearsin midproduction was a bit of a mixed blessing; wehad to port the physics model to the new platformand revamp the art tool chain. In the end, however,the new hardware turned out to be just what thedoctor ordered. Once the port was done, Alan Graywas free to work on the game and underlying tech-nologies, and the hardware effort, focused inChicago, was in hands that were devoted entirely tothat pursuit. At this point, we devised a new sched-ule based on the availability of the new hardware,which was six months away, and the crunch began.We eventually met that schedule, thanks to someserious help in the eleventh hour.

2.LEADERSHIP LACKING. The RUSH art effort sufferedfrom the art team’s lack of a strong leader.

Initially, this task fell to Michael Prittie because hewas the most senior of the group. Michael was a fineartist/modeler/animator, but lacked the technicalbackground to lead a cutting-edge, real-time 3Deffort. Next in line was Spencer Lindsay, who wasdefinitely the technical art lead throughout the pro-ject. At that point, however, Spencer wasn’t ready toassume the duties of managing and scheduling therest of the art team. For a while, Michael andSpencer tried to divide the lead duties betweenthem, which really didn’t work.

As a result of all this confusion, Rob Adams, whowas in charge of texture production and 2D work forthe game, was, for the most part, left to his owndevices. Rob was a talented artist, and he produced aplethora of textures. However, there was minimalorganization of these textures into a library, much ofthe modularity of the overall texture set had to berethought, and the project required a global color bal-ancing. Rob wasn’t modeling worlds until late in theproject, and as a result, wasn’t properly aware ofsome of the implications that our mapping methods(for example, separating building tops and buildingbottoms so that the textures could easily be com-bined into a variety of buildings, or tailoring thehouse and building bottoms to the predefined hillangles that we were using to model the tracks) shouldhave had on his texture development. The discrepan-cies between Rob’s work and our mapping efforts rep-resented relatively small problems, but precludedhandy solutions to the daunting task of modelingthree-and-a-half-miles worth of city streets while try-ing to avoid too much repetition. The lesson to belearned from this set of circumstances, in my opin-ion, is that everyone on an art team should do bothmodeling and texturing, as the two are closely linkedin today’s 3D games. In fact, Rob’s texturing skillsimproved when he began modeling in earnest, andhe turned out to be an excellent modeler as well, amuch-needed help in the latter stages of the game.

Eventually, towards the end of theproject, we decided that I should takeover as art director. I was brought ontothe team as game designer, but I hadjust finished a blit-based game, so I wasinitially discounted as a 3D artist. Iquickly became frustrated, though, atdesigning tracks on paper and watchingover Spencer’s shoulder as he built theroad surface for the first track. With theteam’s permission, I began working thenight shift so that I could use the Onyxto learn MultiGen II and proceeded tomodel the road surface for the secondtwo tracks. When the track surfaceswere done and the game design was ina fairly stable state, I went on to startmodeling scenery for the tracks as well.At this point, I began to realize that thetexture library needed to be rethought,and it was the resolution of this issuethat convinced the team to let me giveit a go as art director. This reorganiza-tion was only a few months before theend of the project. We were behind onmost fronts at that point, but we wereprepared to take a fresh look at thingsand push through. Upper managementsaw things differently, however, and sothe face of the art team changed againin the eleventh hour, necessitating anapplication of sheer labor towardsmeeting a deadline.

3.CORPORATE CHAOS. Along with aseries of lay-offs in late 1996,

upper management at Atari eliminatedthe position of Director of Animation,formerly held by Tom Capizzi. Theyalso decided that since we were behind,Tom should take over as art director forthe RUSH team. I’m sure Tom would bethe first to admit that he received his

direction on how the game should befinished from myself and the otherRUSH artists, but I’m the first to admitthat the project could never have beenas polished a final product withoutTom’s help. Tom took care of the cabi-net graphics, logos, and attract movies(with Greg Allen and Brent Englund onthe video shoots), and furthermore puttogether a subteam to finish up thecars. Tom contracted Kirk Young andchain-ganged Jeff Shears and GeneHigashi from another team to finishthe car effort, while the rest of the artteam concentrated on finishing thetracks and select screens. Tom also hadthe dubious pleasure of inheriting a bigorganizational and relational mess, andI am eternally grateful to him for tak-ing that mess off of my back just as Iwas hunkering down to hoist it up; butin the end, it all worked out.

4.THE GAME’S DIFFICULT LEARNING CURVE.The biggest design flaw with RUSH

was that, despite our best efforts, itslearning curve was still a bit steep for aportion of the arcade audience. Drivinga realistic car model through the streetsof San Francisco at extreme speeds isjust plain hard to do. We wanted play-ers to be able to get good at it, but wealso wanted the casual player to be ableto play it and not be scared off. Wetried to address this problem in ourdesign with two major tactics. The firstwas a smooth progression of the skilllevel required for each of the tracks.Players can drive Track 1 by justputting a foot on the gas; a player inthe Beginner car can pretty much goaround the track without steering.Which brings us to the second tactic:

the cars were divid-ed into four classes,going from theExtreme, which isthe full simulation,to the Beginner,which has serioustraining wheels,with a smooth con-tinuum between thetwo. By the time aplayer has masteredTrack 3, which actu-ally requires braking(or at least taking afoot off the gas) toget the best timesand can finish thecourse without

crashing in the Extreme car, he or shehas spent a lot of time and a lot moneyfeeding his or her addiction.

The problem lay in the fact that toomany people chose the Extreme carwhen they ought not to have done so.A player can choose Track 3 and usethe Beginner car and still not have toobad a time of it, but a beginner whochooses the Extreme car on any of thetracks is in for a rough ride. One of thelast revisions to the game featuredgraphics and sound cues designed tomake players aware of the dangers ofthe Extreme car. This tactic may havehelped somewhat, but John Ray con-tends (and I agree), that we shouldhave put access to the Extreme car on asecret button combination. Secret but-ton combinations are commonplaceEaster eggs in arcade games these days,and we used them for other player con-figurable aspects of the game success-fully. In the end, we decided, unwisely,not to use one for access to theExtreme car. If we had actually limitedaccess to the Extreme car, we probablycould have prevented a certain percent-age of players from being scared off bythe difficulty of the game.

5.RUSHED DESIGN. The only othermajor problem we had with the

design of the game was a lack of finaltuning. I was so busy scrambling tobuild tracks that a few fine-tuningissues slipped through the cracks,despite an excellent testing crew. I’mnot going to elaborate on those, butsuffice it to say that it’s possible tocheat a little in rare instances with theinitial release of the game, and thedrones can be kind of evil sometimes.

Pushing Boundaries

N ow, I don’t want you to get theimpression that the art effort on

SF RUSH was a complete fiasco. That wasdecidedly not the case, and though itmay have been a sprawling mess someof the time, it was successful in the end,and we managed to push a couple ofboundaries along the way. Many ele-ments contributed to the success of thegame design, but in the end, I think theinterplay of two main elements distin-guish RUSH from other racing games ofits kind and create a unique experience.The first is the combined sense of real-ism gained from the realistic physics


62

P O S T M O R T E M

Finished Rush cabinets rolling off the line in Waukegan, Ill.

model, the force-feedback steer-ing, the surround sound, andall the little touches. Thestrength of the car and the lay-out of the tracks let players per-form some incredible, decided-ly unrealistic stunts. This styleof game play, combined with asense of tactile realism, createsa positively surreal experiencethat can be quite a rush, so tospeak.

Since SF RUSH was released inDecember of 1996, sales of thegame have exceeded 10,000units (a large number for adeluxe, sit-down, coin-opgame), while sales of consumer ver-sions of RUSH have topped the 500Kmark and continue to climb. We werefortunate enough to have Ed Logg —the man who created ASTEROIDS,CENTIPEDE, and GAUNTLET, and convert-ed WAYNE GRETZKY'S 3D HOCKEY to theN64 — volunteer his team to do theN64 port for Christmas 1997. The in-house consumer RUSH team not onlymade the sprawling beast run properlyunder the N64s limited resources, butalso managed to add new graphics and

a portfolio of player adjustable effects(wind, fog, and so on) and options(tag, secret keys, and others). At thesame time, the coin-op team was work-ing on an update to the arcade version(SAN FRANCISCO RUSH: THE ROCK). Thisrelease would feature new tracks, aswell as incorporating a new set of carsthat were done by some of the MACE

team artists (Jeremy Mattson, PatriceCrawford, and Matt Harvey). The faceof the RUSH team changed once againnot long after the game went to pro-

duction. Steve Riesenberger,Aaron Hightower, RickGonzales, Garret Jost, and BrianDavis have all joined the team,and everyone but John Ray andSpencer Lindsay have movedon to different pastures. Boththe consumer and therevamped coin-op RUSH teamsare currently hard at work ontwo separate RUSH sequels.

Not long after the produc-tion of the original game, Imoved on from the coin-opRUSH team. Tom Capizzi hadalready left the company to

join Rhythm and Hues in LosAngeles, so Spencer Lindsay became artdirector again for RUSH: THE ROCK.Spencer had learned some valuablelessons over the course of the project— as we all had — and was well pre-pared to take up the reigns. Mean-while, I was off on vain attempt tomake something other than anotherracing game. I obviously failed miser-ably, as I’ve been working on nothingbut another racing game for the lastnine months. But that’s anotherstory… ■

64

P O S T M O R T E M

It’s a gutsymove in achaotic,often cut-throatindus-try, and

it’s not forthe faint of

heart. As anagent, I work

with a variety ofdevelopment groups,

both startup and veter-an. Shopping your game

to publishers can be astressful, emotional process,

regardless of your level of expe-rience, and particularly if it’s

your first attempt. Doing yourhomework first will allow you to go

in prepared. I have a list of specifictips that I like to pass on to gamedevelopers who are contemplatingtaking the plunge.PUT TOGETHER A VIABLE TEAM. I know thatsounds vague and obvious, but you’dbe surprised. A designer and a formertester do not a solid team make. Ideasare a dime a dozen in the game business,like film ideas in Hollywood. Withoutstrong technology and proven skills, yourdevelopment effort will hold little attrac-tion for publishers. A viable team shouldbe skilled in programming, animation,design, and project management. Withoutany of these pieces, you put your chances of

getting a deal in serious jeopardy. WRITE A DETAILED DESIGN SPEC. I cannot tell you howthrilled I am when a developer comes to mewith a fleshed out design document; to a pub-lisher, this shows you’re serious and havethought the concept through. Publishers getrather concerned when the developer seems tobe designing the game “off the cuff” during aninitial meeting. I recently met with one ratherenterprising developer who actually wrote atechnical design document, along with thedesign spec, before meeting with the publishers.DEVELOP A PROTOTYPE. A game concept, on its own,means very little in this industry. Publishingexecutives and agents are hit with loads of con-cepts every week, and without technology toback ideas up, your chances of landing that con-tract are slim. Unless you just jumped ship fromthe latest hit title, few publishers are willing torisk the necessary millions on an unproven teamwithout a core technology. The best prototypesare fully interactive, allowing the user to explorea bit of what the game world is expected to looklike. The final game rarely resembles the proto-type, but it gives publishers a feel for what thecore team is capable of putting together in a rel-atively short period of time.KNOW YOUR PUBLISHER. Set up meetings with onlythe most appropriate publishers, so as not towaste your time or theirs. In other words, itmakes little sense to begin your tour by pitch-ing a PC game to a console-only publisher.Likewise, some publishers are visibly boutiquein their title line-ups; it would be highly unlike-ly for a publisher only interested in PC militarysimulations to cut a deal on a 3D platformer forthe PlayStation.

b y S u s a n L e w i sS O A P B O X

Crossing the Chasm:

Tips for Startup Studios

S o you’ve decided to split and do your own thing

— you’ve gathered some industry cohorts and you

have a “great idea for a game.” Congratulations…

and I mean that.

Susan Lewis is an agent and the founder of ThinkBIG, which provides international representation to developersand publishers in the game industry. Prior to ThinkBIG, Lewis spent several years specializing in executive andtechnical search for the game industry. She is a Graduate of Brandeis University. Susan can be reached [email protected] or http://www.thinkbigco.com.


Continued on p. 71

Illu

str

ati

on

by

Ric

k E

be

rly

DO YOUR RESEARCH AND DEVELOP

A SOLID PITCH. Make it easyfor the product develop-ment people to explainyour concept conciselyto the other executivesand marketing people.Everyone hates to thinkof their game as a “metoo” title but if market-ing is going to predicthow the game will sell,they need to compare it toeverything else out there.Take GRAND THEFT AUTO, forinstance — indisputedly ahighly original game. Yet,one might pitch it as“MICRO MACHINES

meets A.P.B. meetsSYNDICATE WARS

(meets QuentinTarentino…).” LEGAL

CRIME could be pitched as“GRAND THEFT AUTO meetsSIMCITY meets CAPITALISM.” ARMY MEN

equals “COMMAND & CONQUER meetsToy Story.” You get the point. You mightthink that your game is unlike anythinganyone has ever seen before, but whenyou leave the meeting, the producer orbusiness development person you justmet with has to explain your game tothe rest of the company. Make it easyfor them. And be prepared to discusshow comparable games have done inthe past and to predict how your gamewill compete in the market that yourgame will face 16+ months from now.BUILDING A BRAND, SEQUELS. Very few pub-lishers have succeeded in developingmajor brands. Electronic Arts, Hasbro,and Mattel have arguably been themost successful in this endeavor, andvarious publishers have succeeded inchurning out tremendously successfulsequel lines (the DOOM/QUAKE series,MORTAL KOMBAT, and FINAL FANTASY, toname a few). Most publishers are keento leverage the money they spenddeveloping version one into deriva-tives, sequels, add-ons, and ports.What is the long term potential of yourgame, and how does the publisher gar-ner long-term profits?TELL THE TRUTH. Be honest when dis-cussing how much time you’ll need todevelop your game, how much it willrealistically cost to complete, and howlong your team will take to ramp up to

begin the project. If youmake unrealistic guar-antees, most publish-

ers will quickly recog-nize this. And even ifyou manage to con-

vince them to signthe deal, nothingprevents themfrom backing out

later. Keeping a dealcan be more work than

getting one signed, particu-larly if you’ve given the pub-

lisher unrealistic expectationsof your abilities.

FINANCIAL STABILITY. Publishers getnervous when they know you’rehanging on by a thread, financially.This means that if you slip on amilestone and they delay pay-ment, they run the risk thatyou’ll go out of business. If apublisher has already put hun-dreds of thousands of dollars

into a product, you have themover a barrel. And don’t think of this asa way to gain leverage; remember thatthe publisher owns the game you’redeveloping and can, in many cases, takethe project away from you and assign itto a more dependable developer. Havingyour staff and the equipment that you’llneed in place makes you more attractiveto a publisher. If you come to themwithout any company infrastructure inplace, they’ll know that a sizeable por-tion of your budget will be going to set-ting up your company (hiring, comput-ers, furniture, and so on), and that thepublisher for your second project willbenefit from the money that could havegone into the first.UNDERSTAND THE RELATIONSHIP BETWEEN

DEVELOPER AND PUBLISHER. Understandingdeal structures and publisher-developerdynamics keeps you from lookingnaïve (and hence, vulnerable) to thepublisher. Know what a realistic devel-opment budget is and understand thatthis budget is an advance on royalties,not a cost borne by the publisher; andwith that, know what a realistic royaltystructure is for a first-time developer.Bear in mind that the developer doesnot receive any back-end royalties untilthe development budget has beenrecouped by the publisher. The sad factis, depending on the advances that youreceived to develop the game and theroyalty rate that you negotiated, it

would not be unheard of for your gameto have to sell in excess of 250,000 oreven 300,000 units before you receivedany further money. GET IN FRONT OF THE CHECK-SIGNER. Thispoint should be obvious, but locatingthe bottom line at a publishing com-pany is never easy (and sometimesimpossible) for a startup developerwith few or no connections. You wantto meet with the decision-maker orsomeone close to them. It’s a painfullysubjective business, and if an inexperi-enced submissions coordinator fails tosee the value in your game, the powersthat be will never see it. Again, theseare connections that take time todevelop, but when the opportunity topitch your game to the executivesrises, go for it and don’t be intimidat-ed. If the game is as good as you thinkit is, they should want to make thetime to meet with you.

Getting a publishing deal is a daunt-ing task. As a startup company, be pre-pared for a lot of rejection. In an indus-try where typically only the top 20games make money, where fewer than10 percent of all games released sellover 100,000 units, and where the aver-age development budget has risen to$1.5 to $2 million, publishers areunderstandably cautious. Why is yourgame going to hit the top 10? What dis-tinguishes you from the hundreds ofother groups approaching each andevery publisher every month? Who isyour target audience? How can this beleveraged into future titles? Why willthe consumer buy your game instead ofTOMB RAIDER 3, QUAKE 3, FINAL FANTASY

VIII, RESIDENT EVIL 3, MADDEN ’00, andso on, and so on, and so on? Do nottake a meeting with a publisher if youare unable to answer these questions. ■

71

S O A P B O X

Continued from p. 72


august 1998latency in online gaming by optimizing packets, setting bandwidth limits, accommodating...

Documents