Interfaces para a Imersão: design intuitivo e responsivo para o sistema web com P5.js

UI-UX. Esse é o nome do bixo. Usuario vê, usuario faz.

Pois então, o que exatamente estamos construindo aqui, exatamente? Apenas uma resposta integral pode guiar a construção do sistema, e por ventura, sua interface e experiencia.

Meu entendimento, é que estamos consruindo uma abstração que permite a construção de obras para fulldome, obviamente.

Ao mesmo tempo, temos um conjunto de competencias que são “obrigatorias”, tais como:

A necessidade de uma plataforma web nativa; A integração com linguagem javascript e suas bibliotecas; A simples importação de “assets”, de diversas naturezas, tais como 3d/2d, audio, videos, etc. Sejam vindo do blender ou outro programa; A capacidade de construção de obras, e com isso, uma linear manipulação de objetos; A capacidade de exportação dessas obras, sejam elas interativas, ou uma subsequente renderização de um projeto fixo; E a facilidade em operar o sistema e uma experiencia fluida de aprendizado.

Ou seja, no espirito das DAWs, uma Workstation para criação de arte Fulldome. “A Online FullDomeWorkStation”.

Existem dois caminhos, e eu acredito no segundo, que se alinha mais com a implementação godot deste post, do que a do post inicial.

Quais são os dois caminhos:

O primeiro, a do post inicial, é continuar utilizando o Godot EDITOR, expandindo sua capacidade e funcionalidade diante das necessidades apresentadas

O segundo, alinhado com o editor didatico apresentado mais acima, é construir um projeto, um programa, um jogo, um sistema, baseado em godot, EXPORTADO.

Cada um tem suas vantagens e desvantagens.

As vantagens do EDITOR são basicamente o fato de se estar convertendo a demanda de um projeto para ser um projeto godot, ou seja, todo o ecosistema de programação, conhecimentos e comunidade, estariam atrelados. Isso oferece uma vantagem a quem conhece o programa, ao mesmo tempo que permite maior liberdade de expansão. O problema é justamente a enorme curva de aprendizado que se aceita com essas vantagems.

A segunda opção, que eu pessoalmente acredito estar mais alinhada, é construir o sistema como um PROJETO. As vantagens são principalmente o fato de se estar oferecendo uma abstração, uma ferramenta especificamente alinhada ao proposito de criação do tipo de obra aqui trabalhado. Isso permitiria que o fluxo de trabalho não se assemelhe nem dependa do fluxo nativo do editor godot, e sim, um fluxo arbitrario e bem definido. Isso muito simplifica o processo de aprendizado e utilização do sistema. O problema é que isso requer que todo fluxo seja, bom, abstraido. Não mais godot quem oferece um gizmo para posicionar em 3d o objeto, e sim um personlizado, programado. Isso para tudo que for necessario.

Ambos os caminhos não são mutualmente excludentes, é possivel ter ambos, porem, é necessario que se faça uma escolha entre qual é a vertente central. Como dito, eu pessoalmente prefiro a exportação, e portanto vou seguir por esse caminho, ainda mais que a vertente do editor encontra-se basicamente completa.

Oferecer ambos é o melhor caminho, e o caminho perfeito é oferecer uma exportação que seja simple e pratica.

Sendo assim, como seria esse programa?

Vamos iterar nas necessidades basicas:

A necessidade de uma plataforma web nativa:

Godot oferece isso, acima vemos que é possivel, então temos isso ja sanado.

A integração com linguagem javascript e suas bibliotecas:

Pela ponte JavaScript do Godot, temos tambem essa necessidade cumprida, embora muitos fatores podem ser melhorados e completados, por exemplo, na implementação de Sobreposição-De-Iframe, o mouse funcionava nativamente. Com a implementação atual de Copia-De-Textura, é necessario a contrução de um emulador de entrada, ainda ainda a ser explorado.

A simples importação de “assets”, de diversas naturezas, tais como 3d/2d, audio, videos, etc. Sejam vindo do blender ou outro programa: 3D, 2D, e audio são tranquilos. Porem, Godot não tem um bom suporte a video online, uma limitação do fato de ser uma exportação webassembly, e videos serem melhor renderizados via codec nativo. É possivel, sim, mas com baixa performance. Talvez alguma biblioteca JavaScript seja util.

A capacidade de construção de obras, e com isso, uma linear manipulação de objetos; Aqui, temos o inicio dos problemas previstos. Como se faz essa operação sob os objetos? Via javasCript? Via GDScript? Via interface grafica a ser construida? Todas as opções anteriores?

Quando no EDITOR, tudo isso era possivel e praticamente automatico. Na EXPORTAÇÃO, não. Agora se faz necessario entender exatamente onde e como tais operadores iram atuar, de que forma, como habilitar, desabilitar, etc.

E a interface grafica, como seria? Um editor de ritmo tipo musical? Slides? Isso é alheio a programação, e sim uma necessidade de especificar o fluxo criativo que se deseja permitir.

Um esboço da UX pode então gerar uma especificação da UI, que por ventura então define as necessidades da implementação em si.

A capacidade de exportação dessas obras, sejam elas interativas, ou uma subsequente renderização de um projeto fixo: Godot tem um exportador nativo, que renderiza videos, porem, apenas em sua compilação para plataforma, não sua versão web. É possivel utilizar plugins JavaScript, que iriam ajuntar os frames num video, certamente. Mas, isso é mais uma complexidade.

O que se propõe é inverter os papeis, e godot ser utilizado na versão compilada, e apenas o javascript rodar no navegador. O Render standalone que ja se comentou. Quando implementado, seus resultados vão guiar melhor essas escolhas.

E a facilidade em operar o sistema e uma experiencia fluida de aprendizado: Documentação e exemplos praticos são a chave para isso, mais ainda do que um sistema bem construido, ou elegante.

Quando uma versão definitiva do projeto se apresentar concluida, a fase mais doce vai poder ser iniciada em completude, que seria a construção dos exemplos praticos, junto com um passo a passo, explanações de funções, etc.

Este blog se aproxima disso, mas não o é. É mais como um making-off, do que um tutorial. Os tutoriais seriam algo que vem depois do projeto estar completo, e não terminam por ai, continuariam a serem desenvolvidos.

Pois então. O que se pretende e por onde está bem definido, agora é concluir a implementação de todas as faces num projeto unificado, e começar a desenvolver esses projetos de musica visual para fulldome.

Antes disso, já se pode trabalhar com p5.js no projeto exportado acima, e tambem, no editor web com o template fornecido.