Este blog esta em reforma no momento.

Clarisse

Hoje vou prestar homenagem à uma companheira que esteve junto desde os primeiros passos da publicação desse projeto.

Ela me acompanhava nas madrugadas as vezes no meu colo ou quase sempre entre o vão do teclado e monitor.

Na verdade ela achava que a máquina era a casa dela.

Ela me mostrou que muito doque eu conhecia sobre gatos era pura lenda. E nela vi amizade e companheirismo.

Nem sempre nos entendíamos, o que rendeu até um acréscimo num personagem do jogo inspirado em um dos seus momentos de crise.

Outras vezes era apegada demais, como em tantas que tive que correr para lavar roupa de cama por ela ter "me" demarcado.

Ela chegou de um jeito inesperado e misterioso. Ouvi um miado na porta abri e ela entrou.

E como num estranho círculo ela se foi, sem explicação e da mesma forma que eu fui o primeiro da família a lhe ver também fui o ultimo.

Clarisse morreu 9:00 da manhã de uma quinta (26/01/2011) com uns 2 anos. De causas desconhecidas após passar por um procedimento rotineiro numa clinica veterinária.

De cada 100 que passam por uma castração 1 tem complicações e minha filinha foi sorteada.

Ela deixou dois filhos que vão ficar comigo e muita saudade.

Fazendo Shaders

Hoje fiquei lembrando de um método de aprendizado que uso desde meus cinco anos: "Se não entende, pega o bagulho e desmonta!"
Nem todos os brinquedos daquela época sobreviveram. Mas hoje em dia temos esse processo mais formalizado.

De fato cansei mesmo de tentar pegar código pronto e tentar juntar os pedaços para um resultado. A maioria dos projetos hoje em dia faz isso.
Mas não estava dando um resultado muito bom, tendo conflitos, dor-de-cabeça pra entender o shader, conflitos de linguagens, de perfis e minúsculos fatores. As vezes eu simplesmente esquecia os drivers de vídeo desconfigurados e não compilava!
Além doque a maioria dos exemplos que vi era de gente pegando os códigos existentes e adaptando.

Procurando tutorial ?
Eu escrevi o texto acima para os que vieram atrás de código para seus projetos, mas deixei os links que vocês procuram no final do post.
Fica esse alerta, a programação de shaders é de baixo nível, mas muito recompensador.

Os passos
 Quando o assunto é shader você tem quase nenhum material em português e muito falatório sobre o assunto em inglês. E nenhuma referência para newbie para aquilo que você quer fazer.

Comecei com um esdrúxulo void main(void) pegando a componente de cor e uns 3 ou 4 exemplos de toon shader.

O algoritmo do toon é fácil, você pega a intensidade do brilho e joga numa sequência de ifs. Simplesmente a coisa a parte mais babaca de programação. Outra vantagem de eu estar fazendo o shader  é que eu posso customizar ainda mais o sistema, ou eu faço uma textura linear de entrada ou uma array.
 A iluminação "per pixel" que começou a dar trabalho. Não tanto o de copiar e colar, mas ir lendo os comandos passo a passo.
Do exemplo acima eu fui sondando, essa parte de programação é muito voltada a matemática, não aquela chata que agente fazia decorando formulas estranhas, mas exige bastante conceito que eu não aprendi na escola. E a capacidade de "visualizar" a equação funcionando, "ver" a equação sempre foi a melhor maneira de aprender pra mim doque decorar a formula.
 Me acalmei e vi que era só eliminar todo o calculo correspondente a cor na equação. E pronto, tinha um valor para ser analisado e dividido no degrade.
Tem uma hora que me confundo entre usar um + (adição) e um *(multiplicação) na equação, mas é só fazer uma "tentativa e erro" que acerto.

A luz foi resolvida de forma mais simples, eu entro com os valores na mão ao invés de usar os definidos dentro da OpenGL, isso vai ser bom para controlar os pontos de luz de entrada. No caso do toon shading é uma escolha melhor já que a luz nem sempre fica boa se for muito realista, então se eu controlar manualmente por script deve dar um resultado melhor.
Agora o passo do normalmap, acabou virando uma técnica vital e me surpreendeu a facilidade que foi inserir ele.
A única coisa problemática foi computar a exata direção do vetor da luz e o vetor da normal na posição correta.
O shader esta quase pronto, eu deixei de lado coisas como os dados de cor do vértice, oque limita o sistema a sempre precisar de texturas para todos os modelos.
Não creio que vai ser preciso uma versão mais simples desse shader, eu poderia usar os dados de cor dos vértices por exemplo mas se o sistema não suportar texturas eu deixo a cargo da OGRE escolher a técnica mais correta.

Mas uma mais complexa com o efeito paralax sim tem que sair, no entanto esse me dá medo! Mas é o desafio para a próxima semana.

Links:
Código fonte do shader *
Tutorial de Toon Shading e GLSL
Tutorial no NeHe
Referência da Blender Game Engine para o 2.5x
Realmente grande site de tutoriais de Blender
www.khronos.org

Discussões e fóruns que pesquisei:
link1 link2 link3 link4  link5 (++) link6 e mais....

* o código está conforme oque se vê aqui, não esta pronto mas funciona com duas texturas em um material. Fica como contribuição para novos projetistas.

Pensando em RPG de novo

Já perdi a conta de quantas vezes falei de lógica de RPG aqui, e acho que ainda tem “pano pra manga”, quanto mais eu analiso mais eu vejo que um RPG, mesmo o mais simples, é composto de minúsculas regras que se amontoam para interagir.
Minha técnica é fazer um simulado mental de uma ação e tentar juntar os recursos que preciso, em vários momentos isso se mostrou monstruoso, dado que vários fatores interferem juntos no resultado.

“No começo do jogo Cibele ganha do mega-arqui-mago-fodão o Anel do Senhor da Guerra que lhe permite empunhar qualquer arma do jogo”

Um simples paragrafo muito comum que vai ajudar o herói de uma campanha épica, mas que implica em ser transformado em realidade, oque me faz pensar que o anel possui uma função que interfere nos testes quando Cibele tenta carregar qualquer arma só pra dizer: -sim ela pode carregar.
Como eu faço isso? Digo pra sistema que o “não pode” deve mudar para “sim”? Ou na hora do teste digo que a força dela é “infinita”, se digo isso quando devo dizer?
Me veio uma solução na cabeça, de atribuir propriedades à um elemento dessa forma um teste caça nelas a que lhe convém.

Proposta:
Atos
+ e - = Transação
< e > = Ação

ato( Cibele > Cobra )  =  Ataque normal
ato( Cibele.magias.fireball  > cobra ) = Ataque mágico, a função ato() recebe nulo se ela não puder usar a magia.
ato( Cibele < veneno )
ato( Cibele < Cobra )
ato( Cibele < Cobra.veneno )

Os atos operam entre atributos e modificadores.
De um modo geral quando dois personagens interagem é um ataque.
Cibele > cobra = chama a rotina de ataque. A rotina padrão faz com que a cobra receba os dados de dano. O dano nada mais é que um modificador de efeito imediato ou não.
Exemplo: se Cibele ataca normalmente o dano é físico (atributo força da personagem + força da arma de mão) cria-se um Modificador chamado dano e passa-se ele para cobra que faz os testes em sua função de receber dano. assim: cobra.recebeDano( dano )
Como dano é um modificador, ele pode alterar os atributos, geralmente “vida” diminuindo-a.
Aqui começa o problema do RPG, diminuir a vida implica em fazer um teste se você pode diminuir esse atributo.

Um cenário tipico:
Cibele.modificadores + ResistenciaAVeneno(+5)
Cibele.equipamento + CotaDeMeiasVivarina
Cibele.equipamento + AnelAntiCobra
Cobra > Cibele -- ou Cibele < Cobra

Na primeira linha Cibele recebe direto um modificador na sua tabela de modificadores. Assim dizemos ao sistema que ela é naturalmente resistente ao veneno (+5).
Na segunda linha ela recebe uma Cota de Meias Vivarina, que suportam perfuração de faca, flecha e bala (exceto as facas Guinsu). (armadura/resistência +20)
Na terceira ela ganha um Anel Anti Cobra, que dá 30 de dano no ofidio que tocar na pele dela.
A ultima linha a cobra ataca Cibele >. Essa função > desencadeia o mecanismo de teste do de ataque do personagem.
A função de ação passa primeiro pelos testes básicos como esquiva e defesa que diminuem um pouco ou todo o dando.
Depois pelos modificadores da personagem, depois pelo equipamento em uso e executa suas funções de comparação. Se o modificador ResistenciaAVeneno achar o valor “veneno” nas informações de ataque ele tira os 5 do valor que foi infligido.
Por ultimo o equipamento MeiasVivarina fazerem um teste e verem que o valor “perfuracao” deve ser ignorado e que o objeto também tem um “cobra” no meio e aplicam a função AnelAntiCobra > Cobra.

Note que a primeira parte do teste usa-se os valores constituintes dos próprios personagens e depois os testes secundários com os modificadores.
O grande problema é que um modificador também interfere em um atributo! Em outras palavras o atributo também é uma classe que faz testes e seus objetos precisão conhecer o seu contéiner.

E ainda tenho que optimizar isto para que não ocorra um teste desnecessário a cada frame (uma placa hi-end ultimamente dá em torno de 500 a 1000 frames por segundo), seria um esforço inútil calcular toda a lógica para isso, por isso as classes contém um mecanismo de cache.

Por ultimo uma modificação a informar no framework descrito acima é a substituição da biblioteca de classes que não estava mais sendo atualizada pelo autor.
Agora estou usando a LOOP. Muito prática.

Postagens relacionadas
Incorporando banco de dados
Progeto de I.A.