BlendELF mão na massa: testes e observações
Após uma semana de testes consegui estabelecer um padrão para a engine. E durante a semana postarei um mini-tutorial básico.
E qual a vantagem de se ter uma situação dessas se a GE do Blender é tão forte?
Primeiro eliminar o peso dos dados de edição, segundo ter um mecanismo de teste diferente do Blender.
Há também uma questão de carisma, eu simpatizei imediatamente quando percebi que o autor seguia um caminho paralelo ao meu.
Exportador do Blender
Primeira coisa que chama a atenção é a facilidade, roda-se o exporter e tem-se um cenário completo exportado.
A segunda é que nem todos os atributos suportados na BGE são suportados pela BlendELF, como por exemplo múltiplas camadas de textura. Se quiser usar iluminação é pela GLSL da própria BlendELF mesmo.
O que pra mim não significa tanto, já que todos os materiais tinham que ser setados manualmente quando exportados para a OGRE (não necessariamente uma falha do exporter do OGRE, mas um fator de que a OGRE tem muuuuto mais recursos no seu script de materiais que a BGE).
Na verdade abrindo-se o editor você verá que ele so suporta os mapas: difuse, normal, displace, height e specular.
No entanto o difuse map pode conter o canal alpha.
Quanto à animação por bone, é imprensidivel tudo estar na escala 1x1 (malha e armature) e no mesmo pivo (ponto zero). Se não da pau total na animação (distorções bizarras)
Coding
Parti para o experimento com scripts, há métodos para você capturar os “atores” da cena, e um esquema para vc criar um script lua dentro do Blender e associa-lo à instância do objeto em cena.
No entanto quando chamei uma função global pelo script atrelado à um objeto gerou uma “falha de segmentação”.
O modelo de programação não lembra a orientação a objetos tão bonito que estamos acostumados, em verdade me lembra meus primeiros experimentos de linkagem com Lua o que faz pensar que esta é a “primeira viagem” do autor neste tipo de linkagem.
Ex.: meuAtor = elf.GetActorByName(“zezinho”)
Meu projeto preferi adotar esta forma, onde uma metatable gerada pela linguagem host guarda as funções, muito mais elegante.
Acho que para um objetivo de testes dá pra encapsular usando a implementação de classes para Lua que ando usando no projeto de I.A. assim eu farei:
Animação também tem que ser disparada por código.
Detectar colisão é uma tarefa relativamente simples. Mas tive que entrar no forum da BlendELf para saber detalhes de como fazer os testes.
De um modo facil:
O difícil é saber como manusear essas coisas. Por exemplo o objeto collision retornado por GetActorCollision esta listado na referência da API Lua do próprio site, mas no formato tipoRetorno = elf.NomeDaFuncao( lista de parametros... )
De fato a documentação é bastante escaça, apesar de completa. Tive que fivar vasculhando a API para descobrir quais os elementos eu poderia pegar com as funções do BlendELF e criei a função getColisionInfo(objCollision).
Para matar minhas duvidas e saber qual é a estrutura deste objeto tive que baixar o source de C++ e analisar as estruturas nos headers.
Por exemplo o userdata correspondente ao objeto collision é um ponteiro para esta estrutura descrita no Physics.h
Outro fator comprometedor é que não obtive um bom resultado (pelo menos nesses primeiros testes) com colisão em malha animada.
A ideia é jogar uma malha simples em volta do personagem como na imagem, e usa-la como teste de colisão. No entanto a engine não retornou resultados de colisão. Vou fazer mais testes, claro.
Agradecimentos à TiZeta que deixou este modelo para download.
Encapsulamento, levels, shaders
Encapsular os dados parece ser simples, o source da engine é bem pequeno. Oque podera facilitar trocar o sistema de leitura de arquivo por um de leitura de banco de dados (aparentemente muuuito mais facil que reescrever o sistema da OGRE pra isso).
A criação de levels com gargas posteriores esta descrita nos foruns, e exige que se tenha um certo trabalho pesado num gerenciador de recursos em Lua, nada que seja tão negativo ja que é uma engine leve pra jogos casuais.
Shaders, você fica limitado aos existentes na própria engine, a não ser que escreva a implementação em C++ ou C# apartir dos fontes.
Suporte e documentação
A documentação é bem precária, apesar de simples para quem já tem conhecimento em engines 3D/2D.
O forum é bem bombado, tem um numero de acessos bom, e o autor aparente ter tempo e disposição para responder, até perguntas esdruxulas dos usuários.
Na verdade ele foi até bem rápido e atencioso quando lhe perguntei.
Futuro?
É interessante, trata-se de um projeto de faculdade mas caiu num certo carisma da galera da Blender Artists
Em verdade tive 7 visitas neste blog domindo de gente procurando por essa engine.
Se o autor receber incentivo pode ocorrer algo como no caso do Sculptriz, onde o autor foi contratado por uma empresa grande (e infelizmente o programa foi vendido junto).
Conclusão
Com uma qualidade de recursos gráficos inferiores ao OGRE ela acaba sendo muito prática em velocidade pois não ha nada oque configurar.
Desenvolver lógica nela é mais pratico e gostoso que no Python.
Já que usa Lua nativamente posso incorporar ela nos testes do meu jogo, ou seja trabalhando direto no 3D ao invés de fazer testes com a Plataforma Flash 2D.
Mesmo que a longo prazo o criador desista da engine, eu ainda posso usa-la para os testes iniciais do jogo. Ou seja o núcleo pesado que eu estava desenvolvendo pode ficar para depois e eu terei mais animo ao ver as coisas andando na tela.
Downloads
BlendELF do site oficial: BlendELF
O fonte das imagens acima, basta coloca-lo na pasta do BlendELF ou baixar esta versão mini.
Recomendo ^_~
E qual a vantagem de se ter uma situação dessas se a GE do Blender é tão forte?
Primeiro eliminar o peso dos dados de edição, segundo ter um mecanismo de teste diferente do Blender.
Há também uma questão de carisma, eu simpatizei imediatamente quando percebi que o autor seguia um caminho paralelo ao meu.
Exportador do Blender
Primeira coisa que chama a atenção é a facilidade, roda-se o exporter e tem-se um cenário completo exportado.
A segunda é que nem todos os atributos suportados na BGE são suportados pela BlendELF, como por exemplo múltiplas camadas de textura. Se quiser usar iluminação é pela GLSL da própria BlendELF mesmo.
O que pra mim não significa tanto, já que todos os materiais tinham que ser setados manualmente quando exportados para a OGRE (não necessariamente uma falha do exporter do OGRE, mas um fator de que a OGRE tem muuuuto mais recursos no seu script de materiais que a BGE).
Na verdade abrindo-se o editor você verá que ele so suporta os mapas: difuse, normal, displace, height e specular.
No entanto o difuse map pode conter o canal alpha.
Quanto à animação por bone, é imprensidivel tudo estar na escala 1x1 (malha e armature) e no mesmo pivo (ponto zero). Se não da pau total na animação (distorções bizarras)
Coding
Parti para o experimento com scripts, há métodos para você capturar os “atores” da cena, e um esquema para vc criar um script lua dentro do Blender e associa-lo à instância do objeto em cena.
No entanto quando chamei uma função global pelo script atrelado à um objeto gerou uma “falha de segmentação”.
O modelo de programação não lembra a orientação a objetos tão bonito que estamos acostumados, em verdade me lembra meus primeiros experimentos de linkagem com Lua o que faz pensar que esta é a “primeira viagem” do autor neste tipo de linkagem.
Ex.: meuAtor = elf.GetActorByName(“zezinho”)
Meu projeto preferi adotar esta forma, onde uma metatable gerada pela linguagem host guarda as funções, muito mais elegante.
Acho que para um objetivo de testes dá pra encapsular usando a implementação de classes para Lua que ando usando no projeto de I.A. assim eu farei:
meuAtor = AtorELF.new()
(onde faço todo o processo elf.GetActorByName....... e também encapsulo todo o sistema necessário)Animação também tem que ser disparada por código.
elf.LoopEntityArmature( model_body, 1.0, 250.0, 30.0 )
Até aqui nada demais, a atual API Python do Blender não da suporte à muitos recursos.Detectar colisão é uma tarefa relativamente simples. Mas tive que entrar no forum da BlendELf para saber detalhes de como fazer os testes.
De um modo facil:
function actorCollizionHandler()
-- loop through the entity collisions
local actorcolidor = elf.GetActorByName(scn,"SphereCol")
for i = 0, elf.GetActorCollisionCount(actorcolidor)-1 do
local col = elf.GetActorCollision(actorcolidor,i)
local data = getColisionInfo( col )
print( data.nor.x, data.nor.y, data.nor.z, elf.GetActorName(data.act) )
end
end
O difícil é saber como manusear essas coisas. Por exemplo o objeto collision retornado por GetActorCollision esta listado na referência da API Lua do próprio site, mas no formato tipoRetorno = elf.NomeDaFuncao( lista de parametros... )
De fato a documentação é bastante escaça, apesar de completa. Tive que fivar vasculhando a API para descobrir quais os elementos eu poderia pegar com as funções do BlendELF e criei a função getColisionInfo(objCollision).
Para matar minhas duvidas e saber qual é a estrutura deste objeto tive que baixar o source de C++ e analisar as estruturas nos headers.
Por exemplo o userdata correspondente ao objeto collision é um ponteiro para esta estrutura descrita no Physics.h
struct elf_collision {
ELF_OBJECT_HEADER;
elf_actor *actor;
elf_vec3f position;
elf_vec3f normal;
float depth;
};
Outro fator comprometedor é que não obtive um bom resultado (pelo menos nesses primeiros testes) com colisão em malha animada.
A ideia é jogar uma malha simples em volta do personagem como na imagem, e usa-la como teste de colisão. No entanto a engine não retornou resultados de colisão. Vou fazer mais testes, claro.
Agradecimentos à TiZeta que deixou este modelo para download.
Encapsulamento, levels, shaders
Encapsular os dados parece ser simples, o source da engine é bem pequeno. Oque podera facilitar trocar o sistema de leitura de arquivo por um de leitura de banco de dados (aparentemente muuuito mais facil que reescrever o sistema da OGRE pra isso).
A criação de levels com gargas posteriores esta descrita nos foruns, e exige que se tenha um certo trabalho pesado num gerenciador de recursos em Lua, nada que seja tão negativo ja que é uma engine leve pra jogos casuais.
Shaders, você fica limitado aos existentes na própria engine, a não ser que escreva a implementação em C++ ou C# apartir dos fontes.
Suporte e documentação
A documentação é bem precária, apesar de simples para quem já tem conhecimento em engines 3D/2D.
O forum é bem bombado, tem um numero de acessos bom, e o autor aparente ter tempo e disposição para responder, até perguntas esdruxulas dos usuários.
Na verdade ele foi até bem rápido e atencioso quando lhe perguntei.
Futuro?
É interessante, trata-se de um projeto de faculdade mas caiu num certo carisma da galera da Blender Artists
Em verdade tive 7 visitas neste blog domindo de gente procurando por essa engine.
Se o autor receber incentivo pode ocorrer algo como no caso do Sculptriz, onde o autor foi contratado por uma empresa grande (e infelizmente o programa foi vendido junto).
Conclusão
Com uma qualidade de recursos gráficos inferiores ao OGRE ela acaba sendo muito prática em velocidade pois não ha nada oque configurar.
Desenvolver lógica nela é mais pratico e gostoso que no Python.
Já que usa Lua nativamente posso incorporar ela nos testes do meu jogo, ou seja trabalhando direto no 3D ao invés de fazer testes com a Plataforma Flash 2D.
Mesmo que a longo prazo o criador desista da engine, eu ainda posso usa-la para os testes iniciais do jogo. Ou seja o núcleo pesado que eu estava desenvolvendo pode ficar para depois e eu terei mais animo ao ver as coisas andando na tela.
Downloads
BlendELF do site oficial: BlendELF
O fonte das imagens acima, basta coloca-lo na pasta do BlendELF ou baixar esta versão mini.
Recomendo ^_~