Computer Graphics World

January/February 2015

Issue link: https://digital.copcomm.com/i/457057

Contents of this Issue

Navigation

Page 41 of 51

40 cgw j a n u a r y . f e b r u a r y 2 0 1 5 It was necessary to return to the original scene descrip- tions in order to adjust certain scenes for more comfortable or dramatic presentation in stereoscopic 3D. Surprisingly, the depth-of-fi eld settings for the scenes were attenuated, since the depth of fi eld was intrinsic to the stereoscopic projections, whereas in the original movies, it was implicit in the images. There were certain movies where, because of the 3D eff ects, scenes had to be ad- justed in order to "look right." T H E W A N D E R F U L I N T E R A C T I V E S T O R Y B O O K S P R O J E C T The Wanderful project had a diff erent complication, since the products are narrative (read to me mode) and interactive (let me play mode). Because the interactivity is closely tied to the platform the product runs on, considerable work went into cre- ating a new interactive layer that sits above the Action Interpreter that derives its actions from input by the user, as shown in Figure 2 (on this page). This system must also render the sound and music interactively, something that hap- pens outside the Pixar system during a postproduction phase. Creating a new generation of the Living Books provided an opportunity to improve them. There were two major areas where distinct improvements were made for all the products: interaction/responsiveness and more convenient page naviga- tion. Both required some major modifi cations to the way the books operated. P I X A R T E C H N I C A L D I F F I C U LT I E S Pixar's movies are huge in scope, resulting from the collab- oration of hundreds of people, spread among a large number of teams and disciplines, and working under signifi cant time pressures. Because they chose to re-render these movies from the original assets to assure the highest quality, they needed to reconstitute a signifi cant amount of that production pipeline – but with a small team and a limited amount of time. Not having access to a lot of the primary leads who worked on the original movies (they were in high demand on active proj- ects) meant they had to recover a lot of knowledge from digital archaeology – documentation, wikis, and database notes. Even when the Pixar 3D team could simply recompile so ware, they o en needed to debug problems caused by changes during production that were un- fortunately not archived properly. One such example was the fact that the Pixar 3D team could not reasonably render its fi lms using old hardware, so it had to port old versions of the so ware onto modern archi- tectures and operating systems. The total amount of code is vast: millions of lines. And again, the 3D team does not o en have access to the principal so ware engineers of even the major sys- tems, much less the minor glue that holds a lot of the production pipeline together. A further complication was that Pixar had migrated from Sun SPARC to Intel-based Dell computer systems a er many of the original movies had been completed. Problems arose from the diff erences in the byte ordering of the SPARC versus the Intel processors (little endi- an vs. big endian). Daniel McCoy, one of the technical leads on the Pixar 3D project, says, "One of the algorithms used in the so ware for generating pseudo-random numbers turned out to have a deeply obscure sensitivity to the endian-ness of the underlying architecture. It was necessary to build in some byte-swapping deep into the so ware in order to generate pseudo-random number sequences approxi- mately matching the ones used for the original fi lm to compara- bly produce some of the algo- rithmically computed textures." And then there are the diffi culties presented by stereo, says Mark VandeWettering, one of the technical leads for the Pixar work. This aff ects camera setup, refl ections and refrac- tions (which were o en faked on Pixar's older fi lms), focus, special eff ects, and dissolves. W A N D E R F U L T E C H N I C A L D I F F I C U LT I E S Wanderful's technical chal- lenges were huge. None of the carefully archived source code was able to be located or provided by HMH, so Glenn Ax- worthy (the original Broderbund so ware architect of the Living Books engine and, later, lead programmer for Wanderful) spent more than a year examin- ing the data and programs from the packaged consumer CD- ROMs. Eventually, he developed a new Living Books playback en- gine from his knowledge of how the original engine worked and insights gained from running the existing programs. And all this was done without access to the original source code. This new engine also estab- lished an insulated environment for the original data to play back in, logically separated from modern OS platforms and making cross-platform develop- ment of the products possible. Furthermore, where the original engine was single-threaded and event-driven, modern platforms require separate threads for graphics, audio output, and user interaction. Creating this new playback engine as heavily multi-threaded o en created problems. Matt Siegel, the lead iOS and Mac programmer, recalls that "subtle timing-sensitive problems showed up during testing – and they tended to appear occasionally and only in real-time interactive playback. Tracking them down was chal- lenging and o en took a lot of patience and time to do so. FIGURE 2: WANDERFUL'S DATA-DRIVEN SYSTEM SHOWS THE INTERACTIVE COMPONENT.

Articles in this issue

Archives of this issue

view archives of Computer Graphics World - January/February 2015