O Linux naufragou o Titanic

O Titanic foi o primeiro longa metragem produzido em Hollywood a ser renderizado no Linux! Conheça mais detalhes desse sucesso!

---

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

---

1. Digital Domain

1.1 Series

Temos muitas séries que utilizaram de tecnologia da Digital Domain para renderizar suas produções! , entre os títulos mais recentes até a data desta publicação temos:

• Dark Matter
• Ahsoka
• Black Mirror (Temporada 6)
• The Mandalorian (Temporada 3)
• The Last of Us (Temporada 1)
• Stranger Things (Temporada 4)
• Wandavision

Entre muitas outras!

1.2 Filmes

O cinema está bem servido de filmes renderizados no Linux, entre os títulos mais recentes até a data desta publicação temos:

• Pantera Negra: Wakanda para Sempre
• Adão Negro
• Animais Fantásticos: Os Segredos de Dumbledore

Também destaco as franquias:

• Vingadores
  E demais filmes da Marvel!
• Homem-Aranha, do universo Marvel:
  De Volta ao Lar, Longe de Casa, Sem Volta para Casa
• Piratas do Caribe
• Senhor dos Anéis
• Harry Potter
• Shrek
  

Clique aqui e veja a lista completa! 

Todos estes, dos estúdios da Digital Domain, em Venice, na Califórnia, Estados Unidos.  E esta empresa foi a escolhida, à época, para gerar os efeitos especiais do Titanic.

Conheça agora os detalhes técnicos de sua complexa e difícil produção!

2. O Navio

O RMS Titanic, o fabuloso navio de passageiros que naufragou em 15 de Abril de 1912, encantou gerações, uma vez que à época era o mais luxuoso e tido como “inafundável”.

Sua história dramática foi retratada em diversos filmes, mas o mais icônico é o filme homônimo do diretor de cinema James Cameron, indo ao ar na grande tela em Dezembro de 1997.

Cena do filme “Titanic” de 1997: Cena renderizada por computação gráfica!

Tamanho sucesso de bilheteria rendeu uma verdadeira legião de fãs do navio mundo afora. E não apenas nas telas ele faz sucesso, como no mundo dos games também!

2.1 Um Game

A quem estiver interessado em rever como foi o naufrágio do mesmo, teremos esta noite – esta publicação será lançada à tarde – a demonstração em tempo real reproduzida na Unreal Engine 5.1, baseada no game Titanic: Honor and Glory.

Essa demonstração terá 2 horas e 40 minutos, mostrando todo o processo em detalhes precisos de tempo: da viagem ao incidente com o iceberg e o inevitável naufrágio.

Mérito à talentosa equipe que detalhou absurdamente cada parte do navio!
O site oficial do game se encontra aqui.

A respeito do vindouro game, que até então segue apenas com uma demonstração disponível, teremos o navio reconstruído por completo, digitalmente com um gráfico soberbo, permitindo que você ande por cada setor do navio – do convés á área das caldeiras – em alta definição e ao fim, vivencie na pele como foi seu polêmico naufrágio:

A quem desejar e interessar, a demonstração executa muito bem sob o WINE na versão mais recente 8.5 Staging. Não há necessidade de muitas modificações, bastando que você possua um hardware nas configurações mínimas para abri-lo:

Processador Intel Core i7 CPU ou melhor, de até 3.5Ghz
Pelo menos 8 Gb de RAM
GPU Mínima AMD RX 550 ou NVIDIA GTX 1050 com pelo menos 4 Gb de VRAM
50 Gb de espaço livre total para baixar, extrair e jogar última demo que é 50% do navio modelado: Projeto 401 V2

Alguns prints que tirei em meus testes:

Aos fãs da história do navio, é um prato cheio!

3. O Efeito Dramático

A galera por trás dos efeitos do filme sofreram de dramas diversos como os vividos por Jack e Rose.

Quando o filme estava em produção sofreu vários tipos de problemas, tendo em vista os custos do UNIX® licenciado, as limitações do Windows NT e da imaturidade do Linux.

4. Produção

4.1 A Tarefa

A ordem de James Cameron era simples: Criar um filme do Titanic, que fosse dramático e usando em seu tempo o que tinha de bom e barato em efeitos especiais. Mas claro que essa tarefa não seria das mais simples e houve um extenso trabalho, seja pra decidir o que seria feito, como, qual o melhor hardware, etc.

Para muitas cenas geradas com efeitos digitais, as imagens fotográficas originais foram capturadas primeiro em filme – usando métodos cinematográficos convencionais com as câmeras e atores – e depois digitalizadas no computador. Cada quadro de filme é armazenado como um arquivo separado em um servidor de arquivos central. Na época esse servidor tinha aproximadamente 5 Terabytes.

Vários artistas digitais começam então a trabalhar nas cenas. O trabalho pode envolver a criação de elementos totalmente novos, como a animação e a renderização de modelos 3D ou a modificação de elementos existentes, como pintar um fio ou isolar as áreas de interesse do filme original. Basicamente não percebemos mas diversas cenas do filme foram compostas de “uma colcha de retalhos” de cenas capturadas em momentos diferentes.

Uma réplica do Titanic foi construída pela metade. Ela possuía interiores e afundava mecanicamente graças a guindastes. Nas cenas em que os personagens corriam por suas vidas no interior do navio enquanto a água estava entrando, deveras era água salgada e o navio réplica estava realmente afundando!

Este trabalho é feito na área de trabalho do artista – geralmente em uma estação de trabalho SGI ou NT. Uma vez que a configuração para este trabalho é feita, o processo é repetido para cada quadro do filme. Esse processamento em lote é feito em todas as CPUs disponíveis na instalação, geralmente em paralelo e requer um sistema de arquivos distribuído e uma visão geral uniforme dos dados. Uma meta desse processamento é permanecer independente da plataforma sempre que possível.

Como a construção de um modelo em escala real do Titanic teria sido proibitivamente cara, apenas uma parte do navio foi construída em tamanho maior e miniaturas foram usadas para outras cenas.

Miniatura construída para recriar a cena em que ele, após partir ao meio, naufraga de pé!

As pessoas em perigo na cena em que o navio fica totalmente em pé após partir ao meio, foi produzida com a ajuda de uma popa falsa em estúdio.

4.2 Renderizando o Titanic

A esses modelos miniatura do Titanic, posteriormente após serem gravados, foram adicionados outros elementos na cena, como o oceano, as pessoas, pássaros, fumaça e outros detalhes que fazem o modelo parecer ancorado, navegando ou posteriormente naufragando no oceano.

Para isso, construíram um modelo do Titanic (foto acima) e fotografaram elementos 2D diversos para simular fotografias subaquáticas, aéreas e terrestres. Adicionando a isso algumas renderizações geradas digitalmente; o resultado dessa “salada” você vê neste vídeo, divulgado pela própria Digital Domain:

As diversas composições formam a cena completa: Pessoas em um plano, água e fumaça renderizados digitalmente, a miniatura do navio, cada pedacinho unido como uma grande e bela colcha de retalhos.

5. Os Computadores

Durante o trabalho nos efeitos do filme Titanic, o complexo sistema de renderização tinha aproximadamente 350 CPUs SGI, 200 CPUs DEC Alpha e 5 terabytes de disco, todos conectados por uma rede de 100 Mbps ou mais rápida. Mais abaixo os detalhes de como isso tudo funcionava!

CPU SGI

5.1 A Análise:

Qual o melhor Hardware?

O objetivo dos desenvolvedores nesse meio é sempre criar imagens da mais alta qualidade dentro de restrições financeiras e de cronograma. A criação de imagens é realizada em duas fases. Na primeira fase, o artista digital trabalha em uma estação de trabalho interativa utilizando pacotes de software específicos e sofisticados e hardware específico de alto desempenho. Durante a segunda fase, o trabalho é processado no modo de lote no maior número possível de CPUs, independentemente do local ou recursos, para melhorar o desempenho interativo

É difícil melhorar essa primeira fase interativa. Os artistas digitais exigem certos pacotes e programas que nem sempre estão disponíveis em outras plataformas. Mesmo que pacotes semelhantes estejam disponíveis, há um custo significativo associado à interoperação entre eles. Outro problema é que alguns dos pacotes exigem certa aceleração de hardware high-end (geralmente 3D). Essa mesma qualidade e desempenho de aceleração 3D podem não estar disponíveis em outras plataformas.

Logo concluíram que os sistemas baseados no DEC Alpha atendiam muito bem às necessidades de processamento em lote, porque forneciam desempenho extremamente alto em ponto flutuante em embalagens de commodities. Os sistemas Alpha podiam ser configurados com grandes quantidades de memória e rede rápida a preços atraentes. No geral, o DEC Alpha apresentou a melhor relação custo benefício para as necessidades da equipe de produção.

CPU DEC Alpha

5.2 Qual Sistema Operacional Usar?

A próxima pergunta que se fizeram foi qual sistema operacional usar. Eles tinham algumas opções:

• Windows NT
• DEC UNIX (mais conhecido como Tru64)
• Linux

Sabiam quais programas precisavam executar nos sistemas, então montaram sistemas de cada tipo e avaliaram sua adequação às várias tarefas que precisavam para essa produção.

1. O Windows NT teve vários problemas. Primeiro, os aplicativos padrão, que normalmente são executados em hardware SGI, não estavam disponíveis no NT. A equipe de software poderia portar as ferramentas, mas essa solução seria muito cara. O NT também teve várias outras limitações; ele não suportava um automounter, NFS ou links simbólicos, todos críticos para a arquitetura de armazenamento distribuído. Haviam aplicativos de terceiros disponíveis para preencher alguns desses buracos, mas eles aumentariam os custos e, em muitos casos, não teriam bom desempenho no tratamento das necessidades gerais de computação.
2. O Digital UNIX funcionou muito bem e se integrou perfeitamente ao ambiente. As maiores limitações dele no entanto foram os altos custos das licenças e a falta de flexibilidade. Estariam comprando e reconfigurando um grande número de sistemas. Comprar separadamente o Digital UNIX para cada sistema seria demorado e caro. O Digital UNIX também não possuía certas extensões necessárias e não poderia fornecê-las em um prazo aceitável. Por exemplo, precisavam comunicar com os servidores de arquivos baseados em NT, conectar duas variedades incomuns de unidades de fita e permitir um grande número de usuários em um único sistema; nada disso era suportado pelo Digital UNIX.
3. O Linux cumpriu a tarefa muito bem. Ele lidou com todos os trabalhos que fizeram. Durante a fase de testes, usaram a capacidade de emular os aplicativos do Digital UNIX para comparar aplicativos padrão e mostrar que seu desempenho atenderia às suas necessidades. A flexibilidade dos dispositivos existentes e o código fonte disponível deram ao Linux uma vantagem definitiva.

A desvantagem do Linux foi o esforço de engenharia necessário para suportá-lo. Sabiam que precisavam dedicar um engenheiro para dar suporte a esses sistemas durante a configuração deles. Felizmente, haviam engenheiros com experiência anterior significativa com o Linux em sistemas Intel  e experiência suficiente no sistema Unix para fazer as modificações necessárias. Testaram cuidadosamente uma variedade de hardwares para garantir que todos fossem totalmente compatíveis com o Linux.

5.3 Software

A distribuição Linux escolhida foi o Red Hat Enterprise Linux 4.1. Naquela época, o Red Hat rodava sob o kernel Linux 2.0.18, que inicialmente não suportava a mainboard PC164 – um dos diversos hardwares do sistema servidor -, então a primeira coisa que tiveram que fazer foi atualizar o kernel para contemplar os drivers ausentes.

Mainboard PC 164: Parte do hardware que renderizou o Titanic!

Durante vários testes, rastrearam vários problemas com dispositivos e mantiveram os kerneis das séries 2.0 e 2.1. Acabaram ficando com o 2.1.42 com alguns patches. Também decidiram pela placa SCSI NCR 810 (disco rígido) com o driver baseado no BSD e a placa Ethernet SMC 100MB, sob o driver de4x5.

Acabou sendo uma configuração muito estável, mas houve um sério problema de ponto flutuante: Dado momento, o software de renderização de água parou inesperadamente com uma exceção (kernel panic!). Solucionar o problema foi um tanto custoso, mas foi resolvido sem prejuízos ao prazo de produção e lançamento do filme.

Na época, nem James Cameron escapou de ver uma tela preta da morte do Linux, conhecida como Kernel Panic!

Felizmente hoje em dia elas são mais raras devido á maturidade do sistema em lidar com diversos hardwares e/ou problemas internos.

5.4 Implementação

Neste ponto, foi tomada a decisão de comprar 160 sistemas DEC Alpha de 433 MHz da Carrera Computers, de Newport Beach, Califórnia. Dessas 160 máquinas, 105 delas estavam rodando Linux, as outras 55 estavam executando o NT. As máquinas eram conectadas com Ethernet de 100 Mbps entre si e ao resto das instalações.

A equipe Carrera foi extraordinariamente útil e forneceu inestimável apoio ao projeto. Esse suporte começou na fábrica, com assessoramento total, seja por meio de entrega, suporte técnico ou reparo.

A equipe do filme Titanic criou um disco mestre, fornecido pela Carrera, que criou um único script de inicialização que configuraria o disco mestre genérico para cada um dos 160 clientes, configurando parâmetros como o nome do sistema e o endereço IP. A Carrera forneceu, construiu, configurou e gravou uma máquina servidora; depois logou como um usuário especial fazendo com que o script de configuração fosse executado. Quando o script foi concluído, a máquina desligou automaticamente. – Uau!

Este processo facilitou a configuração das máquinas tanto para Carrera como para os desenvolvedores do estúdio. Quando os computadores clientes chegaram, bastou apenas conectarem e ligarem o botão Power, e eles se conectaram na rede de forma basicamente automática.

Todas as 160 máquinas estavam alojadas em uma pequena sala na Digital Domain em dez raques de 19 polegadas. Eles estavam conectados a uma tela central, teclado e mouse por meio de um sistema de comutação – famoso hardware KVM – para permitir que um operador se sente no meio da sala e trabalhe no console de qualquer máquina nela.

5.5 O Laboratório de Informática

A sala foi montada em um período de duas semanas, incluindo a instalação do sistema elétrico, de computação e de rede. O tempo gasto na criação do script de inicialização foi extremamente bem aproveitado, pois permitiu que as máquinas fossem liberadas com relativamente poucos problemas. Nesse ponto, começaram a executar o trabalho do Titanic através do “Render Ranch” dos sistemas Alpha’s.

A primeira parte do trabalho foi simular e renderizar os elementos da água. Sabiam que a água era a parte computacionalmente mais cara, então esse processo foi uma das principais razões para se comprar os Alphas.

Essa tarefa foi computada por aproximadamente 45 minutos e, em seguida, geraram várias centenas de megabytes de dados de imagem para serem armazenados nos servidores de armazenamento central. Dados intermediários foram armazenados no disco SCSI local dos Alphas. O poder de ponto flutuante do DEC Alpha fez com que as tarefas rodassem cerca de 3,5 vezes mais rápido do que nos antigos sistemas SGI que o estúdio usava anteriormente!

Quando a renderização de água foi concluída, a carga de tarefas passou para a composição. Esses trabalhos eram mais vinculados a E/S, porque precisavam ler elementos de discos em servidores espalhados pela instalação e combiná-los em quadros para serem armazenados centralmente. Mesmo assim, ainda viram melhorias de um fator de dois para essas tarefas.

Todos ficaram extremamente satisfeitos com os resultados. Entre o início de junho e o final de agosto de 1995, os sistemas Alpha rodando Linux processaram mais de trezentos mil quadros do filme. Os sistemas estavam funcionando 24 horas por dia, sete dias por semana. Não houve longos períodos de inatividade e muitas das máquinas ficaram funcionando por mais de um mês de cada vez.

6. Problemas

Alguns dos problemas eram específicos do Alpha, e alguns eram problemas do Linux em geral.

Compatibilidade de hardware, particularmente com o Alpha sob Linux, ainda foi um problema comum ao longo do tempo de gravação e edição do filme. A Carrera foi muito cooperativa em enviar várias variedades de cartões de sistema, para que pudessem fazer testes extensivos. A gama de escolhas era grande o suficiente para que pudessem encontrar uma combinação que funcionasse.

Tiveram que prestar muita atenção em quais produtos estavam usando, já que a revisão específica do chip fez diferença em alguns casos.

O problema do ponto flutuante (discutido acima) foi o problema mais difícil que tiveram de resolver. Este foi um bug de longa data que nunca havia sido rastreado – atribuíram esse fato à relativamente pequena comunidade em manter drivers do hardware Alpha no Linux, lembrando, um sistema tão jovem para a época ante os maduros UNIX e o NT.

Tiveram vários pequenos problemas de configuração em relação ao tamanho das instalações. A maioria deles foram apenas mudanças de parâmetros no kernel, mas eles deram trabalho para rastrear. Por exemplo, tiveram que aumentar o número de sistemas de arquivos montados simultaneamente (64 não era suficiente). Além disso, esperava-se que as leituras do diretório NFS coubessem dentro de uma página (4K na Intel, 8K na Alpha); Tiveram que dobrar esse número para suportar o número médio de quadros armazenados em um único diretório.

O gerenciamento de inicialização no Linux Alpha foi mais difícil do que gostariam. Sentiram que a documentação precisava de melhorias para torná-la mais fácil. O gerenciamento de inicialização exigia amplo conhecimento de ARC, MILO e Linux para que funcionasse. O ARC exige a entrada de uma quantidade razoavelmente grande de dados para que o MILO seja inicializado. O MILO funcionou bem e forneceu um bom conjunto de opções, mas nunca conseguiram reinicializações suaves para operar corretamente. Tiveram trabalhando com engenheiros da DEC para melhorar alguns desses problemas.

O elo mais fraco no kernel Linux parecia ser a implementação do NFS, resultando na maioria das falhas do sistema. Geralmente, tem-se um grande número de sistemas de arquivos montados simultaneamente, e esses sistemas de arquivos costumavam estar sob carga pesada. Quando os servidores centrais caíam ou tiveram problemas, os sistemas Linux não se recuperavam. Os sintomas comuns desses problemas eram NFS em versões obsoletas e o kernel travando causando alguns kernel panic!. Quando todos os servidores estavam em execução, as caixas do Linux funcionavam corretamente. No geral, a implementação do NFS funcionou, mas deveria ser mais robusta e foi um ponto fraco á época.

7. Finalização do filme Titanic!

Os sistemas Linux funcionaram incrivelmente bem para sanar os problemas e necessidades da produção do filme. O custo-benefício foi esmagadoramente positivo, inclusive incluindo os recursos de engenharia que dedicaram a sanar os problemas do processo de produção. As máquinas Alpha sob Linux acabaram sendo um pouco mais difíceis de configurar do que se esperava, mas o estado do Alpha sob Linux estava melhorando muito rapidamente e valeu a pena o esforço.

A Digital Domain continuou a melhorar e expandir as ferramentas que tinha-se disponíveis nesses sistemas. Estavam gerindo o desenvolvimento de aplicativos mais comerciais e internos disponíveis no Linux. Na verdade, os sistemas Linux foram usados ​​apenas para processamento em lote, mas esperava-se que o software de composição fosse usado interativamente por mais artistas digitais. Este software não requeria hardware de aceleração dedicado, e a velocidade fornecida pelo processador Alpha foi um grande benefício para a produtividade.

O desenvolvimento de filmes de longa metragem e efeitos visuais de televisão proporcionou um campo de testes de alto desempenho e de baixo custo graças ao Linux. Acreditamos que a natureza de propósito geral da plataforma, juntamente com a precificação de commodities, oferece ampla aplicação em áreas diversas, não apenas no cinema. O baixo custo de entrada, versatilidade e interoperabilidade do Linux é suficientemente atraente para garantir um investimento, experimentação e implementação mais extensas; motivo mais do que suficiente para se perceber um domínio do Linux nos grandes estúdios de cinema!

8. Conclusão

Todo o “sofrimento” durante a produção do filme á época rendeu muita experiencia, firmando o Linux como a base para as produções posteriores. Tanto que a lista de filmes renderizados com Linux – que não é pequena e muitos são sucesso de bilheteria – só aumenta cada dia mais. Adiciona-se a isso o fator da OSCAR’s ter entrado pra Linux Foundation, então mais estúdios aderiram ao software livre e gratuito.

#UrbanCompassPony

Fontes:
Depoimentos: Linux Journal
Arte de Chamada: Sputnik News
História: Wikipedia
Arte Secundária: Globo
Linux em Hollywood