Este ano a BlenderPRO alcançou um patamar impressionante. Com três dias de evento o espaço de convívio, trocas, aprendizado e diversão está em suas devidas dimensões. Infelizmente por motivos geográficos e patrocináficos eu não pude comparecer. Ainda assim conseguimos organizar uma oficina online sobre desenvolvimento da Blender Game Engine.

Luis Retondaro e Erick Henrique - parabens por todo o trabalho

Foto da direita pra esquerda: Luis Retondaro e Erick Henrique : meus mais sinceros parabéns por toda a disposição, trabalho e generosidade em tocar este sonho coletivo chamado BlenderPRO

O meu principal objetivo com esta oficina, era o de naturalizar a figura do desenvolvedor do software livre.  Mostrar um pouco como qualquer pessoa pode se envolver e o proesso não tem grandes mistérios. O público-alvo variou desde pessoas experientes em programação a usuários da BGE ávidos por entender um pouco mais do que acontece em seus bastidores.

Quem?

O começo foi uma conversa sobre quem hoje em dia desenvolve para a Blender Game Engine e para o Blender, e o que leva pessoas a aventurarem-se nestes espaços. Claro que as motivações são sempre pessoais, então aproveitei para compartihar as minhas próprias motivações e um pouco de minha trajetória.

Sobre os desenvolvedores do Blender você encontra em um post anterior uma análise tratando um pouco deste tema. Sobre minha trajetória você encontra espalhado por este blog diversos momentos desta minha caminhada na terceira dimensão.

De uma forma geral, a maioria dos desenvolvedores Blender são usuários que de uma forma ou de outra viram-se compelidos à contribuir de volta para o programa. Tendo em vista a quantidade de bugs que sempre cerca o Blender, não é difícil entender como alguém que desesperadamente precise de alguma coisa implementada acabe por fazê-lo por conta própria. Um detalhe interessante é que a grande maioria dos desenvolvedores do Blender não tem formação formal de computação. São (nos quais me incluo) auto-didatas com expertises nas mais diversas áreas. Comentei também sobre o escasso cenário de desenvolvedoresda Blender Game Engine. Isto está melhorando sem dúvidas, mas é ainda uma situação alarmante (temos atualmente não mais do que 6 desenvolvedores mais ou menos ativos).

Quê?

Uma vez entendido quem desenvolve para a Blender Game Engine foi a hora de falar um pouco sobre o tipo de funcionalidade que sempre é bem-vinda no programa e que critérios são usados para decidir sobre isso. Eu queria ter abordado este assunto com mais calma, mas enfim acho que deu pra passar um pouco a idéia.

De modo geral para uma funcionalidade entrar no programa ela deve atender aos quesitos: utilidade (ser de amplo uso), robustez (o código tem que se integrar bem com o código atual do programa) e manutenção (é importante ser fácil contar com suporte futuro para correção de bugs – tanto por parte do desenvolvedor original, ou  por quem quer que assuma esta área).

Depois destes dois pré-estabelecidos tópicos eu abri para perguntas, para entender para onde guiar a conversa.  Uma das primeiras perguntas foi sobre porque o Blender congela quando se adiciona uma nova cena. A razão por trás disso é bem simples: o suporte para Multithreading na BGE é praticamente inexistente. Por um lado isto é comum em qualquer engine de jogos (é muito complicado sincronizar eventos que sejam co-dependentes). Por outro pela falta total de suporte à processamento paralelo, a Blender Game Engine é toda implementada de forma serial. Ou seja, um processo só começa quando seu anterior termina – por exemplo, um script só é calculado quando o script anterior estiver terminado. Com isso sempre que se carrega uma nova cena Blender “trava” enquanto a cena nova é carregada. Talvez seja possível usar multi-threading especificamente para esta funcionalidade. Vamos ver. Eu prometi dar uma olhada, mas não tenho a menor idéia do que eu vou encontrar no código.

Com isso eu aproveitei para mostrar também o processo de conversão de objetos do Blender para a Blender Game Engine. De forma resumida, é só entender que quando você altera a posição, cor, tamanho, … de um objeto durante o jogo, você não quer que isso altere o seu arquivo original quando você interromper o mesmo. Por isso a BGE funciona como um sistema blindado, em que todos os elementos do jogo no Blender tem que ser convertidos para estruturas internas da BGE. E falamos também um pouco da estrutura do código da BGE (bem por alto, simplesmente explicando o que cada diretório no código abriga).

Como?

E chegou a hora de uma entendiante (para quem estava assistindo) sessão ao-vivo de bug-fixing. Luis Retondaro (o grande Luis 🙂 ) perguntou como que alguém que já programe tem como meter a mão na massa. Bom, isso certamente merece um artigo em si mesmo, mas aproveitamos a deixa para tentar consertar algum bug da BGE. O bug escolhido foi [#22371] Alpha Planes affecting 2DFilters. Foi divertido mostrar o tracker (sistema de gerenciamento de bugs e patches do Blender) pra galera, e explicar um pouco das ferramentas que eu uso. No caso especificamente:

  • MSVC – Microsoft Visual Studio 2008 – IDE para programar, debuggar, compilar
  • GrepWin – ferramenta para fazer buscas rápidas no código
  • IRC – programa de conversa usado pelos desenvolvedores e agregados para conversa de forma mais dinâmica do que listas de discussão permitem. #blendercoders no FreeNodes. É um ótimo lugar para tirar dúvidas quando se está começando a desenvolver pro Blender, e um péssimo lugar para pedir funcionalidades novas. Meu nick lá é dfelinto. Ah, there it’s English only.

Para quem está no Linux ou Mac lá também existem ferramentas próprias para programação com suas vantagens e desvantagens. A correção do bug na verdade é uma linha, mas como todo bug gasta-se um bom tempo com investigações e testes. A página de bugs e patches é projects.blender.org lá é possível visitar bugs já identificados, e ajudar a testar outros ou enviar seus patches. É uma ferramenta vital pois representa boa parte do canal de comunicação entre os desenvolvedores e os usuários.

Uma parte importante deste etapa são os chamados 3 erres. (1) Reproduzir (2) Reduzir e (3) Resolver. Não importa o tamanho de seu problema, este sistema é de ampla utilidade. As etapas (1) e (2) podem ser inclusive feitas por pessoas sem nenhum conhecimento de programação, liberando o programador para a tarefa de resolução do problema. Reproduzir é a primeira etapa, e é a parte de triagem, onde se determina se um bug é uma falha do programa mesmo, ou simplesmente um descuido do usuário. Reduzir e simplificar é uma das etapas mais importantes na minha opinião, muitas vezes representando mais da metade do trabalho de consertar um bug. Simplificar um problema para a sua instância mais enxuta permite ao desenvolvedor não ter dúvidas sobre onde começar a atacar. Resolver é o trabalho inestigativo de entender dentro do código onde o problema se manifesta, e como contorná-lo.

Câmera, Luz, Ação

A idéia original era fazer deste workshop um ponto de partida para que novos desenvolvedores pudessem dar seus primeiros passos. Para tanto, resolvi criar dois vídeos ao longo do fim de semana mostrando o dia-a-dia do desenvolvimento da Blender Game Engine. A intenção dos vídeos é ilustrar o fluxo de trabalho (workflow) apartir de exemplos reais de funcionalidades implementadas. Ambos os vídeos foram gravados “ao vivo”, com isso eles se extenderam um pouco mais do que eu tinha imaginado, mas servem também para mostrar em tempo real a forma de pensar e agir que eu emprego.

O primeiro vídeo tem uma hora e meia de duração e mostra a implementação do método object.life. Este é um recurso criado para sincronizar eventos junto com a extinção de objetos temporários – objetos criados pelo Actuator Edit Object->Add Object). O vídeo mostra as etapas de criação de arquivos de teste, investigação, debugging, … até a função ser enviada para o código do Blender.

O arquivo usado para testes durante a gravação encontra-se aqui.

O segundo vídeo é de uma hora de duração. Neste caso eu resolvi mostrar o processo de revisão de patches (no caso meu próprio patch) e inclusão da funcionalidade no código do Blender. A funcionalidade escolhida foi a bge.render.makeScreenshot (a antiga Rasterizer.makeScreenshot). Esta função permite que você capture a tela do jogo enquanto ele está rodando. Ela ainda não tinha sido portada do Blender 2.49.

O arquivo de exemplo mostrado no vídeo encontra-se aqui

Mais Dúvidas

Mesmo sem passar os vídeos, não deu tempo de cobrir todos os assuntos que gostaríamos. Ficaram algumas questão não respondidas que vou aproveitar agora pra discorrer brevemente sobre elas:

– Como saber em que pé está cada módulo/parte do Blender (entre 2.49 e 2.50)?

A forma mais confiável é compilando o Blender você mesmo e conferindo no programa. Ou confiar que de tempo em tempo a documentação online esteja atualizada também – ToDo. O último recurso é perguntar para um desenvolvedor que saiba te indicar quem é o responsável pela área em questão

– Que fim levou o WebPlugin?

Infelizmente o desenvolvimento do webplugin (que tinha recomeçado em 2008) foi interrompido novamente. O principal motivo foi o investimento de grandes empresas e consórcios na área de 3D na internet e a não definição de um padrão estabelecido. Pareceu um pouco desperdício de energia investir numa solução própria quando talve o futuro próximo possa vir a proporcionar uma nova solução comum.

– Adição Fundo Preto/Branco/….

Eu anotei isso, mas agora não tenho a menor idéia da pergunta :/ Alguém lembra?

– Onde encontrar documentação do código  do Blender?

Existe até bastante documentação em inglês: Coding Guides Tutorials , Architecture . Existe uma regra “não-escrita” que diz que se você não consegue entender o código lendo ele, então você não devia mexer nele. Eu não concordo de todo com ela, mas ela acaba se aplicando a áreas meio cabeludas do Blender/BGE como parte do código de rendering ou mesmo a parte de GLSL.

E agora?

Aí depende. Se tiver gente interessada em um sistema de tutoria, eu me ponho na disposição de ajudar no que for possível. Eu tive bastante ajuda para começar, e tenho até hoje. Não é dar o peixe, mas ensinar a desbravar os mares e mergulhar fundo no Blender. Posso gravar mais vídeos, tirar dúvidas, …

E lembre-se, o segredo é ser cara-de-pau 😉
Uma boa noite,

Dalai

(muito obrigado a todos que ajudaram na organização do evento de alguma forma e a todos que compareceram. Fiquei emocionado de ver todo mundo hoje, mesmo que pela webcam).

Artigos relacionados que eu recomendo:

Leave a Reply

Your email address will not be published. Required fields are marked *

Post Navigation