-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
564 lines (491 loc) · 31.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light dark" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.min.css" />
<link rel="stylesheet" href="css/pico.min.css">
<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script type="text/javascript" id="MathJax-script" async
src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js">
</script>
<title>DD1354 Project Blog</title>
<style>
.center {
text-align: center;
}
.bordered {
margin-top: 1em;
margin-bottom: 1em;
}
</style>
</head>
<body>
<main class="container">
<h1>DD1354 Project Blog</h1>
<article>
<h3>Update 0 - In Unity There Is Strength</h3>
<h6>25th of February 2024</h6>
<p>
Welcome to my project blog in the DD1354 Models and Simulation course. My name is Azeez Daoud and I
am here to invite you to venture with me in world of <b>WAVES!</b>. There we will encounter
differential equations, numerical analysis, and a whole lot of springs and masses. Together we will
build a system of coupled springs and masses, shake it (<b>A LOT!</b>) to produce two
types of waves: transverse and longitudinal waves. The former propagates through the medium by
displacing it perpendicularly in the direction of its motion. The latter displaces the medium in the
direction of motion. This might seem quite abstract, so here is a figure showing the two types:
</p>
<figure class="center bordered">
<img src="Blog/Update0/waves.png"
alt="An image of transverse and longitudinal waves moving through a spring">
<figcaption>
A person shaking a spring producing transverse and longitudinal waves. Image from
<a href="https://upload.wikimedia.org/wikipedia/commons/0/08/CNX_UPhysics_16_01_GirlWave.png"
target="_blank">wikimedia.org</a>.
</figcaption>
</figure>
<p>
How do we visualise that? Well, we need 3 ingredients:
<ol>
<li>Physics</li>
<li>Numerical Analysis</li>
<li>Somewhere to do the simulation</li>
</ol>
Let us focus on the third point first by choosing a tool to do our simulation. I have decided to use <a
href="https://unity.com/">The Unity Game Engine</a>, because it is easy set up and use. The medium
we are going to make waves propagate through will be a rope-like object modelled as a chain of springs
and masses, like in the following figure.
</p>
<figure class="center bordered">
<img src="Blog/Update0/coupled_spring_mass.png"
alt="An image of transverse and longitudinal waves moving through a spring">
<figcaption>
A coupled spring-mass system. Image from
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/7/70/Coupled_Harmonic_Oscillator_k.svg/640px-Coupled_Harmonic_Oscillator_k.svg.png"
target="_blank">wikimedia.org</a>.
</figcaption>
</figure>
<p>
This is called a coupled spring-mass system which we will abbreviate as <abbr
title="Coupled Spring-Mass System">CSMS</abbr>, but more on that later. First we need to set up a
few things in Unity:
<ol>
<li>Springs</li>
<li>Masses</li>
<li>Walls</li>
</ol>
Masses and walls are fairly easy to set up. Masses will be just an cube with coordinates for position and
velocity (we can actually omit the mass for a reason that will become clear soon). Walls will also be a
cube stretched and compressed to look like plane. We will also create a point on that wall where we can
attach things to it. The most difficult of the three is springs, because they can stretch and compress. How
should we achieve that in Unity? Simply we will attach a script to a cylinder that stores two coordinates
(Transforms in Unity-lingo) it can attach to. Based on the vector between those objects we will stretch,
move and orient that cylinder based on that vector. In the inspector it looks like this
</p>
<figure class="center bordered">
<img src="Blog/Update0/unity_spring_fields.png"
alt="An image of of a coupled spring-mass system as a chain of three springs and two masses">
<figcaption>
Unity fields for setting the connection points of a spring.
</figcaption>
</figure>
<p>
Let's add a couple of cube that move up and down and attach their Transforms to the spring to test that
our stretchiness works.
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/Iwt6dKgRRMI?si=1YNvBj25eockP65u"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
<b>IT WORKS!</b> What next? Well let us set up a scene where we can do our little experiment. Just
two walls, a floor and some light adjustments should work (we'll maybe make it more
beautiful later on).
</p>
<figure class="center bordered">
<img src="Blog/Update0/unity_scenery.png"
alt="An image of the scenery in the Unity Editor as two walls and a floor">
<figcaption>
The scenery of the experiment in Unity Editor
</figcaption>
</figure>
Alright the stage is set! In the next update we will get our hands dirty with some physics and numerical
integrators!
</article>
<article>
<h3>Update 1 - Let There Be Waves</h3>
<h6>26th of February 2024</h6>
<p>
Welcome back! Today's update will be filled with mathematics and physics but the results will hopefully
be
satisfying! Let us begin by creating a <abbr title="Coupled Spring-Mass System">CSMS</abbr>. We create
an object which we will use to generate the CSMS and handle the physics for it. We give it the number of
masses and it subdivides the vector between the walls into small parts in which we will place masses.
Between two masses (or wall and mass) we put a spring whose connection points are the masses. The
results
look like this:
</p>
<figure class="center bordered">
<img src="Blog/Update1/csms_generated.png" alt="An image of the unity">
<figcaption>
The CSMS generated in the Unity Editor
</figcaption>
</figure>
<p>
Alright, now it is time to add some forces on this CSMS. Take any mass at coordinates given by \(X_i =
(x_i, y_i, z_i)^T\) and with mass \(m\) (to avoid confusion I will use 'mass' for the physical property,
and 'body' for the object that is a <em>mass</em>) in the system it will experience a number of forces:
<ul>
<li>
<b>Gravitational Force</b>, given as \(F = -mg\hat{y}\) where \(\hat{y} = (0, 1, 0)^T\), or in other
words
a force pointing downwards (in Unity The y-axis in the up-down axis, so we will use that convention
here too), which is equal to the mass of the object times the gravitational acceleration which on
Earth is \(g \approx 9.81 ms^{-2}\).
</li>
<li>
<b>Spring Forces</b>, given by <a href="https://en.wikipedia.org/wiki/Hooke%27s_law">Hooke's Law</a>
as \(F_\text{spring} = -k\left[(\lVert\Delta X_{i, i-1}\rVert - R)\frac{\Delta X_{i,
i-1}}{\lVert\Delta X_{i, i-1}\rVert} + (\lVert\Delta X_{i, i+1}\rVert - R)\frac{\Delta X_{i,
i+1}}{\lVert\Delta X_{i, i+1}\rVert}\right]\), where \(\Delta X_{i,j} = X_i - X_j\), \(k\) is the
spring constant and \(R\) is the rest length of the spring. The expression is combined the spring
forces from the springs from both sides of the body. From now on we will reduce the large expression
inside the square brackets to just \(\Delta X_i\).
</li>
<li>
<b>Damping Forces</b>, given as \(F_\text{damping} = -\gamma \dot{X}_i\), where \(\gamma\) is the
damping factor and \(\dot{X}_i\) is the velocity (first derivative with respect to time) of the
body.
</li>
<li>
<b>Driving Force</b>, given as \(F_\text{driving} = F_0\cos(\omega_d t)\hat{y}\), which is
essentially a force that is given by a sinusoidal oscillation with amplitude \(F_0\) and angular
frequency \(\omega_d\). For now the driving force is in the \(\hat{y}\)-direction. We can actually
add this in different directions by making \(F_0\) a vector of amplitudes and multiplying by
different cosine functions with different frequencies, and even phases in each axis. We will do
that later on.
</li>
</ul>
How do we combine all these forces? The answer is <a
href="https://en.wikipedia.org/wiki/Newton%27s_laws_of_motion?#Second_law">Newton's Second Law of
Motion</a>:
\[F_\text{total} = m\ddot{X}_i\]
or in other words: the total force on a body is equal to its mass times its acceleration. So, what we get is
the following:
\begin{align*}
F_\text{total} &= F_\text{gravity} + F_\text{spring} + F_\text{damping} + F_\text{driving} = \\
m\ddot{X}_i &= -mg\hat{y} -k\Delta X_i - \gamma\dot{X}_i + F_0\cos(\omega_d t)\hat{y}= \\
\ddot{X}_i &= -g\hat{y} - \frac{k}{m}\Delta X_i - \frac{\gamma}{m}\dot{X}_i + \frac{F_0}{m}\cos(\omega_d
t)\hat{y}
\end{align*}
If we make each body have the same mass then we can forget about the mass and give the parameters to the
simulation as values <em>normalised</em> by the mass. So the equation reduces to:
\[
\ddot{X}_i = -g\hat{y} - \omega^2\Delta X_i - \Gamma\dot{X}_i + \Lambda\cos(\omega_d t)\hat{y}
\]
(the reason the factor in front of \(\Delta X_i\) is \(\omega^2\) is due to solving the equation of motion
of the harmonic oscillator analytically and getting \(\omega = \sqrt{\frac{k}{m}}\) as the natural frequency
in the solution, so we will use that here too)
</p>
<p>
'Alright, alright,' you may say. 'A non-homogenous second order differential equation‽ How will we solve
that?' Good question! We must delve in the world of Numerical Analysis and ask for the assistance of the
numerical integrators. We could use <a href="https://en.wikipedia.org/wiki/Euler_method">Euler's Forward
Method</a> but that is not stable enough (yes, it sends everything to everywhere in seconds). How
about the famous Runge-Kutta methods? And more specifically, Runge-Kutta 4? Yes, that works! I won't go
to the details of how the Runge-Kutta methods works, so I refer to the <a
href="https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods">Wikipedia page</a> and the book
<em>Numerical Analysis</em> by Timothy Sauer.
</p>
<p>
So, we start with that static CSMS, and for every body we do a single Runge-Kutta 4 iteration once each
update (FixedUpdate in Unity with fixedDeltaTime set to 0.005s in order to make the calculations easy
(fixed increments) and stable (small increments)). We do, however, only add the driving force
\(F_\text{driving}\) so the first (leftmost) body, and we will see how the wave propagates. Let us see
the results for the following parameters:
<ul>
<li>\(g = 0\) (we want to show the effects of oscillation for now)</li>
<li>\(\omega^2 = 100\)</li>
<li>\(\Gamma = 0.5\)</li>
<li>\(\Lambda = 5\) </li>
<li>\(\omega_d = 1\)</li>
</ul>
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/MITmsFfUQVE?si=rJe8SEPLMK_I7T1Z"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
<b>THERE! THERE!</b> Do you see that? It is the <b>TRANSVERSE WAVES</b> 🥳! Alright alright, how
about
some gravity?
Let us make
<ul>
<li>\(g=9.81\)</li>
<li>\(\omega^2 = 10000\) (otherwise gravity wins over the spring forces)</li>
<li>\(\Gamma = 1\) (for the same reason as above, and since gravity will increase the velocity by a lot
quickly, so we need to <em>damp it down</em>)</li>
</ul>
Let us also start with \(\Lambda = 0\) to let gravity do its work in the beginning. Thereafter, we will make
\(\Lambda = 500\). We will also start with \(\omega_d = 1\) then increment it by 1 thrice and notice
some interesting wave-pattern emerging.
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/N9OCVyoR-uc?si=UsjlC4wA4duUJxtt"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
Oh! The wave are <em>standing</em> still in their place rather than propagate forward, and every time we
increment the integer values of the frequency the number of <em>peaks</em> (called antinodes) seem to
increase by one... interesting 🤔. Anyway, whew! Our mathematical model worked pretty
well! So as the famous (maybe not so famous) saying goes:
</p>
<blockquote>
"The Math is Mathing! The Physics is Physicsing!"
<footer>
<cite>- Anonymous Mathematics & Physics Enjoyer</cite>
</footer>
</blockquote>
For the next time, we will look into longitudinal waves by generalising our driving force to be in any of
the
\(\hat{x}, \hat{y}\) or \(\hat{z}\) direction.
<h4>Sources</h4>
<ul>
<li><em>The Physics of Waves</em> by Georgi Howard</li>
<li><em>Numerical Analysis</em> by Timothy Sauer</li>
<li><a href="https://en.wikipedia.org/wiki/Hooke%27s_law"><em>Hooke's Law</em></a> by Wikipedia
Contributors</li>
<li><a href="https://en.wikipedia.org/wiki/Newton%27s_laws_of_motion?"><em>Newton's Laws of
Motion</em></a> by Wikipedia Contributors</li>
<li><a href="https://en.wikipedia.org/wiki/Euler_method"><em>Euler's Method</em></a> by Wikipedia
Contributors</li>
<li><a href="https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods"><em>Runge-Kutta Methods</em></a>
by Wikipedia Contributors</li>
</ul>
</article>
<article>
<h3>Update 2 - An Slight Turn of Events</h3>
<h6>2nd of March 2024</h6>
<blockquote>
There is nothing permanent except change
<footer>
<cite>- Heraclitus</cite>
</footer>
</blockquote>
<p>
Well well well, there has been a slight turn of events. I presented my idea and prototypes to the course
examiner, and the feedback I got was that in order to get a high grade (hopefully A) I must add a focus
on a research-based topic. I am aiming for a high grade and have thus changed my plans slightly. I
decided to drop the longitudinal wave visualisation part of the project and focus only on transverse
waves. Instead, I will compare the model we discussed in the previous update, which I will henceforth
call the <em>Force Based Dynamics</em> model abbreviated as <abbr
title="Force Based Dynamics">FBD</abbr>, with a model called Position Based Dynamics shorted to
<abbr title="Position Based Dynamics">PBD</abbr>. This model will be based on the paper <em><a
href="https://matthias-research.github.io/pages/publications/posBasedDyn.pdf">Position Based
Dynamics</a></em> by Müller, M. et al. with some inspiration from the paper <em><a
href="http://graphics.berkeley.edu/papers/Liu-FSM-2013-11/Liu-FSM-2013-11.pdf">Fast Simulation
of Mass-Spring Systems</a></em> by Liu, T. et al. regarding damping. So in this update I will
present how PBD will be implemented in this project and show some results using the same context of
the videos in the previous update. So let us get started!
</p>
<p>
PBD uses two components: vertices and constraints. Without going deep into mathematics here, a vertex is
like a body; it has a position \(X\), a velocity \(\dot{X}\), and mass \(m\), whilst a constraint is
simple a rule we apply on the positions of a number of vertices. In our case the constraints will only
be applied to pairs of vertices, and these constraints will be very similar to Hookean spring forces.
They have the form \(C(X_i, X_j) = \kappa(\lVert X_i - X_j\rVert - R\)), where \(R\) is the <em>rest
length</em> of the spring, and \(\kappa \in [0, 1]\) is a <em>spring stiffness</em>-like factor. In
every step in the simulation we estimate the next position of the vertices, then apply the constraints
to optimise the estimations. The way we change these estimations uses some multivariable calculus, but
the final form of the change be seen in step 4 of the algorithm below. The optimised position
estimations become the vertices' new positions. In summary here is the steps of the algorithm in very
high language: after we initialise the \(n\) vertices, we do the following at each step in the
simulation:
<ol>
<li>Update the velocities \(\dot{X}_i\) of vertices \(i=1,2,\ldots,n\) using external forces
(gravitational and driving forces)</li>
<li>Damp the velocities using \(\dot{X}_i \gets \alpha \dot{X}_i\) for some \(\alpha \in [0, 1]\)</li>
<li>Estimate the positions as \(\tilde{X}_i = X_i + \Delta t \dot{X}_i\)</li>
<li>For vertices \(j\) and \(j+1\) add \(\Delta \tilde{X}_j = -\frac{\kappa}{2}C(\tilde{X}_j,
\tilde{X}_{j+1})\frac{\tilde{X}_j - \tilde{X}_{j+1}}{\lVert\tilde{X}_j - \tilde{X}_{j+1}\rVert}\) to
\(\tilde{X}_j\) and \(\Delta \tilde{X}_{j+1} = -\Delta \tilde{X}_j\) to \(\tilde{X}_{j+1}\), for \(j
= 1,2,\ldots,n-1\)</li>
<li>Update the vertices thusly: \(\dot{X}_i \gets (\tilde{X}_i - X_i)/\Delta t\) and \(X_i \gets
\tilde{X_i}\)</li>
</ol>
If we are using immovable walls, then we treat them as vertices in step 4 but don't update their positions
in step 5. You may have noticed that positions are the main focus of this algorithm. Forces are only used if
they are external and are solely used to update the velocity. The rest of the algorithm only uses the
positions to update the velocities and position forward in time. You may have also noticed that even though
vertices by definition use mass, our algorithm does not. This is due to the fact that the if we
assume all the masses are the same and, just like previously, the masses simply cancel out giving us a
massless algorithm. Pretty cool!</p>
<p>
Alright now, how does this look like in Unity? First let us clean things up. We will separate the FBD
code into its own class, and create a new class for the PBD. In the <abbr
title="Coupled Spring-Mass System">CSMS</abbr> let us make it possible to choose between FBD and PBD
in order to make our comparison later. Now let us see the results! First up is the simulation of
transverse waves without gravity.
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/APWlAl8FnnI?si=JvB7rWMf7vhxnoy5"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
It seems to work pretty well! It is a bit janky sometimes but overall it is very realistic! Let us add
some gravity (add more spring stiffness, and driving force amplitude for the same reason as before).
Here is what that looks like
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/p8qkjtipsuM?si=KHx7wyRbWoZLgF7Z"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
Yeah... the start was a bit <em>interesting</em> but overall the simulation looked very realistic!
Things are looking good for the PBD model! Awesome 😎!
</p>
<p>
In the next update, I will try to compare the two models and perhaps optimise the models further if
possible. See you later!
</p>
</article>
<article>
<h3>Update 3 - Measure Twice... Cut Twice 😬</h3>
<h6>9th of March 2024</h6>
<p>
Hello again! Long time no see! I have been working on the report quite a lot recently and also gathered
some data to compare the <abbr title="Force-Based Dynamics">FBD</abbr> and <abbr
title="Position-Based Dynamics">PBD</abbr> models. I have also noticed a small mistake in my
Runge-Kutta 4 iteration which significantly changed the motion of the <abbr
title="Coupled Spring-Mass System">CSMS</abbr> you saw in the videos from the previous updates.
</p>
<p>
Let me start by describing the, very silly 😅, mistake. In the FBD, every iteration one should
use the positions and velocities from the previous step to calculate the new positions and
velocities then after the calculations are done the positions and velocities are updated. See the code
below for the correct way to do this.
</p>
<code style="white-space: pre-wrap;">
for b in bodies {
do Runge-Kutta 4 step for b
store new position and velocity in new_p, new_v
}
for b in bodies {
b.position = new_p
b.velocity = new_v
}
</code>
<p>
Instead of updating at the end, I updated the positions and velocity immediately after calculation
like so
</p>
<code style="white-space: pre-wrap;">
for b in bodies {
do Runge-Kutta 4 step for b
store new position and velocity in new_p, new_v
b.position = new_p
b.velocity = new_v
}
</code>
<p>
And since the next body uses the previous body for spring calculation the position of the previous body
have already changed and the forces become unbalanced creating a more 'ropey' effect. The new and more
correct FBD simulations look like this now.
</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/MznIZKPulSA?si=kClwG_W7QQOZPr1f"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/XL78FgudVTI?si=DNmQ_L9_Xx-48sPW"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>
Very less ropey and more stiff-springy, especially in the gravity version where I increased the
\(\omega^2\) to avoid the spring breaking.
</p>
<p>
Now, on to do some comparisons. I did a brief study of the motion of both models in the report but I
will not do that here because well, you can see the motion in the videos. I will instead show a small
performance analysis I did. I ran each models with 50, 100, 250, 500, 750, 1000, 1500, 2000, and 3000
bodies/vertices then measured the time it took to call the step method. This was done classically by
storing the time before the call then measuring the difference after the call finished. The results are
in the plot below.
</p>
<figure class="center bordered">
<img src="Blog/Update3/model_iteration_time.png"
alt="A plot of the time-cost per step per number bodies for the FBD and PBD models">
<figcaption>
A plot of the time-cost per step per number bodies for the FBD and PBD models
</figcaption>
</figure>
<p>
As you can see, PBD is a lot faster because it does one 'motion calculation' per step whereas the FBD
with Runge-Kutta 4 does four. Therefore we see that the time differs by around a factor of four.
</p>
<p>
That is it for today. I will probably do another update with the final demonstration and some conclusive
thoughts. Until next time 👋!
</p>
</article>
<article>
<h3>Update 4 - The Final Update</h3>
<h6>12th of March 2024</h6>
<p>Greetings! This is the final update and for that I have recorded a small demonstration showing everything
(I hope)
about the two models. Enjoy!</p>
<figure class="center bordered">
<iframe width="80%" height="400" src="https://www.youtube.com/embed/m0da07iXDm8?si=vYON2CEmCBLnTnUt"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowfullscreen></iframe>
</figure>
<p>(If you are wondering the music is <em>Danse Macabre</em> by Camille Saint-Saëns)</p>
<p>
The models seemed to work very well! Did you also see how the Euler Forward integrator makes everything
go CRAZY? Yeah, that is why Runge-Kutta 4 is better in this situation.
</p>
<p>
Regarding the project, it was honestly amazing! I learned a lot about physics and computer graphics. I
have some regrets regarding the process but I learned a lot about planning and researching which will
definitely come to use later in life! In summary, my advice is to start focusing on a topic early on
rather than try to learn everything about a topic, especially when the timeframe of the project is very
limited. It will reduce the risk of burnout!
</p>
<p>
Finally, I would like to thank the course-responsible and teaching assistants of DD1354 for the numerous
feedback opportunities they provided! As a last remark, I will list some references which I found
interesting regarding <abbr title="Position-Based Dynamics">PBD</abbr> and similar, since that model was
especially useful in computer graphics.
</p>
<ul>
<li>Müller, M., Heidelberger, B., Hennix, M. and Ratcliff, J., 2007. <em>Position based dynamics</em>.
Journal of Visual Communication and Image Representation, 18(2), pp.109-118.</li>
<li>Nealen, A., Müller, M., Keiser, R., Boxerman, E. and Carlson, M., 2006, December. <em>Physically
based deformable models in computer graphics</em>. In Computer graphics forum (Vol. 25, No. 4,
pp. 809-836). Blackwell Publishing Ltd.</li>
<li>Wang, Y., Xiong, Y., Xu, K., Tan, K. and Guo, G., 2006, November. <em>A mass-spring model for
surface mesh deformation based on shape matching</em>. In Graphite (Vol. 6, pp. 375-380).</li>
</ul>
<p>
Alas, this marks the end of our journey! Thank you for reading my blog! Farewell 🫡!
</p>
</article>
</main>
</body>
</html>