OpenUSD 26.11: registo de autoria dos objetos da cena, compressão de malhas PMC e composição mais rápida

A Alliance for OpenUSD anunciou o OpenUSD 26.11 e descreveu as principais capacidades da versão. O formato passa a ter uma forma oficial de registar quem criou cada objeto da cena: um artista à mão, uma exportação de um pacote DCC ou um passo de IA generativa. Para os estúdios que já misturam trabalho manual e dados gerados num mesmo asset, trata-se de um mecanismo padrão de registo da proveniência dentro do próprio ficheiro, sem tabelas externas nem metadados de pipeline.

O segundo grande tema da versão é o desempenho. A Pixar mediu a aceleração da composição em várias cenas de produção. Para quem transfere geometria pesada pela rede, o OpenUSD passa a suportar o codec aberto de compressão de malhas PMC.

De quem é este prim

O novo esquema de autoria é acoplado a um prim e guarda um registo de quem ou do que o criou: o programa e a sua versão, os participantes, o tipo de origem, os dados de entrada e a hora de criação. Um mesmo objeto pode ter vários registos. Por exemplo, uma personagem foi gerada por uma rede neuronal, depois foi retocada por um modelador e, em seguida, o asset passou por uma exportação de outro pacote. Cada um destes passos guarda o seu próprio registo. A autoria também se acumula a partir dos objetos pai, pelo que um prim transporta o contexto da sua hierarquia juntamente com os seus próprios registos.

Estes registos podem ser consultados com a nova ferramenta usdauthors, tanto para a cena inteira como para uma camada específica. Os desenvolvedores de pipeline recebem uma interface de programação para as mesmas consultas. Se, antes da entrega do projeto, um cliente perguntar que assets foram tocados pela IA, a resposta poderá ser procurada no próprio ficheiro — desde que os registos tenham sido escritos nele.

Composição mais rápida, Hydra mais contida

A composição já não copia nós que depois acabam igualmente descartados. Uma otimização separada diz respeito à compilação da própria biblioteca: segundo as medições da Pixar, ficou mais curta no Visual Studio e no Xcode, enquanto no GCC o tempo de compilação praticamente não mudou.

«A Pixar reporta uma aceleração da composição de 10–30 por cento em várias cenas de produção».

É assim que o resultado é descrito no blogue da Alliance for OpenUSD. Aí também se ressalva que as medições se referem a cargas concretas e que o resultado depende da estrutura da cena e da configuração da compilação. A título de comparação: na versão da primavera 26.05, a otimização da composição dava cerca de 8% de poupança de memória em cálculos específicos em planos de teste e 17% num dos relatórios. O ganho atual refere-se à velocidade.

O Hydra, a camada que entrega a cena ao viewport e aos render delegates, aprendeu a partilhar dados constantes idênticos entre objetos relacionados. Num teste com uma multidão de personagens esqueléticas, montado a partir de uma cena de produção, o consumo de memória do Hydra caiu 25%. Em cenas grandes também vão ajudar o percurso paralelo da seleção, a atualização em lote do point-instancer e a descarga opcional da cache do índice de cena.

Há também uma nova configuração para as instâncias: é possível expandir uma instância na representação de render para que os filtros de cena subsequentes trabalhem com a sua hierarquia, mantendo-se o instancing no próprio USD tal como estava.

Compressão de malhas PMC

O OpenUSD acrescenta suporte para o Polygonal Mesh Coding (PMC), um codec do grupo de trabalho Volumetric Visual Media da Alliance for Open Media. Com ele surgem um plugin de formato para malhas comprimidas e a ferramenta de consola usdcrush, que converte as malhas de uma cena USD. Na avaliação da AOUSD, isto dá às equipas que distribuem assets ricos em geometria uma forma de reduzir o volume de armazenamento e de transferência das malhas. O componente é opcional e está desativado no script de compilação padrão, pelo que, ao compilar o OpenUSD, tem de ser ativado em separado.

Storm: backplates e superfícies implícitas

Na 26.08, lançada a 20 de julho de 2026, surgiram os esquemas backplate, ou seja, os fundos colocados atrás do enquadramento, e o seu suporte inicial no renderizador integrado Storm. Na 26.11, os backplates recebem materiais com animação ao longo do tempo, materiais não ilumináveis e gradação de brilho. Os parâmetros de gradação foram, por sua vez, renomeados: gain passou a slope, lift passou a offset, gamma passou a power. Os assets com os nomes antigos têm de ser atualizados.

No modo de pré-visualização, o Storm aprendeu a desenhar superfícies implícitas de forma nativa. Antes, este trabalho dizia respeito apenas às esferas; agora foram acrescentados cones, cilindros e cápsulas. O problema foi descrito no fórum da AOUSD, já em abril de 2025, por Matthew Kuruc: a esfera era convertida numa superfície de subdivisão e, após a suavização, «encolhia» para dentro do raio indicado. Se tal esfera for usada como guia para colisões, a imagem no viewport divergirá daquilo que a simulação vê. O desenho nativo mostra as formas suportadas diretamente, sem conversão prévia numa malha poligonal, mas, por agora, está desativado por omissão e ativa-se com uma opção experimental separada. Esta opção substituiu a anterior, que só se ocupava das esferas.

O que mais mudou

• No RenderMan XPU 27.3, os grafos de implementação MaterialX ampliam o suporte nativo para Standard Surface e OpenPBR. As integrações com o RenderMan 27.2 e versões anteriores têm de desativar esta capacidade.
• Surgiu um tipo de valor «duração», separado do instante de tempo: deslocar uma animação muda o seu início, mas não a sua duração. Os ficheiros com estes valores só serão lidos por versões recentes dos leitores USDC e USDA.
• As expressões de variáveis podem definir um valor de reserva, caso a variável não exista no contexto. Um asset pode definir um valor por omissão e o pipeline pode substituí-lo.
• As correções automáticas para os validadores já podem ser registadas em Python.
• A física trata de forma mais coerente os corpos rígidos desativados numa hierarquia, pelo que os colisores e as juntas são interpretados de maneira mais uniforme.
• As dependências foram alinhadas com a VFX Reference Platform CY2025: oneTBB por omissão, Qt 6.11 em Windows, Linux e macOS, OpenImageIO 3.1.8, OpenColorIO 2.4.2, OpenVDB 12.1.1, OpenEXR 3.3.6.
• Os ficheiros binários escritos pelas primeiras versões do formato Crate deixam de ser abertos por omissão pelo leitor. O grupo seguinte de versões antigas mantém-se com o estado de obsoleto.

O que isto significa na prática

O esquema de autoria aparece num contexto em que a questão da separação entre trabalho manual e gerado se torna cada vez mais visível para os estúdios. O valor de um registo destes dependerá, provavelmente, de os pacotes DCC começarem a preenchê-lo na exportação. O esquema, em si, é uma possibilidade do formato: se a ferramenta não criar registos, o campo ficará vazio.

Com o PMC convém ser mais cauteloso. A Alliance for Open Media abriu a implementação de referência do codec a 28 de abril de 2026 e ela própria classifica a norma como em preparação. Khaled Mammou, copresidente do grupo de trabalho, afirmou que os desenvolvedores podem ajudar a moldar a especificação final. Ou seja, o formato ainda pode mudar. Para a transferência interna de dados e a entrega de assets online, parece já ser possível experimentá-lo, mas arquivar assets de produção apenas em forma comprimida é, por agora, arriscado. A abordagem cautelosa é também indicada pelo facto de o componente estar desativado por omissão.

A julgar pela descrição, quem mais ganha com esta versão são os estúdios com cenas grandes e multidões: ganho na velocidade de composição e poupança de memória. Quem já tenha a gradação configurada nos backplates e mantenha no pipeline ficheiros USD binários muito antigos terá de dedicar tempo à migração.

Por que razão o OpenUSD se dedicou ao registo da autoria precisamente agora: a enxurrada de geração por IA, as exigências de direitos dos estúdios, a pressão dos reguladores?