Este blog esta em reforma no momento.

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:
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 ^_~

Reparando a Wacom

As canetas Wacon são os equipamentos mais singulares que temos para criar arte digital, mas quando quebram... o transtorno psicológico é fenomenal.

Esses dias cheguei em casa e logo na primeira sentada na máquina meu corpo gelou. Minha tablet, investimento alto e válido que me deixou contente por dias agora não estava mais operando.


Uma minuciosa louca busca me levou à este blog: looplemonkey.blogspot.com
Baseado na história de sucesso dos mesmos, nas dicas, na constatação que tudo estava fudido e no preço de R$ 187,00 uma nova,me pus à ação

Reparos são a pior parte da informática, principalemte para programadores, que odeiam manutenção, agora quando o dano vai além da simples troca de peças e envolve a parte eletrônica da coisa todo técnico de informática esta totalmente sozinho no mundo.

Primeiro o material, um pouco diferente do nosso amigo do blog:

Fita crepe, Super Bonder, alicate, ferro-de-solda, pinça, marca-texto e coca-cola.


Na fita crepe tem que ser generosa, pois o alicate vai escorregar, sério, você vai fazer força mesmo, mas tem que ser na mão (tentei com uma morça, mas não deu muito certo). Use a Coca-cola para se acalmar.

Localizando a ponta de ferrite quebrada, marquei as pontas dos fios com marca-texto e removi a borracha da parte trazeira e depois a ponta quebrada.

Soldei o bastão de ferrite da borracha onde estava a ponta, seguindo a marca feita com o marca-texto para não correr risco de inverter uma polaridade (geralmente esses rolamentos magneticos tem um certo grau de frescura).


Testei na maquina e fiquei feliz e aliviado.

Com minahs mãos, agora sem tremer mas ainda suadas, soldei a ponta quebrada na trazeira (borracha) e colei o bastão com super-bonder.
Infelizmente a borracha não rescusitou.

Então testei com um pouco e rascunhei outro dos personagens que só tinham rascunho em textos. João Sem Dente é um mecânico com um sorriso milagroso no rosto, achei que combinaria com a situação.

Reparo 60% algodão ^_^
Let’s Rock

BlenderELF Open Source 3D Game Engine

BlenderELF 0.9 Beta 2
Sem duvida em dados momentos agente se espanta, nem dava mais importância ao fórum onde fui achar isso.

Aparentemente o autor teve umas ideias paralelas as minhas, sem se dedicar à um game, ele produziu uma engine interessante.
Estive olhando os fontes e esta semana tentarei fazer alguns testes.



Mesmo que ela não consiga ser 100% usável, ao menos pode significar um avanço em alguns testes de modelos. Pois sua interface (de código) é bem amigável e parece ser fácil customizar algumas coisas.
Ou no mínimo sera uma boa referência.

Prós:
Possui uma API em c++, oque possibilita uma expansão promissora.
Já usa Lua
Aparenta ser extremamente fácil de incorporar ao material já produzido
Multiplataforma

Contras:
O FPS não é nada impressionante
O script lua parece ser obrigado a fechar em um loop principal
Não sei se o autor irá dar continuidade com o projeto à médio prazo
Não se baseia na OGRE (ok, nada de renders absurdos)

OGRE 1.7 Cthugha - Instalando no Ubuntu

A instalação da OGRE foi de fato muito mais simples nesta versão. Não havendo necesidade de compilação.
Bastou anexar estes dois PPA ao sistema:
https://launchpad.net/~ogre-team/+archive/ogre
https://launchpad.net/~andrewfenn/+archive/ogredev
Entrar no Synaptic e baixar tudo que for OGRE 1.7 normalmente.
Depois para resolver problemas de endereçamento de bibliotecas compartilhadas bastou criar uma nova referência:
sudo ln -s /usr/lib/OGRE /usr/local/lib/OGRE

P.S.: Não esqueça de baixar coisas como FreeImage e OIS também (versões DEV)

Ainda não fiz todos os testes, mas aparentemente esta sem problema nenhum, compilando todos os CG-Programs (que são a parte mais afetada por problemas no sistema)

Daqui pra frente é eu balbuzeando minha opinião...
Muitos de meus problemas com a OGRE, com certeza se devem à escolha imediata da arquitetura de 64-bit como padrão.
Somando-se a natural migração lenta de código legado, que aparentemente deve durar uns 200 anos, temos sempre as mudanças internas nos sistemas operacionais que por motivos de migração sempre tem pastas como: lib/lib64 system/system32/system64

A escolha no entanto foi muito gratificante quanto à produção de média, já que agente se beneficia de um ambiente mais parrudo e rápido.

Estou também mudando parte da estrutura interna do jogo, seguindo-se o embalo dos demos da OGRE idealiza-se a utilização da Janela de Aplicação como ponto principal do jogo.

Com mais tempo de estudo já da pra enxergar que se pode usar um conjunto mais separado de classes para isto. Assim estou criando uma só para gerência de resources e inicialização da aplicação. Não só fica mais bonito e organizado, como também me permite uma melhor comunicação entre os módulos.

Lógico tem um monte de coisa que não compensa fazer diferente do código exemplo, há muitos desvios no código para casos de multi-plataforma. Desvios de Windows, Linux e Mac em todo canto enfim a velha dor de cabeça mesmo assim tem tanta coisa no OGRE que deixa o C++ quase tão portável quanto o Java. Em verdade muitas vezes perdi tempo implementando bibliotecas que a OGRE ja implementava de antemão (algumas até exageradas, podendo ser subistituidas facilmente por bibliotecas menores e mais leves, mas não menos funcionais).

Concept de bolsa de iventário

Suponhamos uma bolsa clássica (bag) de RPG.
Em seus formatos programacionais mais comummente usados nós temos uma matriz de slots onde podemos encaixar os objetos.
Tipo um arco como 3x4 slots, uma espada curta 1x3 e assim por diante.

Esta semana pensei em algo diferente enquanto jogava Resident Evil percebi um pequeno detalhe: A dificuldade crescente em achar espaço no “case” de armas.

Comecei a idealizar este conceito de bag, aprimorado, usando a Box2DFlash.
Dá pra improvisar bastante nas “enfiações” de coisas.
Outra vantagem da Box2D é que mesmo que a implementação de render do Flash dentro do ambiente C++ não se tornar viável, o Box2D é escrita originalmente para C++.

Quem tiver interese em estudar um pouco a Box2D, aqui vai um pequeno e funcional trecho de código optimizado para a versão 2.1a (a mais nova até esta data)

GUI - Hikari bati o martelo em OGRE e Flash

Hikari surgio à alguns anos nos foruns de OGRE criiado pelo ajs15822.
Uma implementação até muito comum de se inserir SWF em aplicações.
https://www.ogre3d.org/forums/viewtopic.php?f=11&t=41999&start=325
No entanto o Flash torna a tarefa de desenvolvimento de GUI muito estupidamente fácil.
Além de contar com a facilidade de desenvolvimento de gráficos, a plataforma Flash conta também com as poderosas bibliotecas de GUI do ASWing e do Flex. E miriades de bibliotecas de efeitos.
Uma das ideias que acabei de ter é manuzeando a famosa "bag" de rpg. Ao invés de usar o sistema de slots, e ter que programar aquele mundarel de tiles, pensei em montar algo com a Box2dFash. Tive uma boa experiência com ela enquanto montava meu site pessoal (no presente momento fora do ar por rolos com meu domínio).
Show case do ASWing
A ASWing também é uma biblioteca muito impressionante e eficiente.
Começo dos experimentos de GUI em nível de produção ja nesta semana.

^_~