Importando Maya ASCII para jogo

Question

Atualmente, estou trabalhando na criação de um gasoduto à base de importação para o meu jogo indie usando Maya .ma ASCII como formato de fonte e meu próprio formato para a física e gráficos como saída. Vou manter coisas como atributos de amplitude de movimento dentro de Maya, como para uma articulação conjunta. Outros tipos de parâmetros que precisa de um monte de ajustes acabar em arquivos de origem separadas (possivelmente ini para coisas como massa, constantes de mola, a força dos motores físicas e similares).

A entrada é, portanto, um .ma e um ini, ea saída é, entre outras coisas, um .fisica e vários arquivos .mesh (um arquivo .mesh per geometria / material).

Estou também provavelmente vai usar Python 3.1 para reformatar os dados, e eu já encontrei alguns 2.1 código LGPL que lê ASCII básico Maya. Eu provavelmente também usar Python para lançar a plataforma durante o desenvolvimento. Jogo é desenvolvido em C ++.

Existe alguma coisa em tudo isso que você aconselharia contra? Um resumo rápido das coisas que pode ser falho:

gasoduto baseada-Import
• (não baseada em exportação)?
• Maya (não 3DS)?
• Maya .ma ASCII (não .mb)?
• ini (não .xml)?
• Separação de attibutes movimento em Maya e "freak-ajuste" atributos em ini (não todos em Maya)?
• Python 3.1 para a construção de dados (não incorporado C ++)?

Edit:. Se você tem uma sugestão melhor de como implementar a cadeia de ferramentas de física / gráficos de importação / exportação, eu apreciaria a entrada

Answer 1

Se você realmente quer fazer isso, você deve estar ciente de algumas coisas. A principal delas é que ele é provavelmente mais de um aborrecimento do que você poderia esperar primeiro. Alguns outros são:

• Maya .ma (pelo menos até o v.2010 atual) é construída por mel. Mel é Turing completo, mas o modo como a cena hierárquica é descrita em termos de nós é muito mais simples e direta de “código”.
• Adicionar início de tratamento de erros ou você vai se arrepender mais tarde.
• Você tem que lidar com um monte de diferentes nós, onde as transformações são de longe os mais detestáveis. Outros tipos incluem malhas, materiais (muitos tipos diferentes), “unidades de sombreamento” e arquivos (como texturas).
• .ma apenas descreve formas e ajustes; mas muito raramente define vértices matérias. Eu escolhi para manter um pequeno script “exportação” dentro da .ma para evitar ter de gerar todas as primitivas exatamente da mesma forma que Maya. Em retrospectiva, este era o caminho certo a seguir. Caso contrário, você tem que ser capaz de fazer coisas como
  1. “Criar esfera”,
  2. “Mover selecção macio com raio este-e-que daqui para lá”, e
  3. “Mover vértice 252 unidades XYZ” (com todos os vértices definidos implicitamente).
• Maya define polígonos para malhas; você pode querer conve rt para triângulos.
• Todos os parâmetros que existem em um certo tipo de nó são explícita ou implicitamente definido. Você tem que saber seus valores padrão (quando definido implicitamente),
• Basicamente, um objecto é definida por uma transformação, uma malha e um primitivo. A transformação é controladora da malha. A transformação contém a escala, rotação, tradução, traduções de articulação, e ainda alguns. As ligações de malha para um versa primitivo e vice. A primitiva tem um tipo ( “policubo”) e dimensões ( “largura, altura, profundidade”).
• Nodes podem ter “herança múltipla”. Por exemplo, uma malha instanciado várias vezes tem uma única malha (e uma única primitiva), mas vários pais (as transformações).
transforma
• Nó são calculados assim (ver Maya xform doc para mais informações):

vrt = getattr("rpt")
rt = mat4.translation(vrt)
...
m = t * rt * rpi * r * ar * rp * st * spi * sh * s * sp

• eu construir meu motor em torno de física, de modo que o motor de jogo quer malhas colocadas em formas físicas, mas na modelagem eu quero que o contrário. Isto mantê-lo genérico para aplicações futuras ( “malhas sem a física”). Esta pequena decisão me causou séria dor nas transformações. Álgebra Linear tem uma escova-up. Problemas na escala, rotação, tradução e corte; o nome dele, eu tive isso.
• Eu construí a minha ferramenta de importação sobre cgkit ’s analisador Maya. Graças Matthias Baas!
• Se você vai fazer algo semelhante, eu recomendo fortemente que você espreitar em meu conversor antes de escrever o seu próprio. Este projeto “pequeno” Levei três meses de agonia para chegar a uma condição básica de trabalho.

Answer 2

Como um formato de serialização geral que é tanto gravável legível e humana humana, tem um excelente suporte Python (e, bem, qualquer suporte ao idioma realmente), você pode querer considerar usando YAML ou JSON sobre ini ou XML.

XML poderia ser aceitável em seu caso, se você nunca gerar arquivos manualmente.

Uma das vantagens de JSON e YAML é digitando: ambos os formatos são analisados ??até listas de Python, dicionários, carros alegóricos, ints ... basicamente:. Tipos python sãs

Além disso, a menos que você tenha certeza de que todas as bibliotecas que você jamais vai usar obras em 3.1, você pode querer considerar furar com 2.x para um pouco devido a problemas de disponibilidade de bibliotecas.

Answer 3

Você deve considerar o uso de um duto à base de exportação ou de um formato de arquivo padronizado tais como OBJ ou COLLADA em vez de re-implementação de um analisador .ma e replicar todos os internos Maya necessárias para interpretá-lo.

O formato .ma / .mb não se destina a ser lido por qualquer programa que não seja em si Maya, de modo a Autodesk não colocar qualquer esforço para tornar este um processo fácil. Para analisá-lo 100% corretamente seria necessário para implementar toda a linguagem de script MEL.

Todos os dutos baseados em Maya que eu vi qualquer primeiro exportar conteúdo em um formato de arquivo padronizado, ou executar scripts MEL dentro de Maya para despejar o conteúdo usando as interfaces de nós Mel.

Note que Maya pode ser executado em um modo "sem cabeça", onde ele carrega uma cena, executa um script MEL, e existe, sem carregar o GUI. Assim, não há nenhum problema de usá-lo dentro de sistemas de compilação automatizados.