В чем делали Toy Story
- Автор темы McST
- Дата создания
" ... вначале было Слово, и это слово было ТриДэМакс ...из него сотворили volume light, star sky, desert sun, fractal surface и water surface ... потом были созданы trees, plants и gross, затем low poly animals и birds, а в конце был создан hi-poly male character, и оживили его CS 1.02b, а потом клонировали Bip Spine его и экструдили в female character, и появился tutorial про Жанну Д'Арк ... " .... вот , собственно, с чего всё началось .... да ...
Да, ЭфОдин прав.
У них свой софт. И тогда был, и сейчас.
Если крупная студия рассказывает, что у них стоит Майя, не думайте, что она такая же, как у вас. Там производство поделено на много департментов, каждый решает свою задачу, а софтверный отдел по ходу под конкретные задачи дописывает, переписывает и меняет софт.
Предшественника 3D Max - Autodesk 3D Studio(или как его там) никто за реальный соф не считал, но в те времена(лет ~10 назад) кроме инхаузного софта были Softimage, Alias PowerAnimator и Wavewfront, которые работали исключительно на силиконах.
У них свой софт. И тогда был, и сейчас.
Если крупная студия рассказывает, что у них стоит Майя, не думайте, что она такая же, как у вас. Там производство поделено на много департментов, каждый решает свою задачу, а софтверный отдел по ходу под конкретные задачи дописывает, переписывает и меняет софт.
Предшественника 3D Max - Autodesk 3D Studio(или как его там) никто за реальный соф не считал, но в те времена(лет ~10 назад) кроме инхаузного софта были Softimage, Alias PowerAnimator и Wavewfront, которые работали исключительно на силиконах.
Некоторые наработки, которые вошли в Toy Story или были использованы там впрямую как технологии, Pixar привозил в Москву еще в 90-м году и показывал
Более подробное сообщение Эд Кэтмулл (президент Pixar) сделал в 1991-м, опять же в Москве.
В 1993-м, в Питере, вместе с главой Xaos Tools, была исполнительный продюсер Toy Story, которая рассказывала о Marionette, но не как о софте, а как о технологии.
В общем, сперва это была внутренняя работа Pixar с использованием собственных разработок.
Точно также, как и знаменитые "Люксо-мама и Люксо-сын". Это была изначально научно-поисковая работа, о которой в Computer Graphics World и других сугубо специальных журналах были даны статьи, там описывались кинематика объектов, свойства и описание поверхностей и т.д. Так, например, лампы совершали "тяжелые прыжки", "легкие прыжки", "прыжки с трамплина" (что вообще не вошло в ролик про "Люксо").
Как забавное дополнение, могу сказать, что Эд Кэтмулл был слегка шокирован использованием без спроса его семейки Люксо в качестве заставке к передаче. Но когда мы ему сказали, чо передача для детей, и она некоммерческая, он успокоился
))
Более подробное сообщение Эд Кэтмулл (президент Pixar) сделал в 1991-м, опять же в Москве.
В 1993-м, в Питере, вместе с главой Xaos Tools, была исполнительный продюсер Toy Story, которая рассказывала о Marionette, но не как о софте, а как о технологии.
В общем, сперва это была внутренняя работа Pixar с использованием собственных разработок.
Точно также, как и знаменитые "Люксо-мама и Люксо-сын". Это была изначально научно-поисковая работа, о которой в Computer Graphics World и других сугубо специальных журналах были даны статьи, там описывались кинематика объектов, свойства и описание поверхностей и т.д. Так, например, лампы совершали "тяжелые прыжки", "легкие прыжки", "прыжки с трамплина" (что вообще не вошло в ролик про "Люксо").
Как забавное дополнение, могу сказать, что Эд Кэтмулл был слегка шокирован использованием без спроса его семейки Люксо в качестве заставке к передаче. Но когда мы ему сказали, чо передача для детей, и она некоммерческая, он успокоился
))- Рейтинг
- 2
"RenderMan in Pixar’s Pipeline
Guido Quaroni, Pixar Animation Studios
guido@pixar.com
April, 2003
Introduction
The RenderMan Interface specification was published by Pixar at the end of the 80s and since the introduction
of a compliant renderer, at the beginning of the 90s, almost every single computer generated
image at Pixar has been computed by the same application, PhotoRealistic RenderMan (a.k.a. PRMan).
Today Pixar has completed the final renders of Finding Nemo, our fifth feature animation rendered
entirely using the same RenderMan compliant renderer. The architecture is pretty much the same but
the actual code has been improved and optimized over several years. This is one of the big strengths
of this software, it has been tested with complex scenes on different platforms. Pixar also sells PRMan
as part of the Rendering Artist Tools and this allows for even more use, testing and features.
Even if the underlying code is quite complex, running PRMan is pretty simple (although there’s no guarantee
it will produce a pretty picture). To be able to produce a picture, PRMan requires a RIB file, which
describes a scene and access to the resources specified in the RIB file like shaders and textures. The
three main environments where we access our renderer are Maya during modeling, shading and special
FX, Marionette during animation, layout and lighting, Ringmaster when we need distributed rendering
on the renderfarm like when computing final film frame. We also use command shell access to
PRMan for debugging, fixes and where we simply have a RIB file to render.
Pixar uses several computing platforms: SGI IRIX, Sun Solaris and Red Hat Linux. While we are phasing
out the IRIX OS, we are seriously looking at other attractive Unix-based alternatives. The renderer needs
to run on these platforms producing the same images from the same input data. In addition binary
modules used by the renderer must be compiled for the different platforms and made available to the
correct architecture that is running the renderer. This has been proven to be quite a challenging task
since there are subtle changes on the different architectures that must be taken into consideration. As
of today we use Linux boxes at the desktop and a combination of Linux and Sun Solaris machines in
the renderfarm.
Since we always use the same renderer (or at least for 99.99% of the shots rendered since Toy Story),
I assume that every mention to a renderer is actually PRMan and that every surface material or light is
a RenderMan compliant shader.
Working Environments (как раз то о чем шел разговор)
Pixar’s Artists and TDs interface with RenderMan from within 3 primary working environments: Maya,
Marionette and Ringmaster. In addition to these environments, we rely on specific tools for RIB generation
(MTOR), shader construction (Slim), RIB filtering (filterrib) and network rendering (Alfred). This
section will describe our pipeline to RenderMan from within each environment.
In Alias|Wavefront’s Maya we create RIB files using the MTOR plug-in. The file is then filtered with an
internal application called filterrib that allows us to modify any RIB statements using custom DSO
modules. For example, using filterrib we can add several custom RiOption and RiAttribute calls that
are specific to our internal pipeline. Shaders are authored via Slim. They can be generated on the fly
by Slim or they can be instances of existing ".slo" files. Using search paths, we allow MTOR renders to
access our shared assets like textures, shaders and archives.
Marionette is our proprietary animation system and within it we can perform PRMan renders at a number
of stages of its pipeline. The pipeline is similar to the Maya pipeline but differs in that shaders are
not built at render time and that the system performs RIB filtering prior to sending the render job to
Alfred.
Ringmaster is our proprietary distributed rendering system. It comprises Alfred, Pixar’s job distribution
product and a complex collection of propietary scripts, programs and databases. In Ringmaster we perform
all the offline renders and simulations for any given shot or sequence. The key aspect of this system
is the complete scriptability of the dependency between jobs and the capability to manage thousands
of render jobs at any given time. For example at the peak of Nemo production we had 3000 CPUs
running in our renderfarm and at the same time more than 10000 tasks were waiting to go. An interesting
design aspect of this systems is that only a single RIB for a given frame is created. To render an
individual element, we apply a RIB filter to accomplish per-element configurations like switching cameras,
render options and attributes and object visibility.
Production Process
To better describe how RenderMan is part of the Pixar pipeline, I'll divide our production process into
different categories where we take advantage of our rendering technology.
Geometric Modeling
This is the first phase of the production process that involves CG and RenderMan. As of today, we use
different 3rd party modeling packages to create our models with Maya the preferred tool. During the
construction and sculpting of the different surfaces (NURBS or Subdivision Surfaces) production TDs
rely heavily on preview renders for different types of feedback. Here a list of useful preview renderings
during geometric modeling:
Topology Checking
• Bad polygonal mesh topology won't render properly
• Simple UV shader can display NURBs orientation
• Normals properly set and consistent across several meshes
Curvature Checking
• Subdivision surface limit surface curvature only visible in a render
• Simple curvature shaders for NURBs curvature display
Surface Shading assignment
• Using special light shaders that turn unassigned objects bright red
Director's Review
• Single frame or animation (turntable) for director's review
Procedural Modeling
For complex procedurals models like hair or particles, we take advantage of the RiProcedural functionality
available in the renderer. RiProcedural DSOs (Dynamic Shared Objects) are modules of compiled
C code linked inside the renderer at runtime. Those modules are very powerful since they allow the generation
of a large number of primitives within the rendering engine context. Inside the generation context
we can also take advantage of Level of Detail information like image size, camera distance and onscreen
coverage of the generated primitives. The disadvantages of using DSOs are mainly in the fact
that a bug in the module can crash the entire render. Also extra attention has to be paid in a multiplatform
environment like our studio. We define search paths in the RIB file to be platform independent
and use a combination of macro expansion ($ARCH) and RIB file filtering to ensure matching architecture
between the renderer and the modules and allow customization and versioning.
Shading
The shading process is performed in different environments. In Slim running in standalone mode, the
art department defines the material palette for a given model. In general we start from a simple Slim
appearance where basic properties like color, opacity, shininess, roughness, etc. are defined.
Sometimes a material palette can be simply a list of material names with a single RGB color associated.
The level of complexity of these materials may vary from model to model or from production to production.
For models built in 3rd party modelers and in particular for sets and props, we use Maya for the definition
of the various shaders and their binding with the objects. Here using MTOR and Slim, technical
directors import material and/or color palettes defined in the art departments and start creating Slim
shaders using the graphical UI. As part of the shading process, the surfaces can be parametrized with
scalar fields, UV sets and reference shapes.
During the shading process the TD has full access to lighting setups from different environments where
the model will be actually used. In particular cases, the lighting setup can be imported from specific
shots of the movie. After the "final" from the director, the model is converted into the Pixar animation
environment, Marionette for dressing, lighting and final rendering.
Characters and other complex deformable models are shaded primarily by custom shaders create with
a text editor and bound from within the Marionette environment.
Layout & Animation
Once models are built, shaded, and articulated, the production process moves entirely inside
Marionette. PRMan is used by both the layout and animation department for intermediate renders of
one or more shots.
For layout renders the system performs render tests of single frames and/or entire shots. The software
generates the RIB file for every frame and before rendering some filtering is performed on these files
to create "variants" based on user settings. For example, in layout renders we use some generic lighting
environment defined by basic lights attached to the camera and we replace all the shaders with a
simple surface shader. This speeds up the render time at the expense of quality. This trade off is
acceptable in layout as render quality is not critical when evaluating camera angles. Once the camera
is locked, a render of the background is performed to create an "image plane" with the set and props.
The animation department relies on similar rendering settings. They preview their animations using
either OpenGL renders or when detail is required or the models require simulations on PRMan renders.
Special FX
Special FX are performed either in Marionette or Maya depending on the shot complexity and requirements.
Particular attention has to be taken when mixing the two environments, especially when lighting
has to match the two plates.
Lighting and Film Rendering
Lighting and Film Rendering are the places where all the features are turned on and we get the maximum
complexity. In those departments, before submitting the final render, TDs writes complex
Ringmaster scripts and rules to create all the elements with the proper dependency analysis.
Film Rendering is also the most CPU and memory intensive renders so in Ringmaster we use all sort of
optimizations. For fast re-rendering on the desktop, we use a special pipeline that involve a pre-render
pass that compute what we call a "deep" file and then a re-render pass where Lumiere (an internal version
of Pixar’s Irma re-renderer) recomputes only the changes from the pre-render pass. This is
extremely useful for light tweaking and previewing. Another technique for accelerating the lighting
process requires per-light rendersto feed a custom application which performs pixel-based lighting
tweaks.
Conclusion
Over several years of continuous use, RenderMan has become a fundamental aspect of our production
pipeline. Understanding the RenderMan specifications and being able to write shaders is a must for
almost of every technical director at our studio. As we move forward with new features added to PRMan,
we are now in the process of improving our pipeline to take full advantage of new capabilities like ray
tracing, occlusion maps, global illumination and other new advanced features we are going to add in
the not-too-distant future.
Acknowledgements
The RenderMan pipeline at Pixar is the result of several years of hard work by lots of great people at
our studio, both from production and the Studio Tools department. In particular I’d like to thank Brad
West, Sanjay Bakshi and Dayiv Ryu for their contributions iin improving the Pixar shading pieline in the
last 18 months and to Wayne Wooten, Susan Fisher and Tony Apodaca, lead of the Film Render group,
for keeping the end of the pipeline, the final renders, under control during the production of Finding
Nemo. I’d like also to thank the engineers of the RenderMan Products group for the development of
MTOR and Slim and for the amzing work they are doing on PRMan."
Guido Quaroni, Pixar Animation Studios
guido@pixar.com
April, 2003
Introduction
The RenderMan Interface specification was published by Pixar at the end of the 80s and since the introduction
of a compliant renderer, at the beginning of the 90s, almost every single computer generated
image at Pixar has been computed by the same application, PhotoRealistic RenderMan (a.k.a. PRMan).
Today Pixar has completed the final renders of Finding Nemo, our fifth feature animation rendered
entirely using the same RenderMan compliant renderer. The architecture is pretty much the same but
the actual code has been improved and optimized over several years. This is one of the big strengths
of this software, it has been tested with complex scenes on different platforms. Pixar also sells PRMan
as part of the Rendering Artist Tools and this allows for even more use, testing and features.
Even if the underlying code is quite complex, running PRMan is pretty simple (although there’s no guarantee
it will produce a pretty picture). To be able to produce a picture, PRMan requires a RIB file, which
describes a scene and access to the resources specified in the RIB file like shaders and textures. The
three main environments where we access our renderer are Maya during modeling, shading and special
FX, Marionette during animation, layout and lighting, Ringmaster when we need distributed rendering
on the renderfarm like when computing final film frame. We also use command shell access to
PRMan for debugging, fixes and where we simply have a RIB file to render.
Pixar uses several computing platforms: SGI IRIX, Sun Solaris and Red Hat Linux. While we are phasing
out the IRIX OS, we are seriously looking at other attractive Unix-based alternatives. The renderer needs
to run on these platforms producing the same images from the same input data. In addition binary
modules used by the renderer must be compiled for the different platforms and made available to the
correct architecture that is running the renderer. This has been proven to be quite a challenging task
since there are subtle changes on the different architectures that must be taken into consideration. As
of today we use Linux boxes at the desktop and a combination of Linux and Sun Solaris machines in
the renderfarm.
Since we always use the same renderer (or at least for 99.99% of the shots rendered since Toy Story),
I assume that every mention to a renderer is actually PRMan and that every surface material or light is
a RenderMan compliant shader.
Working Environments (как раз то о чем шел разговор)
Pixar’s Artists and TDs interface with RenderMan from within 3 primary working environments: Maya,
Marionette and Ringmaster. In addition to these environments, we rely on specific tools for RIB generation
(MTOR), shader construction (Slim), RIB filtering (filterrib) and network rendering (Alfred). This
section will describe our pipeline to RenderMan from within each environment.
In Alias|Wavefront’s Maya we create RIB files using the MTOR plug-in. The file is then filtered with an
internal application called filterrib that allows us to modify any RIB statements using custom DSO
modules. For example, using filterrib we can add several custom RiOption and RiAttribute calls that
are specific to our internal pipeline. Shaders are authored via Slim. They can be generated on the fly
by Slim or they can be instances of existing ".slo" files. Using search paths, we allow MTOR renders to
access our shared assets like textures, shaders and archives.
Marionette is our proprietary animation system and within it we can perform PRMan renders at a number
of stages of its pipeline. The pipeline is similar to the Maya pipeline but differs in that shaders are
not built at render time and that the system performs RIB filtering prior to sending the render job to
Alfred.
Ringmaster is our proprietary distributed rendering system. It comprises Alfred, Pixar’s job distribution
product and a complex collection of propietary scripts, programs and databases. In Ringmaster we perform
all the offline renders and simulations for any given shot or sequence. The key aspect of this system
is the complete scriptability of the dependency between jobs and the capability to manage thousands
of render jobs at any given time. For example at the peak of Nemo production we had 3000 CPUs
running in our renderfarm and at the same time more than 10000 tasks were waiting to go. An interesting
design aspect of this systems is that only a single RIB for a given frame is created. To render an
individual element, we apply a RIB filter to accomplish per-element configurations like switching cameras,
render options and attributes and object visibility.
Production Process
To better describe how RenderMan is part of the Pixar pipeline, I'll divide our production process into
different categories where we take advantage of our rendering technology.
Geometric Modeling
This is the first phase of the production process that involves CG and RenderMan. As of today, we use
different 3rd party modeling packages to create our models with Maya the preferred tool. During the
construction and sculpting of the different surfaces (NURBS or Subdivision Surfaces) production TDs
rely heavily on preview renders for different types of feedback. Here a list of useful preview renderings
during geometric modeling:
Topology Checking
• Bad polygonal mesh topology won't render properly
• Simple UV shader can display NURBs orientation
• Normals properly set and consistent across several meshes
Curvature Checking
• Subdivision surface limit surface curvature only visible in a render
• Simple curvature shaders for NURBs curvature display
Surface Shading assignment
• Using special light shaders that turn unassigned objects bright red
Director's Review
• Single frame or animation (turntable) for director's review
Procedural Modeling
For complex procedurals models like hair or particles, we take advantage of the RiProcedural functionality
available in the renderer. RiProcedural DSOs (Dynamic Shared Objects) are modules of compiled
C code linked inside the renderer at runtime. Those modules are very powerful since they allow the generation
of a large number of primitives within the rendering engine context. Inside the generation context
we can also take advantage of Level of Detail information like image size, camera distance and onscreen
coverage of the generated primitives. The disadvantages of using DSOs are mainly in the fact
that a bug in the module can crash the entire render. Also extra attention has to be paid in a multiplatform
environment like our studio. We define search paths in the RIB file to be platform independent
and use a combination of macro expansion ($ARCH) and RIB file filtering to ensure matching architecture
between the renderer and the modules and allow customization and versioning.
Shading
The shading process is performed in different environments. In Slim running in standalone mode, the
art department defines the material palette for a given model. In general we start from a simple Slim
appearance where basic properties like color, opacity, shininess, roughness, etc. are defined.
Sometimes a material palette can be simply a list of material names with a single RGB color associated.
The level of complexity of these materials may vary from model to model or from production to production.
For models built in 3rd party modelers and in particular for sets and props, we use Maya for the definition
of the various shaders and their binding with the objects. Here using MTOR and Slim, technical
directors import material and/or color palettes defined in the art departments and start creating Slim
shaders using the graphical UI. As part of the shading process, the surfaces can be parametrized with
scalar fields, UV sets and reference shapes.
During the shading process the TD has full access to lighting setups from different environments where
the model will be actually used. In particular cases, the lighting setup can be imported from specific
shots of the movie. After the "final" from the director, the model is converted into the Pixar animation
environment, Marionette for dressing, lighting and final rendering.
Characters and other complex deformable models are shaded primarily by custom shaders create with
a text editor and bound from within the Marionette environment.
Layout & Animation
Once models are built, shaded, and articulated, the production process moves entirely inside
Marionette. PRMan is used by both the layout and animation department for intermediate renders of
one or more shots.
For layout renders the system performs render tests of single frames and/or entire shots. The software
generates the RIB file for every frame and before rendering some filtering is performed on these files
to create "variants" based on user settings. For example, in layout renders we use some generic lighting
environment defined by basic lights attached to the camera and we replace all the shaders with a
simple surface shader. This speeds up the render time at the expense of quality. This trade off is
acceptable in layout as render quality is not critical when evaluating camera angles. Once the camera
is locked, a render of the background is performed to create an "image plane" with the set and props.
The animation department relies on similar rendering settings. They preview their animations using
either OpenGL renders or when detail is required or the models require simulations on PRMan renders.
Special FX
Special FX are performed either in Marionette or Maya depending on the shot complexity and requirements.
Particular attention has to be taken when mixing the two environments, especially when lighting
has to match the two plates.
Lighting and Film Rendering
Lighting and Film Rendering are the places where all the features are turned on and we get the maximum
complexity. In those departments, before submitting the final render, TDs writes complex
Ringmaster scripts and rules to create all the elements with the proper dependency analysis.
Film Rendering is also the most CPU and memory intensive renders so in Ringmaster we use all sort of
optimizations. For fast re-rendering on the desktop, we use a special pipeline that involve a pre-render
pass that compute what we call a "deep" file and then a re-render pass where Lumiere (an internal version
of Pixar’s Irma re-renderer) recomputes only the changes from the pre-render pass. This is
extremely useful for light tweaking and previewing. Another technique for accelerating the lighting
process requires per-light rendersto feed a custom application which performs pixel-based lighting
tweaks.
Conclusion
Over several years of continuous use, RenderMan has become a fundamental aspect of our production
pipeline. Understanding the RenderMan specifications and being able to write shaders is a must for
almost of every technical director at our studio. As we move forward with new features added to PRMan,
we are now in the process of improving our pipeline to take full advantage of new capabilities like ray
tracing, occlusion maps, global illumination and other new advanced features we are going to add in
the not-too-distant future.
Acknowledgements
The RenderMan pipeline at Pixar is the result of several years of hard work by lots of great people at
our studio, both from production and the Studio Tools department. In particular I’d like to thank Brad
West, Sanjay Bakshi and Dayiv Ryu for their contributions iin improving the Pixar shading pieline in the
last 18 months and to Wayne Wooten, Susan Fisher and Tony Apodaca, lead of the Film Render group,
for keeping the end of the pipeline, the final renders, under control during the production of Finding
Nemo. I’d like also to thank the engineers of the RenderMan Products group for the development of
MTOR and Slim and for the amzing work they are doing on PRMan."
но George прав...
Многие поуезжали. Олег Байбородин в Штатах продолжает то, чем был занят в России, и "максисты" его работу знают.
Миша Ляпунов, один из ведущих спецов по рендерингу, OpenGL и DirectX, насколько я знаю, в Microsoft.
Леша Пажитнов, автор "Тетриса", тоже в Штатах. Вице-президентом Silicon Graphics, Inc. (те самые "Силиконы"!) был Эдик Талныкин, один из первопроходцев компьютерной графики еще в СССР.
Кажись, там же - Антон Чижов (по крайней мере, несколько его проектов реализованы в Штатах).
Какой смысл теперь что-то искать в России?
Тогда, когда приезжали сюда Кэтмулл, Бейли, основатель Silicon Graphics, Inc. Кларк, Гудрич и другие, в стране что-то привлекательное для них происходило, были научные школы, были интересные разработки. С Кэтмуллом я обсуждал возможность создания совместного предприятия или совместного проекта.
Все. Просто кончилось интересное время.
Сейчас-то что Кэтмуллу здесь делать?
Многие поуезжали. Олег Байбородин в Штатах продолжает то, чем был занят в России, и "максисты" его работу знают.
Миша Ляпунов, один из ведущих спецов по рендерингу, OpenGL и DirectX, насколько я знаю, в Microsoft.
Леша Пажитнов, автор "Тетриса", тоже в Штатах. Вице-президентом Silicon Graphics, Inc. (те самые "Силиконы"!) был Эдик Талныкин, один из первопроходцев компьютерной графики еще в СССР.
Кажись, там же - Антон Чижов (по крайней мере, несколько его проектов реализованы в Штатах).
Какой смысл теперь что-то искать в России?
Тогда, когда приезжали сюда Кэтмулл, Бейли, основатель Silicon Graphics, Inc. Кларк, Гудрич и другие, в стране что-то привлекательное для них происходило, были научные школы, были интересные разработки. С Кэтмуллом я обсуждал возможность создания совместного предприятия или совместного проекта.
Все. Просто кончилось интересное время.
Сейчас-то что Кэтмуллу здесь делать?