A piada “Verlet só é Verlet se vier da região francesa de Verlet; caso contrário é só Euler espumante” é excelente
Fico me perguntando como alguém passa de conhecimentos de desenvolvimento web, Gradle e Java para o estágio de criar algo assim
Como não fiz graduação em CS, às vezes sinto que, por mais linguagens de programação que eu aprenda, nunca vou conseguir entender esse tipo de coisa. Mexi um pouco com OPENLY, LIBGDX, GODOT e Unity, mas criar uma simulação de tecido do zero parece realmente intimidador
É muito mais simples do que parece. Fiz a demo de “tecido rasgável” linkada em outro ponto desta thread antes mesmo de começar minha carreira como engenheiro de software
Aqui se usa uma integração de Verlet básica: você atualiza vetores 2D que formam uma grade com base na posição atual e na posição anterior, e impõe restrições para que mantenham uma distância fixa dos pontos imediatamente vizinhos. Se desenhar linhas entre esses pontos, você tem um tecido. Eu estava fascinado por simulações físicas e fui pesquisar; foi uma das coisas mais fáceis de implementar que encontrei primeiro, e o retorno pelo esforço foi muito bom. Claro que, a partir daí, fica muito mais complexo
Já me senti de forma parecida por querer aprender simulação física. Com o tempo, aprendi que é preciso separar áreas de conhecimento como física das ferramentas de programação usadas para implementá-las
Especialmente quando você começa por desenvolvimento de jogos, parece que para cada simulação importante — corpos rígidos, tecido, molas, fluidos — deve existir um jeito natural e idiomático de programá-la. No começo, eu também achava que simulação de fluidos seria algo naturalmente expresso dentro da linguagem, como criar uma grade e escolher regras de atualização a cada passo de tempo. Mas, na prática, é modelar o problema com matemática e física e depois mapear isso para a linguagem e as ferramentas, que nem sempre permitem expressá-lo de forma idiomática
Existem algoritmos fáceis de transformar em código, como simulações de tecido baseadas em posições de partículas e molas, mas isso acabou criando uma impressão enganosa quando tentei ir além. No fim, foi preciso me aprofundar mais em física e análise numérica e então traduzir o problema para código; o resultado pode ser um código meio tosco e cheio de números mágicos
Desenvolvimento web não se limita a Java e, em geral, é dominado por problemas de integração de componentes. Há muita estrutura e pouco conteúdo; os cálculos são delegados a bibliotecas, e a complexidade de integração aparece no build, enquanto em runtime o problema é a escala de sistemas distribuídos
Já escrever simulações é intensivo em cálculo, então a maior parte do código é conteúdo de fato. Se desenvolvimento web é uma composição de coisas heterogêneas, simulação é algo mais homogêneo. O problema fica limitado pelo desempenho de um único processo dentro do orçamento de tempo definido pelos frames por segundo
Por isso dá para se concentrar em um único ambiente de execução. Recomendo o navegador, que resolve os problemas de distribuição. Ganja[1] talvez seja o projeto de simulação definitivo mais próximo de “conteúdo, não estrutura”. É muito peculiar e difícil de entender, então a manutenção parou, mas funciona. Em uma direção um pouco mais estruturada há o D3, e seus autores já criaram algoritmos modernos de visualização/layout, como grafos baseados em força[2]. Um ponto de partida mais amigável pode ser a família Processing[3], que começou em Java e foi portada para Python, JavaScript e outras linguagens
Dito isso, uma única simulação de tecido, comparada a uma engine de jogo, é como uma célula de um rato. Uma engine de jogo é enorme e, mesmo nela, você acaba fazendo muita integração interna em vez de escrever simulações diretamente
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
No fim, é tudo matemática e física
Você não perguntou especificamente sobre desenvolvimento de jogos, mas conhecimentos como gráficos, matemática, iluminação e física em geral estão muito difundidos nessa área. Se tentar procurar separadamente por um tema de nicho como simulação de tecido, pode ser difícil encontrar informações que não estejam ligadas a materiais de desenvolvimento de jogos
Hoje li https://alextardif.com/LearningGraphics.html, que pode servir como guia em várias direções. https://learnopengl.com/ continua sendo bem avaliado, mesmo agora que existem APIs mais novas como Vulkan, Metal e DX12. Mas pense na API como uns 5% do problema a resolver. Para ser sincero, talvez seja ainda menos, embora Vulkan seja mais pesado do que eu já tinha ouvido dizer
Se você não quiser aprender C/C++, a comunidade WebGL é grande, então dá para começar por subreddits ou fóruns relacionados. Ainda assim, a API e a plataforma são mais a casca em volta da parte realmente interessante e nova, que é a simulação física em si
Para contextualizar, sou desenvolvedor web/Gradle/Java e, depois de uma tentativa alguns anos atrás, estou voltando a criar uma engine de jogo no meu tempo livre
Não é tão difícil assim. Em JavaScript, você representa cada ponto como (x,y,z), atribui uma massa e, a cada frame, aplica gravidade e, se necessário, acrescenta um pouco de ruído
Sempre que uma partícula tenta se mover, você usa trigonometria para transmitir a força pelas arestas para outros pontos e adiciona um pouco de amortecimento para evitar que tudo saia de controle. A massa depois determina quanto cada ponto é afetado pelas forças. Se 3D parecer pesado demais, comece em 2D
Lembrei de um vídeo da Polygon que analisa o incrível design de tecidos de Elden Ring: https://youtu.be/wSSqx-Dh6ko
Um ponto que o vídeo não enfatiza o suficiente é que o tecido também tem um propósito funcional. O tecido encobre a forma dos inimigos, dificultando distinguir o modelo
Em jogos cujo núcleo é o combate corpo a corpo e a detecção de acertos precisa — que talvez seja um dos aspectos mais inovadores dos jogos da FromSoft —, tecidos que se movem livremente tornam mais difícil julgar quão perto você precisa deixar o personagem para acertar um ataque, ou quão longe precisa ficar para não ser atingido. Somando isso a movimentos e padrões de ataque difíceis de prever, a dificuldade aumenta, e cada combate se torna único
No mundo real, o tecido tem a mesma propriedade. Um inimigo usando uma túnica ou capa é muito mais ameaçador e difícil de enfrentar
Pessoalmente, não gosto dos jogos da FromSoft por causa do loop de gameplay, mas, em termos de design, vejo alguns deles como estando entre os videogames mais bem feitos da história
Também existe a minha versão, feita há 14 anos: https://www.youtube.com/watch?v=G05M_Y6NQVM
Concordo que essa estrutura básica é muito simples de implementar, e que o resultado fica realmente muito legal
Fui eu que fiz isso. A versão original que publiquei no Codepen foi há cerca de 13 anos
Também acho difícil acreditar, mas, quando lembro que foi antes de eu conseguir meu primeiro emprego como programador, parece mesmo muito tempo atrás
O videogame Hitman, de 2000, já tinha tecido, e Mirror's Edge, de 2008, tinha tecido rasgável. Provavelmente nenhum dos dois foi o primeiro
Esses simuladores de tecido sempre parecem um tanto instáveis. Se você cria um tecido em Grid, ele começa a saltar e a se mover aleatoriamente
Fico me perguntando se isso acontece por acúmulo de erros de ponto flutuante IEEE 754
Vale a pena procurar por integração numérica no contexto de simulações físicas ou engines de jogos. Como ponto de partida, veja https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary...
Pelo que entendo, não é apenas erro simples de ponto flutuante, mas algo que surge da própria natureza de aproximar funções contínuas por etapas discretas simples. O artigo da Wikipédia linkado também tem um gráfico mostrando que, com passos grandes, os erros se acumulam muito antes de a precisão de ponto flutuante se tornar um problema
Cada técnica de integração numérica tem trade-offs diferentes. Há métodos como Euler, Verlet e Runge-Kutta; alguns tendem a acumular energia total, enquanto outros tendem a perder energia, e ambos são comportamentos incorretos. Métodos mais complexos costumam se comportar um pouco melhor, mas aí surge a questão de avaliar se o ganho de cada passo mais complexo compensa em relação a repetir mais vezes um algoritmo mais simples e rápido
Em simulações físicas, a conservação de energia não funciona por padrão a menos que seja codificada explicitamente. Por exemplo, pode ser necessário fazer correções manuais periodicamente
Além de erros de arredondamento, a quantização do tempo e outros pequenos erros vindos do próprio modelo matemático também são causas
Se o erro for no sentido do amortecimento, o efeito é a energia se dissipar como no mundo real e o movimento acabar parando; se for no sentido da aceleração, a simulação sai do controle
Quero dizer ao autor deste site que ficou muito bem feito. Ele roda como está, sem JavaScript externo, e também funciona no celular
É difícil dizer isso da maioria dos sites baseados em texto hoje em dia
Trabalho realmente impressionante. É simples, mas prende a atenção, e mostra bem como a integração de Verlet é poderosa para criar uma simulação de tecido natural e plausível
Se você tiver interesse, também recomendo o artigo de Jakobsen que veio da engine do jogo Hitman. É um clássico
É bom ver alguém realmente fazendo as perguntas difíceis sobre como algo assim funciona. Toda vez fico com a sensação de que tudo é construído a partir de inúmeros pequenos passos acumulados ao longo de anos
Fico curioso se a pessoa bate em um ponto em que a matemática parece um muro, ou se continua insistindo até entender
O mais interessante é como bastam alguns parâmetros e restrições para produzir um movimento tão realista
Dá a impressão de que o mundo ao nosso redor talvez seja apenas um conjunto de modelos e forças ocultos, e que nosso trabalho seja descobri-los e simulá-los. Belo trabalho
1 comentários
Comentários do Hacker News
Outro exemplo que dá para ver no navegador: https://oimo.io/works/cloth/
Depois de ler o texto de Marian Pekár, consegui entender a integração de Verlet e criar minha própria simulação de tecido: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
Fico me perguntando como alguém passa de conhecimentos de desenvolvimento web, Gradle e Java para o estágio de criar algo assim
Como não fiz graduação em CS, às vezes sinto que, por mais linguagens de programação que eu aprenda, nunca vou conseguir entender esse tipo de coisa. Mexi um pouco com OPENLY, LIBGDX, GODOT e Unity, mas criar uma simulação de tecido do zero parece realmente intimidador
Aqui se usa uma integração de Verlet básica: você atualiza vetores 2D que formam uma grade com base na posição atual e na posição anterior, e impõe restrições para que mantenham uma distância fixa dos pontos imediatamente vizinhos. Se desenhar linhas entre esses pontos, você tem um tecido. Eu estava fascinado por simulações físicas e fui pesquisar; foi uma das coisas mais fáceis de implementar que encontrei primeiro, e o retorno pelo esforço foi muito bom. Claro que, a partir daí, fica muito mais complexo
Especialmente quando você começa por desenvolvimento de jogos, parece que para cada simulação importante — corpos rígidos, tecido, molas, fluidos — deve existir um jeito natural e idiomático de programá-la. No começo, eu também achava que simulação de fluidos seria algo naturalmente expresso dentro da linguagem, como criar uma grade e escolher regras de atualização a cada passo de tempo. Mas, na prática, é modelar o problema com matemática e física e depois mapear isso para a linguagem e as ferramentas, que nem sempre permitem expressá-lo de forma idiomática
Existem algoritmos fáceis de transformar em código, como simulações de tecido baseadas em posições de partículas e molas, mas isso acabou criando uma impressão enganosa quando tentei ir além. No fim, foi preciso me aprofundar mais em física e análise numérica e então traduzir o problema para código; o resultado pode ser um código meio tosco e cheio de números mágicos
Já escrever simulações é intensivo em cálculo, então a maior parte do código é conteúdo de fato. Se desenvolvimento web é uma composição de coisas heterogêneas, simulação é algo mais homogêneo. O problema fica limitado pelo desempenho de um único processo dentro do orçamento de tempo definido pelos frames por segundo
Por isso dá para se concentrar em um único ambiente de execução. Recomendo o navegador, que resolve os problemas de distribuição. Ganja[1] talvez seja o projeto de simulação definitivo mais próximo de “conteúdo, não estrutura”. É muito peculiar e difícil de entender, então a manutenção parou, mas funciona. Em uma direção um pouco mais estruturada há o D3, e seus autores já criaram algoritmos modernos de visualização/layout, como grafos baseados em força[2]. Um ponto de partida mais amigável pode ser a família Processing[3], que começou em Java e foi portada para Python, JavaScript e outras linguagens
Dito isso, uma única simulação de tecido, comparada a uma engine de jogo, é como uma célula de um rato. Uma engine de jogo é enorme e, mesmo nela, você acaba fazendo muita integração interna em vez de escrever simulações diretamente
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Você não perguntou especificamente sobre desenvolvimento de jogos, mas conhecimentos como gráficos, matemática, iluminação e física em geral estão muito difundidos nessa área. Se tentar procurar separadamente por um tema de nicho como simulação de tecido, pode ser difícil encontrar informações que não estejam ligadas a materiais de desenvolvimento de jogos
Hoje li https://alextardif.com/LearningGraphics.html, que pode servir como guia em várias direções. https://learnopengl.com/ continua sendo bem avaliado, mesmo agora que existem APIs mais novas como Vulkan, Metal e DX12. Mas pense na API como uns 5% do problema a resolver. Para ser sincero, talvez seja ainda menos, embora Vulkan seja mais pesado do que eu já tinha ouvido dizer
Se você não quiser aprender C/C++, a comunidade WebGL é grande, então dá para começar por subreddits ou fóruns relacionados. Ainda assim, a API e a plataforma são mais a casca em volta da parte realmente interessante e nova, que é a simulação física em si
Para contextualizar, sou desenvolvedor web/Gradle/Java e, depois de uma tentativa alguns anos atrás, estou voltando a criar uma engine de jogo no meu tempo livre
Sempre que uma partícula tenta se mover, você usa trigonometria para transmitir a força pelas arestas para outros pontos e adiciona um pouco de amortecimento para evitar que tudo saia de controle. A massa depois determina quanto cada ponto é afetado pelas forças. Se 3D parecer pesado demais, comece em 2D
Lembrei de um vídeo da Polygon que analisa o incrível design de tecidos de Elden Ring: https://youtu.be/wSSqx-Dh6ko
Em jogos cujo núcleo é o combate corpo a corpo e a detecção de acertos precisa — que talvez seja um dos aspectos mais inovadores dos jogos da FromSoft —, tecidos que se movem livremente tornam mais difícil julgar quão perto você precisa deixar o personagem para acertar um ataque, ou quão longe precisa ficar para não ser atingido. Somando isso a movimentos e padrões de ataque difíceis de prever, a dificuldade aumenta, e cada combate se torna único
No mundo real, o tecido tem a mesma propriedade. Um inimigo usando uma túnica ou capa é muito mais ameaçador e difícil de enfrentar
Pessoalmente, não gosto dos jogos da FromSoft por causa do loop de gameplay, mas, em termos de design, vejo alguns deles como estando entre os videogames mais bem feitos da história
Sempre gostei dessas animações de tecido. A primeira que vi provavelmente foi a demo de tecido rasgável do dissimulate no Codepen, e é difícil acreditar que aquele código foi escrito há 9 anos
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
Concordo que essa estrutura básica é muito simples de implementar, e que o resultado fica realmente muito legal
Também acho difícil acreditar, mas, quando lembro que foi antes de eu conseguir meu primeiro emprego como programador, parece mesmo muito tempo atrás
Esses simuladores de tecido sempre parecem um tanto instáveis. Se você cria um tecido em Grid, ele começa a saltar e a se mover aleatoriamente
Fico me perguntando se isso acontece por acúmulo de erros de ponto flutuante IEEE 754
Pelo que entendo, não é apenas erro simples de ponto flutuante, mas algo que surge da própria natureza de aproximar funções contínuas por etapas discretas simples. O artigo da Wikipédia linkado também tem um gráfico mostrando que, com passos grandes, os erros se acumulam muito antes de a precisão de ponto flutuante se tornar um problema
Cada técnica de integração numérica tem trade-offs diferentes. Há métodos como Euler, Verlet e Runge-Kutta; alguns tendem a acumular energia total, enquanto outros tendem a perder energia, e ambos são comportamentos incorretos. Métodos mais complexos costumam se comportar um pouco melhor, mas aí surge a questão de avaliar se o ganho de cada passo mais complexo compensa em relação a repetir mais vezes um algoritmo mais simples e rápido
Além de erros de arredondamento, a quantização do tempo e outros pequenos erros vindos do próprio modelo matemático também são causas
Se o erro for no sentido do amortecimento, o efeito é a energia se dissipar como no mundo real e o movimento acabar parando; se for no sentido da aceleração, a simulação sai do controle
Quero dizer ao autor deste site que ficou muito bem feito. Ele roda como está, sem JavaScript externo, e também funciona no celular
É difícil dizer isso da maioria dos sites baseados em texto hoje em dia
Trabalho realmente impressionante. É simples, mas prende a atenção, e mostra bem como a integração de Verlet é poderosa para criar uma simulação de tecido natural e plausível
Se você tiver interesse, também recomendo o artigo de Jakobsen que veio da engine do jogo Hitman. É um clássico
É bom ver alguém realmente fazendo as perguntas difíceis sobre como algo assim funciona. Toda vez fico com a sensação de que tudo é construído a partir de inúmeros pequenos passos acumulados ao longo de anos
Fico curioso se a pessoa bate em um ponto em que a matemática parece um muro, ou se continua insistindo até entender
O mais interessante é como bastam alguns parâmetros e restrições para produzir um movimento tão realista
Dá a impressão de que o mundo ao nosso redor talvez seja apenas um conjunto de modelos e forças ocultos, e que nosso trabalho seja descobri-los e simulá-los. Belo trabalho