Meeting 2016 11 28
Anwesend:
- Jürgen Richter-Gebert
- Aaron Montag
- Michael Strobel
- Martin von Gagern
Ganz oben auf der Agenda von Michael.
Martin hat ein bisschen Code dazu geschrieben, aber der tut noch nicht was er soll: eine halbfreie Masse auf einem Kreis schaukelt sich jetzt zu einem Überschlag auf. Wahrscheinlich werden von Martins tangentForce branch nicht die richtigen methoden gefüttert. Oder irgendwas wird nicht auf 0 initialisiert.
Ein Skript was on Hit von Physik-Elementen ausgeführt wird. “Script after bouncing” im Inspector. Im Moment wird das von Cinderella nicht exportiert. Martin kümmert sich um den Export. Cinderella setzt evtl. eine globale Variable namens hitter, das müsste man reproduzieren. Die Priperty soll afterBounce heißen und dem Behavior-Objekt zugeordnet sein.
Timing sollte umschaltbar sein: feste Zeitschritte in Simulationszeit, oder möglichst konstantes Verhältnis von Simulationszeit zu echter Zeit. Default sollte wie bei Cinderella sein, also feste Simulationszeit pro Frame, weil das Zeichnen von Spuren damit sinnvoller aussieht. Das andere Verhalten mit im Vergleich zu echter Zeit synchronem Verhalten kann man dann bekommen, indem man CindyJS({…, animation: { syncToTime: true, …}, …}) setzt.
Langfristig eine Alternative wäre, dass man RK auch verwenden könnte, um Interpolationspunkte zu bestimmen, zusätzlich zum Endergebnis.
Alles was an Physik-Eigenschaften in Cinderella existiert sollte auch exportiert werden. Martin schaut sich das an. Insbesondere so was wie richtungsabhängiger Dämpfung von Floor und Bouncern.
Rund um #539. Was ist das richtige Verhalten, wenn Maus und Skript das gleiche Element bewegen? Wann werden Checkpoints (aka. last good state) erstellt?
Vermutung: Cinderella betrachtet die Bewegung mit der Maus und die danach durchgeführte Bewegung vom Script als separate Operationen. Wenn die Maus in eine nicht singuläre aber komplexe Situation navigiert, und das Skript dann von da aus in eine singuläre zurück navigiert, dann geht die nächste getracte Bewegung von der komplexen Maus-Situation aus. In CindyJS hingegen wird die Maus und die Skripte gesammelt betrachtet. Wenn das Endergebnis von beiden zusammen singulär ist, wird die Situation davor als Ausgangspunkt der nächsten Bewegung verwendet.
Das Verhalten in diesen Situationen ist sehr Interpretationssache. Kompatibilität mit Cinderella ist daher nicht so wichtig, CindyJS darf sich ruhig anders verhalten. Funktion die stateContinueFromHere triggert könnte für Experten zugänglich gemacht werden.
Cinderella hatte mal ein restricted Move Flag, was Bewegungen verhindert die Zwischenergebnisse komplex machen. Scheint verschwunden zu sein.
See #526.
Martin macht einen PR.
Können #462(imagergb) und #519(webcam resolution) gemerged werden? Martin schaut sie noch mal an.
Präferenz: deformimage oder lieber colorplot-stabil mit CPU-Fallback? Entscheidung: Ersteres ist wichtiger. Für CindyGL wäre es wertvoller, sauber zu dokumentieren, was alles übersetzbar ist. Aaron schreibt erst mal etwas mehr Doku, und dann deformimage.
Im Rahmen eines Projektes sollen mathematische Modelle mit Annotationen ins Web gestellt werden. Es existieren die Ergebnisse von 3D-Scans und Oberflächenfotos, die als Meshes und Texturen abgelegt sind. Siehe https://mathematical-models.org/models/ für wie das aussehen kann.
Cindy3D im Haupt CindyJS-Canvas. Idee: begin3d bekommt eine Größe übergeben, und liefert ein Bild was mit drawimage gezeichnet werden kann. Aber dann kommen die Mausevents nicht bei Cindy3D an. Besser wäre daher ein HTML Overlay. Evtl. mit Positionsangaben in %.
Cindy3D auf Mobile. Marzin muss sich erst mal ein iPad ausleihen. Kann sein dass das Problem lediglich daran liegt, dass der depth buffer bei Desktops 16 bit hat, bei Mobile hingegen nur 8 bit.
Könnte für eine Ausstellung in Frankreich relevant sein, die Surfer-artig algebraische Flächen dritten Grades ausstellt.
Schön
Im Moment ist noch ein Sign Flip drin, dessen Ursprung ungeklärt ist.
Das IFS reagiert recht spät erst auf User Input. Das lässt sich evtl. verbessern durch weniger Punkte pro Frame, damit der Worker weniger lange am Stück beschäftigt ist. Ansonsten müsste man ein paar Punkte im GUI-Thread berechnen, damit man zumindest irgendetwas sieht.
Zum Speicherformat wäre ein Array gut, mit Probability und Color pro Element.
{type:"IFS", ifs:[{prob:1, color:[1,0,0]}, {prob:2, color:[0,0,1]}]}Muss noch eingebunden werden. Nachdem die Zahl der Plugins zunimmt, wäre es gut, wenn der
Wir nutzen im Moment noch Teile von MIDI.js. Die machen aber Kopfschmerzen. Es wäre besser, sich davon zu verabschieden. Soundfont Player könnte eine Lösung sein, oder was eigenes.
Wenn man komprimiertes Audio loopt, passt die Phase dann noch zusammen? Kann man FFT als Node der Web Audio API verwenden, um Samples im Phasenraum zu loopen?
Langfristig wäre es schön, ein eigenes Soundfont-Format zu haben, was Sustain und dergleichen mächtiger macht.
Timbre hat hier geholfen, Code auf dem iPad laufen zu lassen.
Die verschiedenen Widgets einer Seite sowie die verschiedenen Sound-Arten (MIDI vs. Sampled) sollten sich einen Audio Context teilen. Könnte man auf CindyJS.wevAudioContext oder so ablegen.
Minimallösung ist Reingemerged, so dass mehrere Finger sich nicht mehr die Events klauen. Weiterer Ausbau muss erst noch gemacht werden.
Symposium on Computational Geometry: Michael und Aaron überlegen sich was.
20.12. wenn Ulli dabei sein kann. Martin fragt ihn. 17.01. in jedem Fall. 14:00 jeweils.