<foo> simply produces <foo>in the text).
<URL: http://somewhere.tld/ >,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto: URI,
e.g. mailto:my.email@somewhere.tld,
if you do not have a genuine Web site).
Benoit (2018-07-01T14:42:01Z)
@Ruxor bien entendu, tu peux mentionner ce lien.
Je vais essayer de nettoyer et commenter un peu ce code…
Si une autre licence que Apache 2 te convient mieux un jour, n'hésite pas. Je n'ai pas gardé le choix de 'public domain' parce que même si ça correspond bien à mon intention, c'est difficile d'exprimer ça d'une façon qui ait une valeur juridique partout.
Ruxor (2018-06-30T22:26:46Z)
@Benoit: Merci, c'est plus agréable à regarder et ça me servira certainement de regarder ton code si je suis de nouveau amené à programmer en WebGL. Pas d'objection à ce que je mette ton lien dans la description de ma vidéo sur YouTube ?
Ruxor (2018-06-30T22:17:59Z)
@DafukIsDis: Franchement, celui qui trouve que j'abuse des emojis, c'est vraiment qu'il a une réaction épidermique à faire soigner avec des anti-histaminiques. En revanche, l'histoire des classes CSS est intéressante : la plupart des standards demandent que les identificateurs soient formés caractères Unicode qui ont des propriétés du genre lettre (on peut nommer une balise XML d'après un mot arabe mais pas d'après un emoji) ; CSS, lui, a choisi de considérer tout Unicode non-ASCII comme permissible dans un identificateur, ce qui permet effectivement les emojis. Il serait de bon goût de mettre en place un méta-standard sur les standards pour éviter des différences aussi gratuites et inutiles de traitement d'Unicode de l'un à l'autre.
DafukIsDis (2018-06-30T08:22:47Z)
Ah ouais, des emojis unicode dans le texte, maintenant. Je savais pas que ce moment était arrivé.
Tu n'as qu'à nommer tes classes CSS avec, je suis sûr que tu vas adorer:
.💩 {clear:both;}
Mais c'est la fête !
Benoit (2018-06-29T21:25:27Z)
Voici une démo!
https://bjacob.github.io/webgl_waves/torus_waves.html
Notes:
- Finalement, c'est basé sur ta formule explicite, et non pas sur une méthode de propagation incrémentale. En effet, ça va déjà bien assez vite.
- Pas besoin de précalculer les poids. C'est OK de calculer des cos() et des exp() pour chaque pixel, à chaque fois.
- En revanche, j'ai adopté une optimisation qui consiste à tirer parti de la symétrie hexagonale du réseau. Mon calcul se passe sur une certaine troncature hexagonale du réseau. Donc il n'est pas exactement équivalent à ton calcul.
- J'ai essayé de porter exactement ton calcul à part ça, y compris exactement ton gradient de couleurs…
Benoit (2018-06-28T20:54:55Z)
En effet ce n'est pas trivial, voici quelqu'un qui a implémenté des démos,
https://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm
et qui nous renvoie à cet article pour comprendre la technique:
http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf
c'est ma lecture pour ce soir…
Ruxor (2018-06-28T18:26:14Z)
@Benoit: Mes motivations pour utiliser une somme d'harmoniques sont que je suis une quiche en analyse numérique 😅 donc je ne sais vraiment pas résoudre itérativement l'équation des ondes. Et j'ai des raisons de penser que ce n'est pas trivial, notamment que l'idée la plus débile reviendrait essentiellement à approcher le laplacien par un laplacien discret sur un graphe (d'adjacence des pixels), mais le laplacien discret en question va donner des front d'ondes en losanges ou en carrés, pas en jolis cercles ; je n'ai pas de doute que les numériciens savent comment corriger ce problème, mais moi pas. Après, j'ai aussi une plus-ou-moins-raison mathématique, qui est que j'ai fait tout ça pour illustrer la problématique du calcul du spectre du laplacien, donc si en fait on n'utilise pas le spectre du laplacien, c'est bête. 😖 (D'autant que mon idée, au départ, était plutôt de faire des sons, et je n'ai pensé à la vidéo qu'incidemment. La ceinture noire de la vulgarisation mathématique ce sera de faire une vidéo ET un son qui va avec qui sont tous les deux agréables et qui illustrent des choses mathématiquement liées, mais je n'en suis pas encore là.)
Benoit (2018-06-28T17:52:53Z)
@Ruxor, bien noté.
Sur:
> ça fait 1920×1080×271 flottants à précalculer, je pense que le navigateur va être Pas Content si on lui demande ça
Ça fait un demi-milliard, soit 2G de mémoire à stocker en float32. C'est sûr que ça fait beaucoup pour des textures, mais ce n'est pas un problème de navigateur, le navigateur ne fait ici qu'exposer la fonctionnalité du matériel.
2G ça fait, en effet, beaucoup, parce que même si un PC a plus de mémoire que ça, devoir traverser 2G 60 fois par seconde demanderait 120 G/s de bande passante mémoire; c'est environ 10x plus que disponible dans un PC typique.
Une autre question: une approche typique pour implémenter des simulations d'ondes en temps réel, est de calculer "incrémentalement" l'onde au temps (t+1) en fonction de l'onde au temps (t), ce qui semble moins coûteux que ta formule explicite "random access" donnant la forme de l'onde à un temps (t) arbitraire.
D'où ma question: quelles sont tes motivations pour utiliser une telle formule? Simplement parce que c'est plus directement mathématique ou bien une considération d'implémentation (il est plus difficile d'avoir confiance en une implémentation itérative parce que l'inexactitude s'accumule au fil des itérations).
Ruxor (2018-06-28T14:59:57Z)
Et sinon, donc, j'ai mis des versions en haute résolution sur YouTube : <URL: http://www.youtube.com/watch?v=cLVQ67SwNZE > pour un réseau triangulaire, et <URL: http://www.youtube.com/watch?v=vod6z379S7g > pour un réseau carré.
Ruxor (2018-06-28T14:58:59Z)
@Benoit: Je pense qu'on peut sans problème passer à Float32. De fait, on peut tout raboter, à commencer par le nombre de poids (≈harmoniques) α calculés (essentiellement la variable hbound dans mon code), la question est à partir de quand ça commence à se voir qu'on rabote, mais je n'ai pas fait d'essais. Mais si on veut passer à une image plus grande, il va aussi y avoir la question de savoir combien de textures float de cette taille il est raisonnable de demander de garder en mémoire. Ma version JavaScript calcule 129 poids en 256×256, soit 256×256×129 flottants, ça reste raisonnable en mémoire. Mais pour les vidéos que j'ai mises sur YouTube, je calcule 271 poids pour la version triangulaire, en 1920×1080 ça fait 1920×1080×271 flottants à précalculer, je pense que le navigateur va être Pas Content si on lui demande ça.
Benoit (2018-06-28T13:23:46Z)
Tu pourrais coder ça en C, ou dans n'importe quel language pour lequel il existe un front-end LLVM, et compiler ça avec Emscripten vers soit du JavaScript optimisé, soit du WebAsm.
Typiquement, tu coderais une bibliothèque en C qui offrirait la fonctionnalité calculatoire, disons
void GenerateFrame(float time, int width, int height, char* bitmap);
Et qui serait compilée sous forme d'une bibliothèque JavaScript. Ça donnerait de meilleures performances que du JavaScript écrit à la main. La partie interface utilisateur resterait en JavaScript/HTML.
En fait, pour ce que tu fais spécifiquement ici, ce n'est pas optimal de faire ça avec un Canvas 2D, il faudrait plutôt faire ça avec WebGL.
Dans l'approche Emscripten, on écrirait une bibliothèque en C faisant des appels OpenGL ES 2.0, et Emscripten compile ça en appels WebGL.
Cependant, utiliser WebGL enlèverait une grande partie de l'intérêt de Emscripten pour ton application:
- avec WebGL, le code de doimage() serait écrit dans le langage de shaders de WebGL, une variante de GLSL, de toute façon proche du C comme syntaxe.
- avec WebGL, il n'y aurait plus trop de problème de performance, et plus de différence de performance entre du JavaScript écrit à la main et du produit par Emscripten, parce que la partie calculatoire serait concentrée dans le shader.
Je ferais bien une petite expérience si j'ai le temps de porter ton code, mais je voudrais savoir la motivation d'utiliser Float64? Est-ce nécessaire? Ça ne serait pas supporté dans WebGL.
Bob (2018-06-28T07:46:55Z)
C'est pas que personne ne lit l'entrée précédente, c'est juste qu'il faut un peu de temps pour l'apprécier :)
Ruxor (2018-06-27T21:31:00Z)
@mummy: Ça ne revient jamais au point de départ (même si ça doit s'en approcher arbitrairement près si on attend assez longtemps).
mummy (2018-06-27T18:09:12Z)
C'est assez fascinant et hypnotique, mais je n'arrive pas à voir si ça change en permanence ou si ça revient au point de départ…C'est de l'art psychédélique !