1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

В чем делали Toy Story

Тема в разделе "Графика в фильмах", создана пользователем McST, 9 фев 2004.

Модераторы: Артер
  1. McST

    McST Знаток

    С нами с:
    01.06.2002
    Сообщения:
    609
    Симпатии:
    1
    Баллы:
    28
    и вобще в чем пиксаровцы работли до того как появилась Майя и все остальные проги что они юзали
     
  2. Guest

    Полагаю что они юзали ТриДэ Макс.....так как до появления Майа и всех отсальных прог , как ты выразился был только ТриДэМакс.
    И видимо они эти пиксаровци доморощеные его и юзают и сейчас и будут юзать его пока незаюзают до конца до самого... это самый ТриДэМакс.
    Удачи.
     
  3. Guest

    " ... вначале было Слово, и это слово было ТриДэМакс ...из него сотворили 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 про Жанну Д'Арк ... " .... вот , собственно, с чего всё началось .... да ...
     
  4. Guest

    Зверинец, б..))
     
  5. Guest

    Да у них, кажется, свой софт ин-хауз... Весьма продвинутый и удобный, если судить по отрывочным кадрам различных мэйкин оф..
     
  6. Guest

    всеже ТриДэЭСМакс... :p
     
  7. Guest

    Да, ЭфОдин прав.

    У них свой софт. И тогда был, и сейчас.
    Если крупная студия рассказывает, что у них стоит Майя, не думайте, что она такая же, как у вас. Там производство поделено на много департментов, каждый решает свою задачу, а софтверный отдел по ходу под конкретные задачи дописывает, переписывает и меняет софт.

    Предшественника 3D Max - Autodesk 3D Studio(или как его там) никто за реальный соф не считал, но в те времена(лет ~10 назад) кроме инхаузного софта были Softimage, Alias PowerAnimator и Wavewfront, которые работали исключительно на силиконах.
     
  8. Guest

    Marionette
     
  9. Guest

    На сколько я помню, у Pixar свой софт под названием - RenderMan, который они продают.
     
  10. Guest

    Некоторые наработки, которые вошли в Toy Story или были использованы там впрямую как технологии, Pixar привозил в Москву еще в 90-м году и показывал
    Более подробное сообщение Эд Кэтмулл (президент Pixar) сделал в 1991-м, опять же в Москве.
    В 1993-м, в Питере, вместе с главой Xaos Tools, была исполнительный продюсер Toy Story, которая рассказывала о Marionette, но не как о софте, а как о технологии.

    В общем, сперва это была внутренняя работа Pixar с использованием собственных разработок.
    Точно также, как и знаменитые "Люксо-мама и Люксо-сын". Это была изначально научно-поисковая работа, о которой в Computer Graphics World и других сугубо специальных журналах были даны статьи, там описывались кинематика объектов, свойства и описание поверхностей и т.д. Так, например, лампы совершали "тяжелые прыжки", "легкие прыжки", "прыжки с трамплина" (что вообще не вошло в ролик про "Люксо").

    Как забавное дополнение, могу сказать, что Эд Кэтмулл был слегка шокирован использованием без спроса его семейки Люксо в качестве заставке к передаче. Но когда мы ему сказали, чо передача для детей, и она некоммерческая, он успокоился :)))
     
  11. Guest

    А сейчас представителей Pixar можно застать на каких нибудь выставках или семинарах в России? Интересно было бы послушать... да и посмотреть.
     
  12. Guest

    Сейчас нет "никакого" интереса у мист. Кэтмулла приезжать в Россию.
    Впрочем как и у других серьезных спецов.
     
  13. Akhvlediani

    Akhvlediani Пользователь сайта

    С нами с:
    06.12.2001
    Сообщения:
    26
    Симпатии:
    0
    Баллы:
    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."
     
  14. Guest

    но George прав...
    Многие поуезжали. Олег Байбородин в Штатах продолжает то, чем был занят в России, и "максисты" его работу знают.
    Миша Ляпунов, один из ведущих спецов по рендерингу, OpenGL и DirectX, насколько я знаю, в Microsoft.
    Леша Пажитнов, автор "Тетриса", тоже в Штатах. Вице-президентом Silicon Graphics, Inc. (те самые "Силиконы"!) был Эдик Талныкин, один из первопроходцев компьютерной графики еще в СССР.
    Кажись, там же - Антон Чижов (по крайней мере, несколько его проектов реализованы в Штатах).

    Какой смысл теперь что-то искать в России?
    Тогда, когда приезжали сюда Кэтмулл, Бейли, основатель Silicon Graphics, Inc. Кларк, Гудрич и другие, в стране что-то привлекательное для них происходило, были научные школы, были интересные разработки. С Кэтмуллом я обсуждал возможность создания совместного предприятия или совместного проекта.
    Все. Просто кончилось интересное время.
    Сейчас-то что Кэтмуллу здесь делать?
     
  15. Guest

    Вице-президентом SGI был Степан Пачиков, а Эдик - одним из топ-менеджеров, но тоже с неплохим окладом:)))
     
  16. Guest

    -"Папа, а чего мы в этой куче дерьма делаем?"
    -"Это наша Родина, сынок"

    А вообще, по-хорошему, "... за державу обидно".
     
  17. Guest

    Ничего, будет и на нашей улице праздник!!!
    По крайней мере я на это надеюсь....
     
  18. Guest

    Просто надо работать! А там будет видно....
     
  19. Guest

    Да ладно вам сокрушацца-то ! Поруччик прав - и праздник будет(и не один), и работать нужно. Народ импортный начнёт подтягивацца...блудные сыны комп. графики...Эх заживё-е-е-м !
     
  20. Guest

    Если уж на то пошло - среди старожилов Pixar'a тоже наш человек есть, который на "Toy Story" работал.
     
Модераторы: Артер

Поделиться этой страницей