Category Archives: Blog

Continuo descrevendo o algoritmo de animação do esqueleto conforme ele é implementado no Flame Steel Engine.

Como o algoritmo é o mais complexo de todos que implementei, podem aparecer erros nas notas sobre o processo de desenvolvimento. No artigo anterior sobre esse algoritmo, cometi um erro; o array de ossos é transferido para o shader para cada malha separadamente, e não para o modelo inteiro.

Hierarquia de nós

Para que o algoritmo funcione corretamente é necessário que o modelo contenha uma conexão entre os ossos entre si (gráfico). Vamos imaginar uma situação em que duas animações são reproduzidas simultaneamente – – pule e levante a mão direita. A animação de salto deve levantar o modelo ao longo do eixo Y, enquanto a animação de levantar o braço deve levar isso em consideração e subir com o modelo enquanto ele salta, caso contrário o braço permanecerá no lugar por conta própria.

Descreveremos a conexão dos nós para este caso – o corpo contém a mão. Ao elaborar o algoritmo, o gráfico ósseo será lido, todas as animações serão levadas em consideração com as conexões corretas. Na memória do modelo, o gráfico é armazenado separadamente de todas as animações, apenas para refletir a conectividade dos ossos do modelo.

Interpolação na CPU

No último artigo descrevi o princípio de renderização de animação esquelética – “matrizes de transformação são transferidas da CPU para o shader a cada quadro de renderização.”

Cada quadro de renderização é processado na CPU; para cada osso da malha, o mecanismo recebe a matriz de transformação final usando interpolação de posição, rotação e zoom. Durante a interpolação da matriz óssea final, uma passagem é feita através da árvore de nós para todas as animações de nós ativos, a matriz final é multiplicada pelas matrizes pai e, em seguida, enviada para renderização ao sombreador de vértice.

Os vetores são usados ​​para interpolação de posição e a ampliação é usada para rotação, porque; eles são muito fáceis de interpolar (SLERP), ao contrário dos ângulos de Euler, e também são muito fáceis de representar como uma matriz de transformação.

Como simplificar a implementação

Para facilitar a depuração do vertex shader, adicionei uma simulação do vertex shader na CPU usando a macro FSGLOGLNEWAGERENDERER_CPU_BASED_VERTEX_MODS_ENABLED. O fabricante de placas de vídeo NVIDIA possui um utilitário para depurar código de shader Nsight, talvez ele também possa simplificar o desenvolvimento de algoritmos complexos de shader de vértices/pixels, mas nunca consegui testar sua funcionalidade. A simulação na CPU foi suficiente.

No próximo artigo pretendo descrever a mistura de múltiplas animações e preencher as lacunas restantes.

Fontes

https://www.youtube.com/watch?v= f3Cr8Yx3GGA

Malevich chega periodicamente a qualquer desenvolvedor no OpenGL. Isso acontece inesperadamente e com ousadia, você apenas inicia o projeto e vê um quadrado preto em vez de uma renderização maravilhosa:

Hoje descreverei por que motivo fui visitado por um quadrado preto, os problemas encontrados por causa dos quais o OpenGL não desenha nada na tela e às vezes até torna a janela transparente.

Use ferramentas

Para depurar o OpenGL, duas ferramentas me ajudaram: renderdoc e Death-Mask O que não mostra nada na tela (apenas um quadrado). Ao usar chroot e montagem em 16.10 i recebo uma assembléia de trabalho do jogo com gráficos .

Parece que algo quebrou no Ubuntu 18.04

ldd mostrou a linkka às bibliotecas idênticas sdl2, gl. Dirigindo uma construção não trabalhadora no RenderDoc, vi lixo na entrada do shader do vértice, mas precisava de uma confirmação mais sólida. Para entender a diferença entre os binarticos, eu os dirigi através do Apitrace . A comparação de lixeiras me mostrou que a assembléia em uma nova ubunta quebra o programa das perspectivas no OpenGL, na verdade enviando lixo lá:

Matrizes se reúnem na biblioteca GLM. Depois de copiar o GLM de 16.04 – Recebi a construção do jogo novamente. O problema foi a diferença na inicialização de uma única matriz no GLM 9.9.0, é necessário indicar claramente o argumento MAT4 (1.0F) nele no construtor. Tendo mudado a inicialização e escrevendo O autor da biblioteca, eu comecei a fazer testes para fsgl . No processo de escrita que encontrei falhas no FSGL, as descrevo ainda mais.

Determine quem está na vida

Para o trabalho correto com o OpenGL, você precisa voluntariamente à força solicitar o contexto de uma determinada versão. Então, ele procura SDL2 (você precisa colocar a versão estritamente antes de inicializar o contexto):

 sdl_gl_seettrtribute (sdl_gl_context_major_version,  3 );

Sdl_gl_settribute (sdl_gl_context_minor_version,  2 );

Sdl_gl_settribute (SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);

Por exemplo, o renderDoc não funciona com contextos abaixo de 3.2. Gostaria de observar que, depois de alternar o contexto , há uma alta probabilidade de ver a mesma tela preta . Por que?

Como o contexto do OpenGL 3.2 deve exigir a presença de buffer VAO , sem o qual 99% dos drivers gráficos não funcionam. Adicione fácil:

 glgenvertexarrays ( 1 ,  &  vao);

Glbindvertexaray (VAO);

Não durma, congele

Também encontrei um problema interessante no Kubuntu, em vez de um quadrado preto, fui exibido transparente e, às vezes, tudo era renderizado corretamente. Encontrei a solução para esse problema no Stack Overflow:
https://stackoverflow.com/questions/38411515/sdl2-opengl-window-appears-semi-transparent-sometimes

O código de renderização do teste FSGL também estava presente Sleep (2s) ; Então, no Xubuntu e Ubuntu, recebi a renderização correta e enviei o pedido para dormir, mas no Kubuntu recebi uma tela transparente em 80% do lançamento do golfinho e 30% dos lançamentos e terminais. Para resolver esse problema, adicionei a renderização em cada quadro, após uma pesquisa do SDLEVENT, conforme recomendado na documentação.

Código de teste:
https://gitlab.com/demensdeum/FSGLtests/blob/master/renderModelTest/

Fale com o motorista

OpenGL suporta o canal de comunicação entre o aplicativo e o driver, para ativá-lo, você precisa ativar os sinalizadores GL_DEBUG_OUTPUT, GL_DEBUG_OUTPUT_SYNCHRONUS, Afixar o aviso GLDebugMessagEntrol e tie the callback através de .
Um exemplo de inicialização pode ser tomado aqui:
https://github.com/rock-core/gui-vizkit3d/blob/master/src/EnableGLDebugOperation.cpp

Neste post falarei sobre minhas desventuras com ponteiros inteligentes shared_ptr. Depois de implementar a geração do próximo nível em meu jogo Death-Mask, notei uma memória vazar . Cada novo nível proporcionou um aumento de + 1 megabyte na RAM consumida. É Obviamente que alguns objetos permaneceram na memória e não a liberaram. Para corrigir este facto, foi necessário implementar a correcta implementação de recursos quando o nível se encontra sobrecarregado, o que aparentemente não foi feito. Como usei ponteiros inteligentes, havia várias opções para resolver esse problema, a primeira envolvia a revisão manual do código (longa e enfadonha), enquanto a segunda envolvia pesquisar os recursos do depurador lldb e do código-fonte libstdc++ para a possibilidade de rastreamento automático contra alterações.

Na Internet, todos os conselhos se resumiam a revisar manualmente o código, corrigi-lo e bater-se com chicotes depois de encontrar a linha de código problemática. Também foi proposta a implementação de um sistema próprio para trabalhar com memória, como fazem todos os grandes projetos desenvolvidos desde as décadas de 90 e 2000, antes da chegada dos ponteiros inteligentes no padrão C++11. Tentei usar pontos de interrupção no construtor de uma cópia de todos os shared_ptrs, mas depois de vários dias nada de útil aconteceu. Houve uma ideia de adicionar log à biblioteca libstdc++, mas os custos de mão de obra acabaram sendo monstruosos.

Cowboy Bebop (1998)

A solução me ocorreu de repente na forma de rastrear alterações na variável privada shared_ptr – use_count. Isso pode ser feito usando watchpoints embutidos no lldb. Depois de criar um shared_ptr via make_shared, as alterações no contador no lldb podem ser rastreadas usando a linha:
.

assistir definir var camera._M_refcount._M_pi->_M_use_count

Onde a “câmera” este é um objeto shared_ptr cujo estado do contador precisa ser rastreado. Claro, os aspectos internos do shared_ptr irão variar dependendo da versão do libstdc++, mas o princípio geral pode ser entendido. Após instalar o watchpoint, iniciamos os aplicativos e lemos o stacktrace de cada alteração do contador, depois olhamos o código (sic!), encontramos o problema e corrigimos. No meu caso, os objetos não foram liberados das tabelas de cache e das tabelas lógicas do jogo. Espero que este método ajude você a lidar com vazamentos ao trabalhar com shared_ptr e ame ainda mais essa ferramenta de memória. Boa depuração.

[Translation may be, some day]

Эта заметка увеличит длину вашего резюме на 5 см!

Без лишних слов о крутости квантовых компьютеров и всего такого, сегодня я покажу как сделать генератор чисел на реальном квантовом процессоре IBM.
Для этого мы будем использовать всего один кубит, фреймворк для разработки квантового ПО для python – ProjectQ, и 16 кубитовый процессор от IBM, онлайн доступ к которому открыт любому желающему по программе IBM Quantum Experience.

Установка ProjectQ

Для начала у вас должен быть Linux, Python и pip. Какие либо инструкции по установке этих базовых вещей приводить бесполезно, т.к. в любом случае инструкции устареют через неделю, поэтому просто найдите гайд по установке на официальном сайте. Далее устанавливаем ProjectQ, гайд по установке приведен в документации. На данный момент все свелось к установке пакета ProjectQ через pip, одной командой: python -m pip install –user projectq

Ставим кубит в суперпозицию

Создаем файл quantumNumberGenerator.py и берем пример генератора бинарного числа из документации ProjectQ, просто добавляем в него цикл на 32 шага, собираем бинарную строку и переводим в 32-битное число:

import projectq.setups.ibm
from projectq.ops import H, Measure
from projectq import MainEngine
from projectq.backends import IBMBackend

binaryString = ""

eng = MainEngine()

for i in range(1, 33):

 qubit = eng.allocate_qubit()

 H | qubit

 Measure | qubit

 eng.flush()

 binaryString = binaryString + str(int(qubit))

 print("Step " + str(i))

number = int(binaryString, 2)

print("\n--- Quantum 32-Bit Number Generator by demensdeum@gmail.com (2017) ---\n")
print("Binary: " + binaryString)
print("Number: " + str(number))
print("\n---")

Запускаем и получаем число из квантового симулятора с помощью команды python quantumNumberGenerator.py

Незнаю как вы, но я получил вывод и число 3974719468:

--- Quantum 32-Bit Number Generator by demensdeum@gmail.com (2017) ---

Binary: 11101100111010010110011111101100
Number: 3974719468

---

Хорошо, теперь мы запустим наш генератор на реальном квантовом процессоре IBM.

Хакаем IBM

Проходим регистрацию на сайте IBM Quantum Experience, подтверждаем email, в итоге должен остаться email и пароль для доступа.
Далее включаем айбиэмовский движок, меняем строку eng = MainEngine() -> eng = MainEngine(IBMBackend())
В теории после этого вы запускаете код снова и теперь он работает на реальном квантовом процессоре, используя один кубит. Однако после запуска вам придется 32 раза набрать свой email и пароль при каждой аллокации реального кубита. Обойти это можно прописав свой email и пароль прямо в библиотеки ProjectQ.

Заходим в папку где лежит фреймворк ProjectQ, ищем файл с помощью grep по строке IBM QE user (e-mail).
В итоге я исправил строки в файле projectq/backends/_ibm/_ibm_http_client.py:

email = input_fun('IBM QE user (e-mail) > ') -> email = "quantumPsycho@aport.ru"

password = getpass.getpass(prompt='IBM QE password > ') -> password = "ilovequbitsandicannotlie"

Напишите свой email и password со-но.

После этого IBM будет отправлять результаты работы с кубитом онлайн прямо в ваш скрипт, процесс генерации занимает около 20 секунд.

Возможно в дальнейшем я доберусь до работы квантового регистра, и возможно будет туториал, но это не обязательно.
Да прибудет с вами запутанность.

Статья на похожую тему:
Introducing the world’s first game for a quantum computer