Fim de semana rendeu

Bom, ao menos a fada esta menos pior de mapeamento. Deu bug no meio do processo do normalmap. Tive que refazer o sculpt 5 vezes. Segui uns conselhos do Mauricio Cunha e do Rodrigo e acertei bastante a mão.
Eu também fiz o rig, depois vou por ela no youtube.

Comecei também com alguns objetos de cena. alguns foram bem simples. A cadeira é que deu mais trabalho. Pena q no Blender não há como cortar faces por faces (não q eu tenha tido despreguiça de procurar um script p issu).
Fis também a caminha, achei mais lógico um simples colchão surrado, afinal Cibele é praticamente uma eremita vivendo da venda ocasional de hervas, sem muita grana pra móveis.
Eu fico muito duvidoso sobre a real quantidade de poligonos que podemos usar. Fala-se em economizar, mas mais e mais veem saindo consoles potentes e o hardware grafico também não fica atráz, mesmo em maquinas mais modestas. Eu jogava Fable na minha GeForce 5200, sofria mas jogava.
Resolvi dar uma arredondada mais decente na orelha, e não me preocupei muito com a perna.
Este urso deve ter ficado em uns 200 tri, eu n ontei.

---

Eu ja devo ter postado isso, não lembro, sobre a dificuldade de acertar a cor. Hj consegui uma foto mais realista do problema. No entanto não sei ainda. Vou essa semana mandar revelar a foto, impressa a percepção das corer é muito maior (infelismente também depende de onde vc revela).
Deu trampo issu, tive que montar a camera num tripé, e ficar testando várias configurações. Essa foto ai foi batida em quase 1 segundo (1/2 na verdade) de exposição, por issu não aparece aquela mancha do monitor de tubo, a imagem dele foi se acumulando na foto.
Bom, ainda tive q Gimpear a imagem p regular a itensidade da cor, ainda ta uns 90~95% doque realmente vejo, supondo-se que não sou dautonico.
Informações da propria camêra:
Tipo de imagem: jpeg (Formato de imagem JPEG)
Largura: 1680 pixels
Altura: 1260 pixels
Marca da câmera: FUJIFILM
Modelo da câmera: FinePix S9100
Data da foto: 2009:03:28 16:07:45
Tempo de exposição: 1/2 seg.
Valor da abertura: 6,60 EV (f/9,8)
Taxa de velocidade ISO: 200
Flash disparado: Flash did not fire, compulsory flash mode.
Modo de medição: Padrão
Programa de exposição: Manual
Distância focal: 7,6 mm
Aplicação: GIMP 2.6.1
Copyright: Marcos Augusto Bitetti

Agora oque rendeu mesmo é o material para o próximo post, na noite de sabado fiz um sketch, e na manhã de domingo escrevi a história. Eu ainda preciso estudar bem mais sobre a arte de escrever, pois a ideia era cada personagem ser apresentado de um geito. Mas o concept ficou legal ^_^
Aguardem....

Lime

Bom, mais uma semana e mais um personagem.
Houve um atraso, mais foi por um bom motivo. No entanto, ja fiz muita coisa nesta! Estou realmente pegando o jeito. Ja não olho mais para o "unwrap" do Blender com os mesmos olhos, agora olho com olhar de fascinação por essa santa ferramenta!

Após o sculpt passei a demarcar o grosso da pintura no Gimp, e posteriormente passei ao Blender onde dei os ultimos retoques nos detalhes da textura. Resolvi fazer as extremidades e pintas rosas, como se fosse um pequeno animal (Ramister me inspirando).
De fato ela é muito pequena, por issu dei uma economizada nos poligonos. E por sorte o exporter da OGRE tem uma regulagem de LOD conforme a distância, que irei reduzir em 10 vezes para esta personagem. (LOD - Level Of Detail - Diminui a quantidade de poligonos conforme a distância).
Aqui também não aparece a textura da asa, eu estou dividindo os personagens em materiais solidos e transparentes. Isso porque o transparente necessita de uma textura para alpha, e alguns parâmetros diferentes de configuração.
Bom, com certeza eu exagerei nos detalhes, mas eu me empolguei... acontece muito.
Infelizmente o normalmap ficou, digamos,... um lixo. Vou ter q refazer. Quem sabe até aumente os olhos.
Ela acabou ficando bem acima de onde eu queria chegar, tem 1218 triangulos de malha. Para um ser que inicialmente seria nada mais doque uma lamparina é muito. Mas pretendo justificar esse excesso, com as funcionalidades da fada.

Ela sera uma ajudante, seus poderes incluem iluminar o ambiente e partilhar a visão (espionagem).

Descrição da raça
Essa é uma fada hematofaga (sim por tráz da carinha de santa há uma vampirinha), de constituição frágil e pequena estatura, entre 5 à 10cm no máximo.
Possui habilidades bioluminescentes(gera luz e alguns exemplares podem produzir um laser), habilidade empatica (precebe emoções), e é capaz de desenvolver uma forma limitada, mas extremamente eficiente, de telepatia com seu possuidor (partilhar a visão e audição).
Sua natureza hematofaga gera uma relação de dependência e lealdade muito grande com o dono.
Manter uma dessas não é muito fácil, consome 1HP a cada dia, e mais 1 ou 2 HP para se regenerar em caso de batalha. (NOTA: Dados não oficiais até eu terminar o sistema do jogo)
Para obter uma exemplar, além de conseguir encontrar alguem que possua uma "rainha", esta mesma rainha deve aprovar a pessoa. A capacidade empatica da rainha e seus instintos são capazes de determinar se um individuo é virtuoso o suficiente para confiar um de seus filhotes.
Com excessão da rainha, todos os outros indivíduos são asexuados. Oque leva pesquizadores a crer que algum dia essas fadas viviam em colonias. Obviamente perderam isso ao serem domesticados pelos homens.

As origens
Faz anos e anos e anos (1999-2001), reparem que o scan ta um lixo, foi feito na primeira escola de informática que dei aula a Good Friends. (Escola legal, scanner fraco ehhehe)
Foi durante uma aula do curso Técnico em Segurança do Trabalho, eu copiando a matéria, pensando em matar o resto da aula pra conversar no corredor... surgiu o primeiro esboço e a idéia dela se alimentar com sangue pra gerar o vinculo. (de certo, foi bom não exercer a profissão. Ja pensou eu com o peão: -Olha, se você não usar um EPI pode ter um braço arrancado pela máquina, e do geito que estou estressado se não por essa coisa agora... eu mesmo arranco)
De inicio progetei-lhes como uma colmeia, uma enorme colônia, com poderes de projetar raios laser e com dois individuos especiais. Um soldado e um guardião.
O soldado é essa em baixo, com espinhos e pontas afiadas, mais resistencia, e uma cauda de escorpião, e carinha de mau para deixar claro a sua função.
O guardião é uma com aparência de anjo, com escudinhos. Só que não devo ter o scan desta, e nem imagino onde diabos meti a folha com os desenhos.
Uma fatidica constatação... esqueci de fazer as antenas! Mas tudo bem, sobrou algum espaço nas texturas de alpha. Vou corrigir esse engano, mesmo porque tenho q mecher nesse normalmap tosco.
Elas serião usadas em um fansine maior que eu planejava fazer. Onde serião guardiãns em uma sala do grande-ultra-mega-fodão-chefão do mau da saga.
Quem sabe eu consiga mais tarde em alguma expanção criar e usar os outros dois individos da familia da Lime.
Um pequeno Flas que fiz a muito tempo, credo, Flash 5 ainda!

Antes que me perguntem, porque o nome Lime se a bendita raça tem uma rosa na cabeça?
Bom, uma boa coisa é dar esse pequeno nó na cabeça de quem joga. Afinal se o jogador pensar, eu favoreço a interação ^_~
E o nome Lime vem de Lime mesmo, na época eu estava assistindo Saber Marionet J. Assistão, é um anime antiguinho mais muito bonito. link1 e link2

Programar programar programar

Novas "features" do exporter:
Metodo appendAnimation()
Agora todo objeto que estiver marcado com IPO sera exportado com um bloco de animação.
O objeto também podera conter propriedades especiais como:

nome	valor
autostart	true/false
loop	true/false
firsframe	int/string
lastframe	int/string
framelist	string:endereco_de_arquivo.txt
callback	string

A intenção é montar um sistema de animação independente, para atender os cinematics.
Uma coisa chata é a curva IPO, descobri que não tenho um pingo de paciência para fazer os malditos calcúlos das curvas.
Mas sei que da pra fazer a equação entre frames fácil (aquela que você calcula a diferênça entre um frame e outro por causa do framerate elevado).
Outra coisa perigosa é que não sei como vai ser a nova API do Blender, dizem que as curvas IPO vão ser descartadas.
Bom, outra vantagem é o framelist, que aponta para um arquivo com endereços de animação. Onde cada linha tem um numero inicial, um final e um label para a animação. Eu poderia usar o sistema de Actions do Blender para issu, no entanto acho que esse caminho é mais simples de início. Mesmo porque ainda não sei oque vira na API do 2.50.

Nas próximas implementações eu irei ver se consigo obter os dados do filtro Constraint. São muitos filtros, e alguns deles não interesão. Na verdade oque deve ser mais usado é o "Track to", que vai se traduzir em um simples "Look At" dentro da OGRE, assim poderei ter cameras estratégicamente posicionadas em cena seguindo o personagem.

Enquanto ia ao banheiro pensei em um pequeno acrescimo para futuras expansões, um campo para chamar uma função callback. Inicialmente achei que ia ser util para animação dinâmica. No entanto ja é previsto que isso seja feito via código naturalmente. Então ficaria redundande. No entanto achei uma finalidade: chamar uma callback informando o frame e o objeto que esta sendo animado. Assim posso disparar eventos em determinadas sircunstâncias.
A cada frame registrado, é enviado a função definida em callback, esta passa dois valores, o lua_userdata do objeto e o lua_number do frame corrente. Uma utilização seria:
function cameraActIntro( ob, frame )
if frame >= 90 then
displayControl.setVisible( true )
else
displayControl.setVisible( false )
end
end
Também implementei melhorias nos objetos, agora ele serializa os objetos em cena antes de mandar pro xml. Assim acaba-se o erro de um objeto pedir um pai sem que o pai seja instanciado.
Uma coisa curiosa sobre o Python, olhei no meu manual e nada, mas não achei um método para pegar o indice de um dado elemento dentro de listas. Acabou que fiquei com pressa de procurar solução no Google e meti uma função para fazer issu, já que a melhor que o método index(valor) precisava estar num TRY para funcionar.
Depois com calma vasculhei o Google e... não é que essa é uma solução que o pessoal realmente utiliza! Curioso a linguagem não ter um indexOf.
Ainda não olhei com calma, ou bons olhos, o Python 3.0 pra saber se issu foi alterado.
O proximo passo agora é dentro do C++, onde deverei inserir uma classe Frame para interpolar valores, e jogar direto na Camera.

Ufah! Esse hoje foi bem técnico, acho que ninguem leu até o fim. Para os que tiverem saco para ler olhem esse endereço (é de onde vem meu papel de parede): www.brianhamner.com

Mais um inimogo

Crendespaldo
Vamos introduzir o conceito, o Dr Raph And Zody (eu estava ouvindo Raphzody quando pensei no nome) era um funileiro que conseguiu chegar ao ultimo ano de faculdade.
No entanto seu T.C.C. não agradou muito a banca, pois se tratava de um projeto que visava trazer tecidos mortos de volta a vida por vias eletro-mecânicas.
Os seus companheiros de classe o chamaram de louco, no entanto apenas quando ele resolveu explicar os motivos de porque não era louco e porque seu projeto tinha tudo para dar certo para uma samambaia, o corpo doscente resolvel internalo num manicômio.Anos depois, muitos mesmo ao ponto dele ficar velinho, ele foi solto e descobriu sua fabriqueta aos pedaços.
No entanto seu laboratorio ainda estava intacto, e não foi dificil achar material para suas experiência pois havia uma pequena guerra civil na cidade próxima.
Surge assim o MC-100107 ou Crendespaldo, o Dr Raph And Zody deu lhe esse apelido porque todos que o olhavam diziam: - CRENDESPALDO!!!!!!!
Como pode-se imaginar Crendespaldo não é um modelo de fino acabamento, feito com materiais precários, um motor de um caminão velho, uma batedeira usada de 1930, umas valvulas de TV velha e umas sobras de pizza e um topete emo, juntando e controlando pedaços de corpos rescurrectos as preças antes que os urubus começem as sobras.
Raph And Zody usa Crendespaldo para pilhar as cidades visinhas, e criou um pequeno exercito de automatos para defender sua "fortaleza".
Ele agora pensa em vender os direitos para Hollywood e enriquecer com a historia do terrivel monstro assassino.

Scripting materials

Consegui resolver o problema da multitextura sem precisar programar em GLSL. No entanto ainda vou usar issu como alternativa, assim que eu descobrir como pegar as texturas dentro do shader.
A alternativa GLSL ainda pode ser bem util porque o framerate caio bastante, de 120 para 80 com todas as texturas e mapa de iluminação.
Uma grande vantagem no sistema de materiais do OGRE são as thecniques, o mesmo material pode ter varias. Cada thecnique apresenta um conjunto de efeitos, o OGRE em tempo de execução, escolhe qual a thecnique mais adequada para o hardware, então eu posso produzir várias para garantir que se a placa gráfica vai exibir com dada precisão oque eu quero.
Isso também é uma mão na roda para gerar desempenho. Por exemplo, posso aplicar uma thecnique com normalmaps mais perto da camera e uma sem ao longe.Esse normalmap ta dando um boooom trabalho. Pois cada elemento que coloco na borda tenho q fazer uma conta para colocalo na borda oposta.
Da trampo, mas fica bom. A melhor solução que encontrei é curiosa, pois é uma téquinica antiga desenvolvida antes do blender ter recurso de renderizar para textura. Onde a camera é posta em ortogonal com escala de 2 (um plano em OpenGL geralmente vai de -1 até 1) e o material usa 3 texturas de blend nos eixos x,y e z. Essa textura vai ser usada no terreno da terceira ou quarta fase.

Os parametros de textura são muito poderosos. Pode-se definir detalhes doque sera feito na pipeline como se estivesse usando os nodes do Blender.
Apartir de agora so uso o Blender para marcar o material no exporter. Todo o trabalho de definição é feito no Notepad++.
Esse fogo deu umas duas horas lendo e preparando até eu acertar. Mas ficou muito bom o resultado, 8 triangulos, bem menos que um cubo e sem nenhum sistema de particulas. E são só 4 texturas 64x64 em jpeg.

material fogo01
{
receive_shadows off
technique
{
pass
{
lighting off
cull_hardware none
cull_software none
scene_blend one one_minus_src_colour
depth_func less_equal
depth_write off
texture_unit
{
anim_texture fogo_frame_1.jpg fogo_frame_2.jpg fogo_frame_3.jpg fogo_frame_4.jpg .5
tex_address_mode clamp
filtering trilinear
colour_op modulate
}
}
}
}

Meu exporter do Blender também evoluio um pouco, resolvi muitos dos problemas de posicionamento. Mas ainda ficaram para traz algumas questões de rotação e escala.
Oque complica na verdade é a versatilidade, crieu o script de forma que tudo que tiver a propriedade "actor" ativa seja considerado objeto dinâmico. Ja os outros são transformados em "static geometry". O problema é que a geometria estatica não aceita as transformações hierarquicas por si só, então tenho q posicionar os objetos no braço dentro do C++.
O OGRE tem bastantes recursos para issu, classes Vector, Quaternion e Matrix. No entanto o Python do Blender parece ter bem mais funcionalidades.
Mas o desenvolvimento esta ficando bem agíl. ^_~