Integração [p5.js:Godot Engine] via JavaScriptBridge
Indice:
Integração p5.js:Godot Engine via JavaScriptBridge
Então Música Visual em Fulldome é?
Quais as funções da programação?
A web como interface coletiva.
A extensionabilidade do Javascript.
Godot, Motor de Jogo ou Multiparadigma?
GDScript como interface entre Criação e Programação.
Proposta de servidor monolitico:
Blender. Possível ecossistema criativo unificado?
O que é Música Visual?
Complexo definir o que é música visual, pois partindo de uma extensão da definição de música, o que seria música? Todo e qualquer som pode ter contexto musical, logo, tudo pode ser -mas nem sempre o é- música. Sendo então, música VISUAL, pode ser tudo que se vê, mas também, não necessariamente o é.
Partindo dessa ecologia “pan acusmática”, temos uma emancipação criativa onde não existe paradigma que o defina. Mesmo assim, todo horizonte tem apenas um sol de onde virtualmente toda luz emana, mesmo existindo estrelas, quase toda a nos iluminar.
Pode-se concluir que então música visual é a arte que utiliza de mecanismos tradicionais da arte musical, na arte (áudio)-visual. Como por exemplo, o ritmo, a textura, contraponto, forma, etc. É o desenvolvimento de uma progressão não mais de objetos sonoros, mas sim, de objetos visuais, regidos por princípios de estruturação musical sonora. Literalmente uma análoga/sinestésica transformação de princípios musicais audíveis, em paralelos visíveis.
Como tais elementos podem ser análogos entre si, podem ser então pareados, produzindo uma obra de Música visual ‘musical’. O tradicional “Clipe”. Contendo tanto musica audível quanto visível, simultaneamente.
Segue abaixo alguns exemplos em diferentes estilos:
O que é Fulldome?
Em si, Fulldome é uma tecnologia desenvolvida para visualização de planetários virtuais. Existem diversas tecnologias, indo de projetores adaptados, sistemas de multi projetores a telas de microled. O que é relevante entender da ferramenta, é que ela proporciona ao publico uma tela curva imersiva em formato de meia esfera, onde uma imersão paralela a da realidade virtual ocorre sem a necessidade dos óculos.
Sua peculiar estrutura resulta em um tratamento especifico de sua mídia. Existem distorções e campos uteis da tela que devem ser bem tratados e considerados durante todas as a fases de produção, para que ocorra um fidedigno mapeamento da projeção a estrutura física da tela do domo, garantido a imersão. Por exemplo, o video geralmente é quadrado com um circulo inscrito, onde apenas o video do circulo é projetado.
Novamente, mais alguns exemplos:
Então Música Visual em Fulldome é?
Por definição, a concatenação das duas anteriores, basicamente. Porem, é importante entender que a mudança do contexto de uma arte, vai implicar em uma mudança da arte em si, certamente.
Aqui, na música visual em Fulldome, tendo a música visual como o objeto artístico e o Fulldome implicando em diversas modificações em seu estrutura basal, como objeto técnico: Por exemplo, o que antes era bidimensional, agora tem uma tridimensionalidade inerente, pois o espectador pode observar diversas partes do domo, geralmente focando na qual ele se encontra assentado em determinada sessão. Temos também o próprio fato de que agora trabalha-se com uma outra geometria. Não mais popula-se o retângulo, agora popula-se uma casca de semisfera. Seus diversos anéis concêntricos oferecem caminhos fundamentalmente distintos de um circulo na tela: É necessário mover sua cabeça para acompanhar, não apenas os olhos. Certamente diversas particularidades estruturais singulares emergem desse entre lugar da música visual e da projeção fulldome. Tais estruturas, implicam cada em incontáveis potenciais aplicações, não necessariamente intercambiáveis com uma tela bidimensional. Sendo assim, idiossincráticos.
Isso sem dizer, na aplicação imediata de uma transformada tridimensional, onde ao utilizar o domo como tela de câmera, temos uma imersão “holodeckiana” de um ambiente tridimensional. Não distante de seu uso original, ao simular um espaço sideral virtual.
Temos então que Música Visual em Fulldome é um encontro de diversas categorias criativas: As estruturas musicais, que servem como fonte artística formal para a regência dos elementos visuais; Os elementos visuais em si, que podem ser objetos 3d, imagens 2d, ou artifícios gerados em tempo real via código; E, a fisicalidade da estrutura projetiva que se destina a obra criativa, a semisfera do Fulldome, que implica em diversas peculiaridades técnico/criativas.
Sendo assim, é de uma uma imbricação curiosíssima entre arte generativa e tecnologias imersivas.
Quais as funções da programação?
Programação, que vem do computes 1337 ‘r0d4r b0ls1nh4’, ou como dizem, fazer programa, é nada mais que fazer o que não quer pra ter o que quer. A maquina não pensa e agora finge que pensa, e fingimos que acreditamos, e por isso achamos ter inteligencia artificial, e, dado que a única função valida da computação é criar a inteligencia artificial, não temos nenhuma função para a programação neste projeto. Risos.
Talvez um igual o do filme “I.A.” imersivo. DomoGPT.
Porem, contudo, mesmo assim, é possível contentar-se com objetos abstratos programáticos que resolvem problemas de forma mais eficiente, por preguiça ou falta de tempo/esforço. Duas mãos na roda.
Por exemplo, a programação pode ser utilizada para construir os objetos visuais que necessitamos para a criação de obras, através de “snippets” de arte generativa, ou modelagem/pintura virtual; Pode ser utilizada para a manutenção desses objetos durante a obra, movimentando e orquestrando suas diversas propriedades ao longo das cenas, tal como posição, tamanho, cor, rotação, transparência, ordenação, etc.; Também é de grande valia para implementar transformações visuais necessárias para adequação ao formato da mídia, como de fato é necessário ao gerar as distorções necessárias ao formato FullDome;
Basicamente essas 3 funções acima cobrem os usos. Porem, idealmente o objeto final da computação se permeia, e a arte generativa/deepmind pode sim vir a ser utilizada na criação audiovisual, até mesmo em primeiro plano.
Porem, garantir que o que se obtêm de resultado final, é necessariamente o que se deseja, é nada mais que um interlúdio entre esses 3 princípios básicos de criação, manutenção e adequação, que a programação livremente oferece caminhos.
A web como interface coletiva.
www.com.br sempre será o melhor site. ou deveria ser www.www.com.br? Pois bem, tem quem é dono, tem que aluga, tem quem faz hotel. Pois ora, cá estamos hospedados neste site, não é mesmo?
Pois então, surfando nesse mar, todos tem seu prancha navegadora, e disso obtemos a maior hegemonia da historia da informática. Atualmente, HTML/JavaScript/WebAssembly formam um complexo que permite todo e qualquer sistema decupar-se e reagir ao mesmo processo igualmente. Ou seja, unifica-se a experiencia de forma agnóstica ao sistema/navegador. (na boa fé/Best Effort)
Graças a esse finalmente, a Web tornou-se um padrão de fato uniforme, nativamente. Isso permite quebrar com confiança as barreiras, os jardins cercados, dos Sistemas Operacionais, e até mesmo dos Fatores Forma:
Um projeto Web Moderno que espera diversos fatores forma, vai os encontrar e adequar-se em tempo real, e entregar a mesma experiencia central, seja num PC, iPhone, SmartTV, Android Car, etc. Sendo um sistema moderno, é garantido funcionar.
Essa liberdade e interoperabilidade permite a criação de experiencias multimídia com um nível de conforto para o programador web, sem precedentes (idealmente).
A extensionabilidade do Javascript.
Em suma, o navegador e o computador estão isolados entre si. Nada que ocorra no sistema em geral deve afetar uma janela de navegação, e vice-versa. Os momentos onde isso deixa de ocorrer devem ser intencionais e absolutamente controlados pelo usuário, nunca internamente. Sendo assim, o navegador é um “sandbox”, onde a areia só cai pra fora se você jogar.
Porem, dentro deste sandbox, é possível construir outros sandboxes, utilizando por exemplo WebAssembly, que pode ser supostamente compilado de qualquer linguagem de programação. Tal competência permite que qualquer estrutura computacional seja portada para o navegador, tornando-o performático e completo. Além disso, o próprio JavaScript tem essa competência, pois já era possível transpilar programas para a web usando puro JavaScript, porem com baixa performance, o que foi resolvido com o WA.
Contextualizando, o JavaScript é sim uma linguagem de programação integral, onde quaisquer objetivos informáticos necessários são atingíveis.
Tais objetivos podem ser catalogados e aglutinados, permitindo uma floculação de grupos de interesse, que se sublimam nas chamadas Bibliotecas.
JavaScript oferece acesso a diversas bibliotecas que são uteis aos objetivos da pesquisa. As bibliotecas, p5.js e tone.js completam o escopo audiovisual, com corrotinas pré-programadas que oferecem diversas funcionalidades básicas e interoperáveis, tais como analise de som e criação de formas geométricas.
Godot, Motor de Jogo ou Multiparadigma?
The one that never arrives. A “engine” que nunca vai ser boa o bastante, não é mesmo? Por que escolher algo com tal alcunha? Bom, de fato Godot é ruim mesmo, mais de 10mil tickets abertos em seu github, a maior parte deles bem antiga. Se tem urgência, corrija você mesmo, pague pra corrigir, use versão customizada, etc. Mesmo assim, é o melhor que existe em engines open-source.
É bem fácil criticar Godot, de fato, basta voltar para os tickets não resolvidos. Porem, devemos ir para o argumento da pergunta, e a sua resposta nos coloca num bom entendimento, pois de fato apenas motor de jogo Godot não é mais.
Integrar diversas funcionalidades num binário único, que abarcam todo o escopo de necessidade, oferecer suporte web, extensionalidade nativa para qualquer linguagem de programação, suporte a renderizações modernas, realidade virtual/mista, etc… Godot é um verdadeiro canivete suíço. Obvio que nenhuma de suas ferramentas é a central, porem sua entourage é como nenhuma outra, sua flexibilidade e interna solidez são incomparáveis. Tudo isso numa linguagem de programação própria, capaz de levar ao máximo a integração entre todos esses componentes. Godot realmente está longe chegar na perfeição. É ruim pois tenta ser bom em tudo, mas está cada vez melhor.
Jogos triplo AAA são feitos em Godot, tal como o em desenvolvimento “PVKK”, e o remake “Sonic Colors: Ultimate” que utiliza seu motor gráfico. Ferramentas/utilitários de desenvolvimento tal como “Material Maker”, onde proceduralmente pode-se construir texturas/materiais; Players de Música, como o ‘Veles’, totalmente open-source e utilizando a integração GDNative para funções dedicadas em linguagens de programação compiladas externamente.
Então, Godot está mais para uma IDE do GDScript, sua linguagem de programação, do que um motor de jogos.
Justifica-se então seu uso, graças a sua incrível flexibilidade, para a implementação do framework de criação Fulldome aqui relatado.
GDScript como interface entre Criação e Programação.
Ah GDScript. Sempre tão doce. O que esperar de uma linguagem de programação originada de um motor de jogos? Não muito, não é mesmo? Algo simples apenas para interação em tempo real, controle de score, etc?
Leviano assim pensar, pois sendo capaz de iterar, é capaz de tudo! Então, sendo “não-tão-simploria” está linguagem, onde então ela nos coloca?
Ela nos coloca na interface entre a criação e a programação!
O programador se torna a interface, onde ao programar em GDScript programa-se em pura arte. Programar em GD é como pintar com variáveis e iterações e quase infinitos pinceis; Não existem muitos limites -caso sua maquina não entre na frente- nessa linda ecologia. É ter a capacidade de invocar qualquer tipo de elemento audiovisual, e ter total autonomia sob sua estrutura, do inicio ao fim.
Demiurgia digital destituída de desafios desastrosos. Toda e qualquer estrutura tem uma progressão simples e direta -ou não?- a seguir para sua manifestação. Complexo, sim, muito complexo, por mais que seja uma linguagem de alto-nivel, sua programação ainda exige que nada seja ao acaso. É necessário um fundamental entendimento do que está acontecendo, e do que se deseja que aconteça, por mais obvio que isso pareça. (Como qualquer linguagem orientada a objetos)
GDScript não te ajuda nem simplifica. Ele apenas não te atrapalha, e isso já basta para ser uma boa linguagem de programação.
Ponte JavaScript-GDScript.
Finalmente chegamos ao objetivo deste post. A ponte JavaScript! Godot oferece desde sua versão 3, uma interface adicional, quando exportado para o navegador. Temos também o próprio editor exportado em web, ou seja, tanto projeto quando editor rodando no navegador!
Inicialmente, propunha-se um editor JavaScript criado em godot. Ou seja, um projeto exportado que ao rodar no navegador permitiria que código JS fosse iterado em tempo real. Tal abordagem serviu para comprovar a integração da ponte no fluxo do trabalho da pesquisa.
Subsequentemente, entendeu-se que era possível acessar a ponte diretamente do editor, sem que fosse necessário exportar o projeto, caso seja usado o editor web do Godot. Tal entendimento muito facilitou o desenvolvimento da experiencia de usuário que buscava-se: Agora temos como construir o JavaScript como um modulo adicional dentre os vários de Godot. Apenas mais um Node, o node onde pode-se escrever código web e tratar sua estrutura como a de qualquer outro node nativo interno.
Isso permitiu trabalhar com “snippets” de p5.js como se fossem códigos nativos de Godot. Bastava atualizar o script e sua função refletia imediatamente. Fosse necessário duplicar, iterar, aninhar, era simplesmente o fazer via Editor ou GDScript. Tinha-se um “canvas” que era tratado como um node qualquer. Atingir tal sincronia foi um trabalho fino de engenharia reversa, sincronizando um iframe virtual acima da janela do godot, alinhando e atualizando com relação a interface do editor.
Tido o sucesso em sincronizar o código com a tela, notou-se um desafio, trabalhar no ambiente 3d não seria possível desta forma. O canvas era alheio ao Godot, sendo um artificio visível somente ao usuário. Necessitava-se de outra forma de obter o conteúdo do “iframe”. Apos diversas investigações, entendeu-se que o próprio p5.js construía um canvas interno que podia ser acessado e convertido em imagem. Foi então possível trabalhar com texturas em 3d, sem a sobreposição de iframes, diretamente.
Tido então sucesso pleno, a integração entre as skecthes e o godot, percebeu-se que parte do processo podia ser abstraído, solucionando uma limitação. Apenas pode-se utilizar tais ferramentas na versão web, pois necessita-se do navegador para acessar o JavaScript. Concluiu-se que construir uma ferramenta que centralize o render das sketches, tornaria o sistema agnóstico, sendo acessível via API. Seria possível utilizar então tanto em godot web, como em exportações nativas, o que acelera a performance. Também isolaria o tratamento das sketches, que pode ser feito em godot, blender, etc, do Render em si.
Camera Fulldome 3D.
Tendo então o túnel de renderização implementado, torna-se possível trabalhar diretamente no ambiente 3D, não mais limitando-se a uma sobreposição de iframe. Tal liberdade permite então tratar das distorções necessárias para adequação ao formato FullDome.
Aqui, foi utilizado parte da implementação da camera 360 (https://github.com/Cykyrios/Godot360). Derivou-se e simplificando o código, restando somente a implementação fulldome, 180, em semiesfera. Com tal câmera, agora é possível converter uma cena 3D arbitraria, em uma projeção fisheye, apropriada ao domo.
Pronto. Todas as ferramentas básicas estão a disposição. Porem por estarmos na implementação web do editor, não temos acesso ao exportador nativo do godot, tal a necessidade do servidor monolítico proposto, permitir utilizar na versão desktop a integração com o JavaScript.
Mesmo assim, a construção de projetos e cenas encontra-se integralizada.
Analise de implementação.
Por favor, acesse
Em “Preload project ZIP:” selecione o template (LINK DO TEMPLATE HOSPEDADO AQUI)
Então, clique em “Start Godot editor”. Ao terminar de carregar,clique em instalar e editar, isso vai abrir o projeto no editor online do Godot.
Ao abrir, alguns error podem ser cuspidos pelo editor, normal, são subsistemas que demoram para carregar e certas dependências. Contanto que depois de alguns momentos, em sua tela uma pequena casa passe a aparecer em locais aleatórios num circulo cinza, o projeto carregou com sucesso!
Isso é p5.js sendo usado como textura num painel 3d sendo renderizado num fisheye para fulldome, tudo em seu browser integrado a um editor, em tempo real! Oba :D
Vamos a analise? Então, antes de tudo, vamos entender um pouco de Godot. A construção de cenas é feita usando “nodes”, que representam algo, e são derivados sempre de um outro tipo de node, mais abstrato que o próprio. Ou seja, tudo deriva de uma definição de node mais básica, e existem nodes especializados. Além disso, é possível estender um node qualquer, usando GDScript, permitindo então personalizar seu funcionamento, etc.
Neste projeto, para esta cena de exemplo, são utilizados os nodes:
TextureRect;SubViewport;Camera360(plugin);Node3D,CodeEdit;Sprite3D;WorldEnviroment.
Estes são os nodes utilizados. Segue uma explicação básica e simplificada de seu funcionamento, em sequencia, sua função na implementação.
TextureRect: É um quadrado que aceita uma imagem.
SubViewport: É um quadrado que renderiza uma sub-cena. (um monitor virtual)
Camera360: É o plugin modificado que serve como câmera fulldome.
Node3D: É uma origem no plano cartesiano tridimensional.
CodeEdit: Permite editar textos e códigos.
Sprite3D: Parecido com o TextureRect, porem pode ser usado em 3D.
WorldEnvironment: Define parâmetros como iluminação global, etc.
Tendo Entendimento básico dos nodes, podemos esboçar a nossa arvore de projeto, ou seja, como os nodes estão estruturados entre si na cena:
Temos três cenas:
A primeira cena, demo_scene.tscn, é o projeto completo em si; A segunda cena, “teste js.tscn”, é a cena em si, definida num ambiente tridimensional A terceira cena, code_edit.tscn, é a interface JavaScript.
Como a cena code_edit vai ser usada na cena “teste js.tscn”, vamos começar por ela:
A cena code_edit contem apenas um node, sua raiz. Este node é uma instancia do node “CodeEdit”. Este node tem um script de editor associado a ele. Scripts de editor rodam tanto no projeto final ou no editor, isto permite implementar funções que rodam a todo momento, seja na exportação ou durante a edição.
Abaixo o código:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
@tool
extends CodeEdit
@export var start = false
@onready var teex = $".."
var document
var overlay
var iframe
var browser = OS.get_name() == "HTML5" or OS.get_name() == "Web"
var editor = Engine.is_editor_hint()
func _notification(what):
if what == NOTIFICATION_PREDELETE:
browsery("CLEARER")
func browsery(action,payload = ""):
if browser:
match action:
"CLEARER":
if overlay:
overlay.remove()
"INITER":
document = JavaScriptBridge.get_interface("document")
overlay = document.createElement('div')
iframe = document.createElement('iframe')
overlay.style = "display:none;"
iframe.srcdoc = ""
overlay.appendChild(iframe)
document.body.appendChild(overlay)
"SOURCE":
iframe.srcdoc = payload
func _ready() -> void:
browsery("CLEARER")
browsery("INITER")
var textext = ""
func _process(delta: float) -> void:
if text != textext:
textext = text
var newtext = placeholder_text.replace("SCRIPT_VAR_SCRIPT",textext.replace("\t",""))
browsery("SOURCE",newtext)
if start:
start = false
iframe.contentWindow["loops"] = 100
teex.texture = update_texture()
func update_texture():
var img := Image.new()
var p = iframe.contentWindow["frame"]
p = p.right("data:image/png;base64,".length()*-1)
p = Marshalls.base64_to_raw(p)
img.load_png_from_buffer(p)
var loctex = ImageTexture.create_from_image(img)
return loctex
Vamos a analise detalhada dessa implementação, linhas por linhas:
1: Temos a anotação que define que este script roda dentro do editor;
2: Definimos a classe base, o tipo de node, que estamos nos baseando para construir o script;
4: Uma variável que aparece no editor, pode ser modificada por todos, serve para iniciar uma corrotina na LINHA 52;
5: Outra variável exportada, é onde a textura final resultante, frame a frame, é alocada. Nessa implementação, o script busca o node acima de si próprio, portanto, deve ser anexado a um node que contenha uma textura. Veremos que é o caso, sendo este um TextureRect.
7-9: Alocamos as variáveis que vão servir para instaurar a ponte javascript numa iframe virtual.
11,12: Verifica se o código está rodando no editor, e em especifico, na versão web.
16-18: Uma função virtual, ou seja, invocada pelo próprio Godot, neste caso, verifica se a instancia está sendo deletada, se sim, remove o overlay, limpando a memoria do navegador da instancia virtual JavaScript.
20-38: Um conjunto de funções chave, alocadas numa única função genérica. “CLEARER” limpa a memoria da instancia atual; “INITER” executa diversos passos que inicializam o iframe virtual invisível, para ser alocado com o script desejado; “SOURCE” define este script nessa instancia virtual.
41-43: Função virtual invocada quando o script inicia, neste caso limpa a instancia por precaução, e a inicializa.
45: Variável que contem o código-fonte html/JavaScript.
46-56: Outra função virtual, é invocada todo frame. Se o texto do CodeEdit for diferente da variável do código-fonte, ela é atualizada, e o código instaurado no iframe virtual. Temos também o uso da variável global start, que neste caso, na linha 54, acessa uma variável JavaScript, e a modifica, fazendo a casinha voltar a mover-se aleatoriamente. Então, a textura exportada é sincronizada.
59-66: O sincronizador de textura, cria uma imagem vazia, e então, acessa a variável “frame”. Ela contem a imagem em base64. O código então adiciona o “header” necessário a uma imagem base64, converte para bytes, carrega a imagem e constrói uma textura, retornando-a.
A LINHA 49, constrói o código-fonte utilizando duas variáveis: “placeholder_text” e “text”. Estas variáveis são nativas do CodeEdit, e podem ser editadas pelo editor.
“placeholder_text” contem o código HTML
“text” contem o código JAVASCRIPT.
A LINHA 49 funde ambos os textos, e remove suas quebras de linha, permitindo que a pagina torne-se um código-fonte de uma única linha de texto, facilmente atribuível dinamicamente.
O código HTML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<!DOCTYPE html>
<html lang='en'>
<head>
<script src='https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.9.4/p5.js'></script>
<meta charset='utf-8' />
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
html, body {
height: 100%;
width: 100%;
overflow: hidden; /* Prevent scrolling */
}
</style>
</head>
<body>
<script>
SCRIPT_VAR_SCRIPT
</script>
</body>
</html>
Analisando o código HTML:
1-3: Temos metadados inicializadores.
4: Ocorre o carregamento da biblioteca p5.js.
6-20: Finaliza-se metadados e configurações de estilo.
22-26: Temos a implementação do código em si, sendo a LINHA 24, o placeholder para o código JavaScript em si.
27: Fecha o código HTML.
E utilizando a biblioteca p5.js temos o código JAVASCRIPT:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var loops = 90
var frame
function setup(){
createCanvas(2160, 2160);
}
function draw(){
if (loops >= 1){
loops -= 1
background(0,0,0,0);
scale(10)
translate(random(1,200), random(1,200));
drawHouse();
}
frame = canvas.toDataURL();
}
function drawHouse() {
clear()
triangle(15, 0, 0, 15, 30, 15);
rect(0, 15, 30, 25);
rect(12, 30, 10, 10);
}
Analisando o código JAVASCRIPT:
1: Define a variável com a quantidade de iterações.
2: Define a variável que vai conter os frames em base64.
4-7: É o inicializador do p5, que cria uma com o tamanho especificado.
9-18: É o loop que é chamado todo frame, caso a variável loop seja maior ou igual a 1, torna-se transparente a tela, aumenta-se a escala em 10, move-se aleatoriamente o centro do desenho, e roda-se a função que desenha a casa. Finaliza convertendo a imagem em base64 alocando-a na variável frame.
20-25: É a função que desenha a casinha em si. Primeiro ela limpa o canvas, depois usando um triangulo e dois retângulos, desenha uma ilustração básica de uma casa com telhado e porta.
Tal é o fluxo necessário para a integração de skecthes dentro do godot, e o funcionamento da cena code_edit.tscn.
Dando sequencia, temos a cena “teste js.tscn”:
Sua estrutura de nodes, muito mais complexa, contem por exemplo, uma instancia da cena code_edit.tscn.
Vamos a sua estrutura:
0·Node3D: Raiz da cena, ponto de origem tridimensional.
1··SubViewport: Display Virtual onde é renderizado o conteúdo de “2·”.
2··TextureRect: Retângulo que recebe a textura de “3·”.
3···code_edit.tscn: Instancia do code_edit.tscn, que obtêm a referencia de “2·” e atualiza sua textura a cada frame com o conteúdo da pagina HTML.
4··Node3D: Outra ponto de origem 3D, serve para isolar “5·” do resto da geometria da cena.
5···Sprite3D: É o retângulo 3D que recebe a textura de “1·”, é o que se visualiza no ambiente tridimensional.
Podemos então chegar na cena geral, a demo_scene.tscn. Aqui teremos a camera360. Ela também contem nodes que contem cenas que contem cenas, vamos a sua estrutura:
0·TextureRect: Raiz da cena, e do projeto. É onde a renderização final ocorre.
1··SubViewport: Monitor virtual onde a cena 3D e a camera360 habitam. É a saída da camera360, já em fisheye fulldome
2···camera360.gd: É uma câmera 3d estendida pelo plugin camera360. Ele gera 5 câmeras virtuais que são cada apontadas para uma face do cubo. Um código junta todas e converte em uma imagem circular.
3···Node3D: Uma origem 3D para a cena 3D “teste js.tscn” em si.
4····”teste js.tscn”: A cena que contem os elementos visuais estruturados.
5·····SubViewport: Tal como antes: Display Virtual onde é renderizado o conteúdo de “6·”.
6······TextureRect: Tal como antes: Retângulo que recebe a textura de “7·”.
7·······code_edit.tscn: Tal como antes: Instancia do code_edit.tscn, que obtêm a referencia de “6·” e atualiza sua textura a cada frame com o conteúdo da pagina HTML.
8·····Node3D: Tal como antes: Outra ponto de origem 3D, serve para isolar “9·” do resto da geometria da cena.
9······Sprite3D: Tal como antes: É o retângulo 3D que recebe a textura de “5·”, é o que se visualiza no ambiente tridimensional.
10····WorldEnvironment: É utilizado para substituir o céu virtual predefinido por um cinza.
Isso conclui a demonstração da implementação.
Discussão:
Então, tal ecologia entre ferramentas de criação JavaScript e sua renderização em tempo real para dentro do Godot, permite uma altíssima flexibilidade expressiva. A aliança entre GDScript e JavaScript, através do navegador, habilita uma dimensão criativa emancipadora, onde com apenas um “browser”, se pode construir diversidades de expressões, no nosso caso, criações que são já adaptadas ao fulldome, diretamente.
O navegador, ferramenta essencial para o uso do JavaScript, e acesso a suas bibliotecas, traz essa liberdade de campo de escolhas, permitindo o uso de um vasto e já testado conjunto de ferramentas criativas, não limitando-se apenas ao p5.js. three.js poderia ser usado, e com mais desenvolvimento e a construção de um “buffer” de áudio, até mesmo a tone.js, etc.
Porem, tal flexibilidade tem um custo na performance, e este custo pode ser otimizado ao máximo, ainda mais sendo uma necessidade de interoperatividade.
Proposta de servidor monolitico:
Isso nos leva a um redesenho do sistema como um todo, sem afetar sua funcionalidade.
Atualmente, nesta implementação, Godot Engine é utilizada para: Editar uma cena 3d; Construir uma ponte entre o navegador e Engine; Deformar o campo tridimensional em uma imagem bidimensional adequada; Operar parâmetros automatizáveis. Ou seja, animar o projeto.
O que se propõe, e poder desacoplar tais operadores em módulos interoperáveis, pensando até mesmo no processo de migração para Blender, onde animações mais complexas podem ser realizadas.
Em primeira instancia, o modulo principal deste sistema, é certamente a ponte JavaScript, algo que Godot entregou nativamente.
O que se propõe é construir um servidor, seja web, seja NodeJS, etc. Com tal servidor um serviço de “telas em paralelo” pode ser construído.
Um rascunho de suas funcionalidades seria:
Um dicionario de iframes, podendo receber alguns comandos: Criar novo iframe -> retorna um id; Deletar iframe id -> Retorna sucesso; Atualizar código iframe -> retorna sucesso; Renderizar próximo frame -> processa e retorna imagem do frame.
Tal conjunto de operações, permitiria acessar via simples protocolo de rede, um serviço que entrega a mesma funcionalidade implementada pelo “code_edit.tscn”, praticamente. Com tal serviço, seria possível reescrever a implementação Godot, que desacoplar-se-ia de sua ponte-JavaScript nativa, permitindo utilizar a versão nativa de plataforma, ganhando bastante performance. Juntamente, permitiria que o acesso ao render JavaScript seja feito por qualquer interface, a priori, Blender e TouchDesigner. Sendo possível então utilizar das ferramentas criativas nativas da web, desacoplado da web em si. Além disso, servidores de alta performance podem ser alocados como “render-farms”, permitindo que maquinas de baixa performance possam ter acesso ao fluxo criativo de alto nível.
Blender. Possível ecossistema criativo unificado?
Tendo em vista que o processo de criação baseado em Godot/JavaScript foi iterado, aliado as considerações de ser uma ferramenta de programação, e não de modelagem/composição visual, buscou-se uma ecossistema que pudesse abarcar todas as necessidades criativas da pequisa.
Blender mostrou-se um competente candidato, sendo não estritamente paramétrico, porem parametrizável, não programável, mas scriptavel, e com um conjunto de modelagem de texturas nodal, animação, renderização, pintura, e tantas outras competências a serem melhor entendidas.
Inicia-se uma mudança de paradigma no escopo da pesquisa, indo de Touch/Godot/JS, para uma criação focada na modelagem/rig/animação 3d, majoritariamente Blenderiana.
Acredito que uma inbricação vai ocorrer, e todas as plataformas vão continuar sendo utilizadas, porem, tendo o Blender como paradigma comum, fluirá interoperação criativa, certamente.