Ultrawidify and the Improper Cropping

Yet another day, yet another post about stuff going wrong. This time, I’ve got a bug report that “videos are jumping around” on Facebook and some other pages. I tried to verify the problem … and everything worked fine for me. Then I decided to boot up Windows and there it was — the problem as described. So nice — we have a problem that happens on some operating systems and doesn’t on others, even though that shouldn’t be the case in theory.

But eventually, the issue was reproduced and that’s all that matters. The issue appears very familiar — it has been observed on reddit before.

A video and a player

In a very ELI5 way, every webpage is made out of a bunch of rectangles (layers, elements), one within another. In order to properly crop a video, we must know which of these elements is actually the player (‘player’ element is to our video what picture frame is to a picture), and we need to know which element is the player element. Picking the wrong element can result in extension cropping to little, too much, or moving the video out of the picture altogether.

We can’t just assume that the first element above the video is a player, either: sometimes sites put addiitonal elements between the two. This is why we need ‘guess’ the player element by looking at the size.

Side note: not all extensions use that approach. Some seem to just assume you use a 21:9 monitor and slap a ‘enlarge this element by 1.3’ on the video element. Great and foolproof strategy for fullscreen. Less great for youtube’s theater mode, twitch with chat opened at the side, or non-fullscreen Netflix.

Legacy and technical debt

The code for determining which element is the player element has some weird quirks thanks to the history of the addon. Most notably, the extension used to work by determining how tall and how wide the video should be back in the day when it was only focused on Youtube and Netflix. This method has a few drawbacks, with most notable ones being:

  1. If you ask browser to tell you the size of the video, it’ll tell you the dimensions you specified
  2. It worked for youtube and netflix, but not for everything else

In general, we can assume that initial size of the player will be exactly as wide as the video or exactly as tall as the video. However, since we actually changed the size of the video (as opposed to telling browser to just enlarge the video by some factor), we couldn’t check for that as if the video was cropped, browser would tell us the post-crop size (and post-crop size is useless for that purpose). Some wonky code was written to deal with this issue and it worked well enough for Youtube and Netflix and sometimes even other sites. However, said code is — in retrospect — pretty bad. Looking at it invokes a few questions that every programmer sometimes asks themselves: “the hell was I trying to do with this shit” and “how the fuck did this even work at all?”

You could farm karma at /r/badcode with this.

Due to problems with #2, a better solution to resizing the video needed to be implemented, and eventually it was in the form of transform: scale(x,y). Using this to crop video (as opposed to modifying width and height attributes of the video) has some nifty advantages: it’s possible to get the size of the video without taking transform into account. This allows us to rewrite the player detect loop in a way that will correctly detect the player element.

Dealing with duplicates

Another thing worth addressing is “duplicates” — that is, what happens when more than one element on our way from video element to the root of the page has the same size. I haven’t figured out what to do in this case, since the correctness of picking innermost over outermost element for player may differ from site to site. In absence of better options, I decided to score every element that could be our player. Rules of the game:

  • Every element that matches our criteria gets 100 base points
  • Elements with 'player' in their ID get 75 bonus points
  • Elements with 'player' in their classlist get 50 bonus points
  • The farther the element is from our video, the more penalty points it gets. First match gets 0 penalty points, second gets one, third gets two and so on.

I haven’t had the chance to test this thoroughly, so results may vary.

That’s it for the day.

Did Toothless Really Have No Choice?

Sorry, but Toothless definitely had a choice, no matter how you slice it.

So there’s been this tumblr blog that got shared on one of my discords. For those who don’t want to follow, here’s a TL;DR.

Remember this scene from How To Train Your Dragon 3, where Toothless basically orders dragons into cages?

  • OP got their jimmies rustled by people saying Toothless shouldn’t have pretended to be French
  • And in the follow-up post, they basically stated that Toothless had no other options but to tell dragons to back off even if you ignore the Thotfury issue.

So let’s take a look at why this is wrong, no matter how you slice it.

If Grimmel Killed the Light Fury

… then he wouldn’t live for long. He wouldn’t even live for short. He’d immediately get blasted apart by every single draconid on Berk.

Contrary to the popular belief, the weapon specimen that Grimmel wields in that scene is not an M4A1. It’s a standard-issue medieval ballista. Its fire rate is much, much lower than that of M4A1 and reload times are pretty awful to the point getting more than one shot out of ballista in any given minute would likely be a massive achievement. In any case, once Grimmel fired his first shot, dragons and wyverns would have forever to blast him.

Obviously, we’re going to face a minor issue here. First of all, you can’t damage the dragon-powered quadcopter Grimmel flies on. That problem is easy enough to solve (just grab him and/or knock him off his stand). The other problem is that precision-blasting Grimmel off the quadcopter leaves the dragon-quadcopter without its pilot. This is a slightly awkward situation, because there’s no telling how deathgrippers would react. However, all the possible reactions generally fall into three groups:

  1. They hover in place
  2. They continue moving towards the ships at the unchanged pace
  3. Panic like my XCOM2 squad the moment they catch a whiff of aliens.

Option 1 is ideal and makes rescuing Toothless easy. Option 2 is a bit worse, but still ideal. There’s six death grippers (four on quadcopter + two solo) facing Toothless’s entire army, which means that Toothless would be returned to the island before he made it halfway to the ships.

Option 3 is where things get a bit more problematic. Panicked death grippers translate into problems for the quadcopter. Best case, quadcopter will become unstable. Worst case, death grippers end up knocking themselves out and freefall to their death. The chance of anyone falling to their death is still borderline negligible in this case — if four death grippers were enough to hold the quadcopter in the air, dozens of Berk’s dragons shouldn’t have a problem holding up the damn thing in the air.

Here we can see that the quadcopter isn’t hovering above the land at this point — it’s decisively over the cliff edge. But keep in mind that New Berk is three kilometers tall (from sea to the lake). If the quadcopter starts losing altitude, team Berk has lots of time to catch it.

If Thotfury gets killed, then it’s game over for Grimmel while team Toothless wins with zero additional causalities.

And if you wondered which of the three options is going to happen if you remove Grimmel from his seat without damaging the quadcopter, here’s your answer. Death grippers continue hovering in place.

The quadcopter only started crashing once Toothless dropped his mixtape.

Could Grimmel be Disposed of Before He Gets a Chance to Kill Thotfury?

Let’s just put things this way. Grimmel doesn’t have eyes on his ass. Have some dragons go around and attack him from the back.

The obvious issue with this plan is that two solo-flying death grippers could notice them and alert Grimmel. That still doesn’t mean Grimmel would get a chance to kill the light fury. The moment he turns around to check what the ruckus behind him is the moment he’s not aiming for the light fury. And the moment he’s not aiming at the light fury (or just being generally distracted) is an opportunity to get rid of him without thotfury getting it.

Would Grimmel Kill the Light Fury

Given everything said so far: lol.

Of course he wouldn’t. Not only would he no longer have a bargaining token for Toothless — once Light Fury is dead, there’s literally no reason for draconids to take it easy on Grimmel; and as first section shows us: Grimmel would get absolutely annihilated in this case.

His threats were empty.

Coulda called his bluff with little consequences.

“And the Flock was Never in Danger”

One of the reblogs of this post states:

And the flock wasnt really in danger. The hunters left the cages unlocked bc they thought Hiccup wasnt coming, and Toothless obviously knew he would bc he then immediately commanded the three like, second in command dragons to break out and go fight

What? That’s patently false.

First of all, the trappers didn’t leave the cages unlocked because they thought Hiccup wasn’t coming. They left them unlocked because “plot convenience.”

If you take a closer look at the cages, there’s two things one can notice.

  1. All cages come equipped with bolt locks and nothing else. Nobody is using padlocks or keys, because why would you? Literally no benefit. Keylocks are mighty expensive and time consuming to manufacture and offer no extra security when you’re trying to keep a dragon in the cage.
  2. Doorhandles are also nowhere to be seen, which means that if the door is not locked with the deadbolt lock, it can be easily opened from the inside of the cell.

Let’s take a look at some screencaps:

No keyholes, no padlocks.
95% chance this is just a regular deadbolt lock.
Hey look, it’s deadbolt locks.

The second thing worth mentioning is that trappers were, in fact, locking the cages. However, since there was more cages than there was trappers, the trappers couldn’t lock everything at once. I was a bit unfair when I called it a ‘plot convenience’ earlier, I know.

Trappers in the process of closing and locking Cloudjumper’s cage.

Just because the trappers haven’t managed to lock all the cages in 60 seconds flat, that doesn’t mean they haven’t been locking them.

Snotlout is unlocking a locked cage.

So that statement is a bunch of ballooney. But then again, this second reblog is so dumb that it barely warrants a response.

Anyway, that’s it for the night.

Ultrawidify: The Twitchy Twitch Problem

Ultrawidify has been seeing some issues with constant aspect ratio readjustments. This post examines and explains why and how these issues happened.

I don’t think I’ve boasted about developing Ultrawidify much on this blog. Maybe I should have, but then again: the audience of this blog is a) people who know me and b) people who use Ultrawidify and were bored enough to click that link in update notes. The point is — you’re all familiar with this extension.

A while back, I’ve noticed an issue on Twitch. It turned out that the video was a bit … well, twitchy. However, the issue seemed to be fairly uncommon, so I made a note in my test videos file and decided to kick the can a little farther down the road. “No big deal, it surely can wait.”

Well, turns out that the issue was a bigger deal than I thought. I’ve recently accidentally visited my facebook feed, and the twitching issue appeared — except worse. I tend to avoid twatter as well, but long story short: I stumbled on a tweet with embedded video.

What a good time for a #literallyshaking joke.

On the plus side, the issue happens very often (more often than auto-detection interval), and it happens equally often even when the video is paused. Here we get the first (and perhaps the only) bit of good news for the day: auto-detection isn’t to blame — and since there’s exactly one other thing that could cause this behaviour, this means I already know where the problem is.

In Search of the Problem

In order to understand whats and whys of the problem, we have to take a quick look at how Ultrawidify crops the video. It’s very simple: it finds the video element and basically tells the browser: “Make sure the video is this wide and this tall and then enlarge it by this much,” where “this much” is whatever number auto-detection script (or user intervention) spat out. In programmer jargon, that’s called setting style string.

For technical reasons,1Blame the video alignment feature for that! Ultrawidify’s auto-detection will also “correct” the aspect ratio when there’s no need — in cases like this, the video would be enlarged by a factor of 1: same size as before.

This should, in theory, do the job just fine. In practice though, Ultrawidify isn’t the only thing doing that. Some sites will also tell the browser to make the video element that big because something on the page changed (example: switching between normal and theater mode on youtube). This effectively undoes any changes Ultrawidify has made to the page. And we really don’t want that, since that has the potential to uncrop the unnecessary letterbox.

Solution to this problem is easy enough at the first glance: we’re just gonna tell Ultrawidify to watch for sites trying to meddle with the video size. If the website tries to change anything, Ultrawidify will undo that change immediately. I think you can see where this is going.

Yes. Twitter is also watching for anything that would meddle with video sizes. If it detects that something changed how big the video element is supposed to be, it will undo that change.

Twitter’s behaviour would also break crop and stretch functionalities, though I don’t think improperly cropped videos are common on the platform. I have noticed improperly cropped videos on facebook, though.

Developer tools seem to agree with this assessment. In inspector view, video element is blinking like there’s no tomorrow while in the console, Ultrawidify is seen setting the same style string over and over again, and the zoom factor is always one. At this point you may wonder why the twitchy video if ultrawidify sets the zoom factor to one, and the answer is simple: twitter doesn’t.

Through the magic of “inspect element” we can see that Twitter is zooming the video ever so slightly (by a factor of 1.005).

With Twitter insisting that the video should be zoomed by a factor of 1.005, Ultrawidify wanting a zoom factor of 1, and neither being very keen on letting go. And this spells trouble for us.

Ultrawidify vs. twitter, 2019 (colorized)

In Search of Solution

If the site will just undo our changes, what can we do? Well, it turns out that there’s a way. As it turns out, there’s actually two sorts of CSS styles: author styles — which is CSS defined by the website you’re visiting; and user styles.

Through the magic of user styles, you — the user — have the final say over how the browser will display the site. If Facebook says the background of the page needs to be white, and you have user style that says the page background should be whatever meme is popular this week … well, tough luck Facebook. Nothing can override user styles, which makes them the perfect “fuck you, you’ll do what I tell you” card. We’ll take it.

There’s another piece of good news: you don’t have to define the styles in advance — you can make them up on the spot and tell the browser to use that. WebExtension API allows us to do that. There is a few caveats, though. Besides making up the style, you also have to make up a class name, attach it to the element and hope that the site won’t remove it. If you want to edit your style, you have to throw the old style at the browser and tell it that you want it removed. You also have to create a brand new style, tell the browser to use that.

Fortunately for us, it currently seems that the sites aren’t as thorough with removing “unauthorized” CSS classes from elements as they are with “unauthorized” styles, but that’s all it is for now: a rule of thumb that everyone seems to follow, until someone doesn’t.

Well, that was a fairly easy fix, wasn’t it? After all, it required very little work from us (the user-style injecting is already implemented — as a part of dealing with vimeo and its special snowflakey bullshit). Performance seems comparable to what it was before (albeit a tiny bit slower to react to changes) and all is well.

Further testing reveals that tie twitching image issue was fixed on Twitter, probably on Facebook as well. At least as far as Firefox is concerned.

Now it’s time to test in Chrome.

Hotel California

So I whip up my “variable aspect ratio” video example on youtube and start sweating profusely. Will the extension work?

Because there is one problem with my solution: Chrome doesn’t support tabs.removeCss(), which turns programmatically generated styles into a bunch of unsuspecting fellows checking into a hotel California. Sure, you can insert the style at any time you want, but it can never leave.

Chrome and chromium pls. The worst thing is that the “feature request” for this was opened in 2016, and the patch has existed for over a year and a half at this point (since February 2018).

Not being able to yank the previous style when adding a new one is problematic the same reason you telling your kids to wear a white t-shirt where your partner told them to wear a red one a minute ago is problematic. It’s also problematic the same reason putting a new highway tolling sticker on your windshield without removing the old one.

It can get messy real fast.

Fortunately for us, Chrome takes the “common sense” (and standard-compliant) approach to handling the first problem: in case you have multiple conflicting definitions, it’s gonna respect the last one. This makes it a bit easier to ignore the second problem, though having tens or in the very worst case (frequent aspect ratio changes, frequent resizings of the player and browser window and watching a video in the same time for long periods of time) even hundreds of conflicting styles shouldn’t be too much of a problem.

This is a bigger mess than How To Train Your Dragon: The Hidden World, even though that theoretically shouldn’t be possible.

Nonetheless, we’ll have to settle for this very terrible practice when in Google Chrome. I’ve ran out of fucks to give and the new ones are expected to arrive only in about a month.

Now, I could probably spend another day trying to deal with Chrome shittiness and try to invent new workarounds, it’s easier to just sit back, REEEEE at Chrome, use my userbase as a glorified guinea pigs and hope that people who watch youtube without closing/refreshing/opening video in a different tab won’t have their performance degraded.

And that’s a very dangerous game. I should know: the first update where autodetection was introduced had major performance issues if you watched videos in a tab continuously for long amount of time (Chrome was a complete lagfest in ~5 minutes of watching video, while performance in Firefox was somewhat better (and very dependent on your hardware) — just good enough that it escaped my testing. It’s been two years now and my ratings on Chrome Web Store still haven’t recovered.

I’ll still take the gamble though, against my better judgement.

At this point, I suppose it’s time for a PSA:

Public service announcement: Google Chrome is garbage (and so are all other Chromium-based browsers). If you aren’t already, you should really use Firefox instead.

Thanks for coming to my TEDx talk.

“You’re just like that coffee machine, y’know … from bean to cup, you fuck up.”

The Case of Twitchy Twitch

So the extension stopped doing twitch things on twitter and the new system for resizing video works. But after a quick visit to the out of season April fools joke (a.k.a. the immortal Blizzcon stream from hell) it turns out that the video still appears … twitchy, which means that twitching on twitch was a result of a different problem.

The ball is now back in the court of automatic aspect ratio detection. To be fair, that twitch issue is a problem with autodetection was known for a wihle. After all, most streams don’t have this problem, and the fact that this doesn’t happen when autodetection detects proper letterbox (or that aspect ratio correction works at all — on Twitter, it wouldn’t!) should be plenty of evidence to support that:

Look at how twitching stops as soon as WoW cinematic begins about 12 seconds into this loop.

This issue smells like a video with a very tiny, nigh unnoticeable black border. Not wide enough for you to notice, but just enough to trigger autodetection. 30 seconds of (local only) defacing, it turns out that our intuition was correct:

Notice this thin black line at the top of the video? It’s only about a pixel or two wide on the source stream, but with video and page background set to white and gray it quickly becomes apparent. Video element is outlined with red.

Turns out that this is a very interesting edge case, but to understand how things went wrong we’re gonna need a quick crash-course in how auto-detection works. The key steps are:

  1. Start counting rows that contain nothing else than black pixels, from top and bottom to the middle. Each row has a number: top row is row 0, last row has a number that’s one less than the number of rows. Due to performance reasons, we only pick a few columns of each row that we actually check for the presence of a (non-)black pixel.
  2. Remember the first row that contains black pixel (on both ends)
  3. Calculate the height of the black bars
  4. Check whether top and bottom black bar are roughly of equal thickness.
    We don’t require black bars to match exactly because:
    1. in theory, the “not black bars” portion of the video is not guaranteed to be of even height. In cases like this, the top and bottom black bar could differ by 1px
    2. in practice, not all pre-letterboxed videos are exactly centered. Case in point: first few seconds of this video.
  5. Calculate and apply aspect ratio. If top and bottom thickness are different, you’ve got two options. Either you over-cut or you end up with a thin black border on either top to bottom. I’m not exactly 100% sure which strategy I’m using: twitch issue suggests I’m using strategy A (overcut), but the previous video suggests black edges are preferable.

That’s the basic idea behind aspect ratio detection, but reality is far more complicated in order to crack down on false positives. This means that we want to avoid unnecessary checks if possible.

Once we determine the correct aspect ratio, we can take a shortcut. Since we know where black bars end and the image begins, we can just check these four rows:

Where ‘n px’ and ‘X%’ are some adjustable thresholds.

The reason why we aren’t checking the rows exactly on either side of the edge is to dodge compression artifacts and blurred edges.

Naming and shaming: Disney (Star Wars: Solo trailer).

So fine, we save numbers of these four rows. Top outer row is the last row in which we failed to detect a non-black pixel minus a pixel or two for safety, top inner row is the first row in which a non-black pixel was detected plus a pixel or two of safety margin.

There is, of course, a problem. If the top black border is one pixel thick and bottom black border doesn’t exist, the extension would have us check rows that don’t actually exist. Since the rows we need to check don’t exist, we can assume that black bars either don’t exist or are too thin to actually annoy anyone. When that problem happens, the extension resets the aspect ratio back to what it was originally.

Here’s a fun fact tho: this step — saving numbers of the four rows — happened only after extension already corrected aspect ratio. Normally that’s not a problem, because videos don’t have one pixel thick black bars on the top and no black bar at the bottom. They would either have substantial letterbox, or none at all.

In this particular case, though, things were a bit different. Ultrawidify would detect the one pixel letterbox and correct it. Then it would check where the black bar edges are and apply the safety margins. Safety margins would be out of bounds.

Would say Ultrawidify and undo the correction right away, and this cycle would repeat forever (or at least as long as one-pixel and zero-pixel letterbox was present).

Fortunately enough for us, the fix for that is easy enough: we try to save the edge rows, and only issue aspect ratio correction if the result isn’t bogus.

And that’s about it for today, really.

Safety of New Berk and The Hidden World: an analysis

If shadiversity can do a whole series analyzing defendability of various locations from Game of Thrones, I reckon I can do one for How To Train Your Dragon 3 as well.

If Shadiversity can do a whole series analysing the defendability of various locations from Game of Thrones … boy, let’s do one for HTTYD3 as well.

Fair warning: I’ve already written this post on reddit, but never really cared to port it over to my blog as well.

The warning about excessive musical references still applies here.

Just surrender here tonight: Safety of Berk

By back-of-the-envelope calculations, the settlement of New Berk lies about 3 kilometers above the sea level — and we aren’t talking about 3 kilometers of a gentle Sunday walk slope. We’re talking straight up, vertical wall. The writers stated that Minecraft Chunk Error is accessible only with the help of dragons, and everything — from the visuals to the height estimates — confirm that.

Back in the medieval ages, height advantage was everything. If a hostile army came to the doorstep of your castle and your castle wasn’t high enough, you’d be in danger of getting flattened by a 90 kilogram rock fired from over 300 meters away when busy with your evening number two1Note: this is not how Erasmus of Lueg actually died, but it does make for a more entertaining story.. New Berk, however, is far too high for trebuchets to reach — or even cannon balls — to reach it, let alone do significant damage.

99 Luftballons

Conquering Berk only becomes technically possible with the advent of aircraft in the late 18th century as even early hot air balloons were reportedly capable of floating at around or even over two kilometers above ground — even though their relatively slow speed and susceptibility to adverse weather doesn’t make them too feasible. In practice, conquering the New Berk only becomes realistic prospect in the 20th century with the invention of an airplane, and subsequent improvements thereof.

Alternatively, you could just conquer New Berk with dragons and wyverns that you’ve captured ahead of time. The trappers still have them. Just saying.

Trapped on an island, lost at sea

A man has need, but those needs aren’t just booze. It’s food as well.

Impenetrable geography means very little if the hostile force can just starve you out to death. On the first glance, this seems likely: encounter with Grimmel’s armada certainly put New Berk on the map. With likely rumors that Berk is hiding dragons for themselves, they could easily send another armada that would surround the island, capture every inbound or outbound ship and keep an eye on the island. With no dragons to help them out and carry them over blockade, the vikings can only wait on the island and hope that their food supplies last longer than invaders’ patience.

But it turns out that Berk may have lucked out in this aspect as well. The island is pretty big — and although there doesn’t seem to be much farmland there as most of the island is either a lake or steep slopes, the situation is not completely hopeless. After all, if Inca could figure it out, then Berk should be able to as well.

That is, of course, assumes Berk doesn’t mostly or majorly rely on fish for their food as in that case, their chances of siege survival would dwindle to single digits. This isn’t as unlikely as one would think: while the lifts are very slow the way the movie presents them, using a counterweight and water power from the nearby waterfalls would be a quick way to improve the lifting speeds massively — to the point a ship could be lifted in a reasonable amount of time that wouldn’t render fishing ineffective.

There is no strength in numbers

Have no such misconceptions..

I won’t cover why separation is bad from safety perspective because this was covered elsewhere in great detail already. Just giving a shout-out.

Now that the safety of Berk is dealt with, let’s move to take a closer look at The Hidden World.

Here at The End Of The World: Safety of The Hidden World

Alternative title: Through dungeons deep, and caverns old but I outright refuse to give that hot trash the honor of having a title feature not once, but twice.

The Drakkars were surprised

Let’s be honest for a moment: the water around The Hidden World entrance is very shallow, likely on the order of magnitude of a meter or two. The screencaps seem to confirm that:

The water here looks pretty shallow. No way you could dunk a full Hiccup into that stream. Some parts of the pic seem to even violate the physics in a very Cities: Skylines way, with water flowing uphill.
Judging by photos of sea shores, the water around the hole looks shallow enough for a man to stand in with no problems (assuming the water was still)

In all those close-up shots, you can see that the rocks poking above the water are more numerous than the rocks a disgruntled DM keeps behind their screen (and they’re bigger, too):

If you design a ship with enough draft and a hull that doesn’t roll once you hit those rocks, you’ve got yourself an island. Load the ship with rocks and you quickly discover that you don’t even care if the ship is seaworthy after hitting said rocks: you’ve just made yourself a small island and a mooring point for future ships.

This would allow the dragon trappers to just make a big ship and run it aground — be it on the rocks that poke out of the water or on the seafloor. Ensure additional anchoring if necessary. Congrats, you have a platform.

And when you took a look at how mighty the waterfall is at it’s bottom, saying that waterfalls are deep on the top becomes a very tough sell. We’re at the bottom of this hole where the waterfall is at its narrowest — yet there’s barely any water?

The waterfalls here amount to not much more than a drizzle.

Assuming actually competent villains, I don’t think anyone is in any danger of getting swept off here.

We lift together

The trappers won’t be making peace to build our future, though. That would be hiccup, and he just threw that chance away. Alternative title: Are you coming in so we can carry this on?

Once you get yourself a platform or a dozen on the edge of The Hidden World, you can start working on descending into the hole. This turns out to be fairly easy: we know that world tech level is sophisticated enough to build lifts if there’s a need. Not only has New Berk managed to achieve that feat — and to top it off, they seem to be using some special elven rope that’s both light and unbreakable. Powering said lifts would also be fairly easy, thanks to the near infinite water supply all around you.

Sure: The Hidden World entrance resembles an inverted wedding cake, but that’s not a problem: you can build multiple lifts: one to reach the first stage, another to reach the bottom. This will be mildly annoying thanks to all the water, but that’s nothing that can’t be worked around.

Judging by the movie stills, the hole is pretty shallow as well. During the shot where Astrid and Hiccup enter The Hidden World, you can see that the water behind them is lit directly by sunlight, which means that the hole probably can’t be deeper than a kilometer if we are really, really generous:

There’s approximately zero chance this isn’t sunlight on the upper portion of the waterfall.

But if you find the second stretch of the way down too challenging, you can do something you can’t do on New Berk (without getting noticed):

Welcome to my mine, we are mining dragons

The part about fighting mobs is up to discussion. Alternative title: I dig my hole, you build a wall

Brothers of the mine, rejoice!2I’d link the original version by Yogscast, but once you hear the Wind Rose cover the original one kinda sounds kinda meh. No offence, I know it’s hard to compete with people who sing for a living. Raise your pick and raise your voice! Since The Hidden World is completely surrounded by rock, you can dig a a dinky dinky hole3Jesus fucking Christ, is that a third Minecraft reference in a span of a paragraph? Tam, you need to put a damper on this shit. parallel to the tunnel. It’s gonna take a while, but it has some advantages:

  1. It’s safer. Dragons can’t get you there.
  2. You get free rock

You can use that free rock to build a dragon-proof fort (stone and water don’t burn, usually) or build a massive dike around the entrance so you don’t have this pesky water to deal with anymore. And when the water’s no longer a problem … well you could just build a couple more lifts, really.

Now we’re (not) defenseless in a land where dragons rule

You think dragons will just wreck anyone who comes near The Hidden World with such fury that doritos would start flying everywhere? Not gonna happen.

Next time someone tells you that US has the biggest navy in the world, show them this picture.

The armada has a massive numbers advantage. For every ship dragons would potentially destroy, three would take its place. They could easily surround The Hidden World to the point — if not because they’d run aground, they’d manage because they’d get stuck trying to fall in all at the same time. They will also have a height advantage by the virtue of entrance to The Hidden World being below the sea level. Once the trappers have made their base, they can use ballistas that shoot spears, bolas and nets in order to down anything that comes their way.

But it gets worse for dragons and wyverns: not only are they at a massive disadvantage both due to height and number of the attackers — they’re also being massively bottlenecked by the size of the entrance acting as a three-lane toll on a dozen lane highway.

All in all, this fight looks like a reasonably safe win for humans, but with one caveat: you need army leaders whose IQ wasn’t reduced to single digits for plot reasons.

Moral of the story: If you want an impenetrable location with maximum safety, you should be looking at New Berk (or distribute the dragons around the original archipelago)

Thanks for coming to my Ted talk.


But we’re not done yet. Bonus round.

High to the skies, across the seas: Safety of the Old Berk

I’ve already did write about this once on reddit, but it’s somewhat relevant here as well so we’ll address it.

It’s been established that Hiccup isn’t particularly wise in the second movie already, that he makes emotional decisions in a heat of the moment rather than listen to reason. Had Hiccup started expanding dragons and Berk’s influence around the archipelago, Berk could become a force to be reckoned with — and while the dispersed islands seem vulnerable to attacks at first, it turns out that they really aren’t. It’s possible to work that to your advantage.

Dragons and wyverns are generally faster than ships (unless they’re given invisible engines made of handwavium and the same stuff plot armor is usually made of) — especially adult dragons that don’t have to carry an entire Berk with them. You could use them to patrol seas around the archipelago, spotting hostile ships way before they become a problem.

When the ships are spotted, main settlements can be alerted, coming to aid in very little time. And when other settlements come to aid … well, that gets the attackers stuck between the rock and a hard place.

Expanding all over archipelago makes plenty sense as a solution to the overpopulation problem — way more so than cramming everyone into a single space.

How Tall is New Berk — a Follow Up: Unofficial Official Height

There is some long-standing things I wanted to address about my estimates of the height of New Berk in How To Train Your Dragon 3, but I could never be bothered to actually follow through with it.

I’ve been thinking about making another round of “how tall is berk” calculations almost ever since the original blog post went up, as I figured I could make those eyeball estimates a bit more accurate — plus, the comment section on reddit did cause some commotion. Eventually I realized that I really can’t be bothered spending a weekend crunching through numbers, so I’ve decided to abandon the plan.

But there’s one thing I really wanted to address still. If you’ve been following my paper napkin calculations regarding aspects of New Berk, you might have noticed that I’ve been using two figures for the height of Berk: the pi kilometers one, which was calculated by pixel licking, and a two kilometer one. I guess it’s high time I explain where the two kilometer figure comes from.

There is this one redditor who claims to work for Dreamworks, and he claims that he can measure the heights of the island. The redditor was kind enough to give us the height of the lake on the New Berk (43,677 ft) and the height of the “overlook” (we can only assume they meant the rock the lift is placed on; ‘about 44,097 ft’), we get a difference of 420 ft. This gives us about 21 ft per meter. Converting those measurements back to meters using this ratio gives us the height of just shy of 2100m for the lift (and ~2080m for the lake).

That number is to be taken with a huge grain of salt, though, as the redditor claimed that ‘somewhere in the village’ was ‘about 53k feet above the sea.’ 53k ft is 2.5 km above the sea level, which makes these numbers anywhere between ‘sus af’ to ‘load of bullshit’ — judging by the screencaps, no part of the village appears to be over 400 m above the lake. Even 200m seems a bit much by eyeball estimates.

You can give the redditor a benefit of the doubt that he forgot where his initial measurement was taken from, but I’ll be sitting in the corner, smashing that X.

Un-disputing the total height of Berk

A different redditor has pointed out ‘a flaw’ in my calculations. The comment says that I can’t really determine how tall the island is, because objects further away from the camera appear smaller.

So I decided to double-check where mountains are located.

This isn’t very scientific, I know.

Quick guesstimate says that village and the highest peak should be roughly the same distance from the camera, so our quick guesstimates for total height of New Berk (not just sea-to-settlement) shouldn’t be too far off.

The numbers behind offsetting emissions

This might lean ever so slightly in the politics territory, but here’s a fun calculation. Was just thinking about how big a pile of carbon would I need to offset my CO₂ contributions while on the walk.

Ideally, the CO₂ contributions should be put back underground, so the first idea would be to just cut down bury some trees (after all, once grown, trees aren’t being much of a net CO₂ scrub) – but that would be wrong. Charcoal — being pure carbon and much more stable than biomass — would be much better. Sure, you’ve got to turn wood into charcoal before you do anything with it, but the process of turning wood into charcoal doesn’t produce additional CO₂. This means: charcoal is the way to go.

Now that we know our preferred form of carbon, let’s take a look at the numbers:

  •  EU’s CO2 emissions are ~6.4 tons per year per capita. USA is 16.5. (using data for 2014).
  • Carbon represents 27.3% of CO2 by weight.
  • Density-wise, charcoal clocks between .2 and .6 tons per m3.

If you wanted to sequester the amount of carbon “you” are responsible for, the pile of carbon you’d have to manage would weigh ~1.75 metric tons (4.5 metric tons if you’re in USA). This translates to a nice 2.9 – 8.7 m³ (7.5 – 22 m³ for USA/NA in general) pile of charcoal to bury somewhere at the end of every year.

This, of course, excludes emissions related to cutting down trees, reforestation (!) and transportation; we also assume that charcoal production is using excess power from the wind farms on days when there’s too much wind. The good news, though, is this: most of the per-capita emissions is produced by companies. If you only wanted to deal with the emissions that you cause directly, the pile would probably be much smaller.

Emissions per capita stuff stolen from here.

How Fast Is the Lift on New Berk (HTTYD: The Hidden World)

I was very bored, so I decided to calculate how long would a ride on New Berk’s lifts be. It would be … very long.

There’s very few things to like about How To Train Your Dragon: The Hidden World, but that doesn’t mean they exist. In fact, the lift at the end of the movie is legitimately my favourite thing about it (and I feel a bit bored today). This, of course, means we’re gonna analyze it a bit.

Do you even lift?

We’re gonna pretend that we’re in high school again and that things like ‘friction’ and ‘drag’ don’t exist where we don’t need them to simplify our calculations.

The first question is: how much power do those windmills produce? To start things off, let’s re-cap some already known calculations that should put us somewhere in the ballpark.

The image doesn’t state the height of the hut outright, but re-calculating hut height from the pixel counts give us 10 meters.

I’m not gonna go into this level of detail today, I’ll just do the eyeballing. If you take the right lowermost blade of the big windmill and measure its length, you’ll get about 110px. Using same conversion factor as we did for the viking, we get about 6.6m for the long side of the blade on average. The width of the blade seems to be about 30px, or about viking-sized — and we’re running off the 180cm estimate for that. That gives us 11.88 m² for each blade. Since there’s 8 of them, that brings our total surface to about 95 m².

But surface area is only one of the things to see how much we could lift by the power generated by said windmill: the other two are wind speed and density. For density, we’ll just take the density at 2000m from engineering toolbox, which comes out at 1 kg/m³.

Wind speed is trickier. In the movie, wind speed doesn’t exist at all, so we’ll have to use our own. 5 m/s seems to be fairly reasonable constant speed. 10 m/s feels slightly generous, but given that the island sticks two to three and a half kilometers out of the ocean … we’ll allow it. 15 m/s would already get into risky conditions, probably and is almost ridiculous. We’ll do all of these three.

Fortunately for us, some people have already made online calculators that calculate wind power based on our parameters. We’ll take this one because it has units that we want. Results are out: ~6 kW for 5m/s, 47.5 kW for 10 m/s, ~160 kW for 15 m/s.

Boy these numbers surely rise up fast, don’t they? But while we’re cheering at those very high numbers, Albert Betz is standing in the corner with a baseball bat, ready to beat some harsh reality in our results. Turns out that you can only turn 59% of that wind energy into something else, with modern turbines being only ~40% efficient. Berk isn’t a modern wind turbine, though — it’s more like those Dutch windmills. Internet says ~15% or less for those, so we’ll just operate with 10% just because the Dutch know their shit better than Berk.

That leaves us with … 600W, 4.75 kW and 16 kW.

But that’s just the biggest windmills. What about the second and the third one?

The second windmill (#2) probably doesn’t produce anything even under full load. The blades are parallel to the wind. The third one is just a smaller version of the first. Eyeballs say blades are ~8 m² (6×2), and there’s 6 of them. This gives us a surface area of ~48 m², and power outputs of 360W, 2.9 kW and 9.7 kW.

Combined outputs are 960W, 7.65 kW and 25.7kw.

If we factored losses from pulleys that run the lift, rather than just the losses in the windmill portion of the lift, this amount of power probably couldn’t lift shit.

Speed of the lift

See this speeds?

Not only does the lift move way too fast, the wind isn’t blowing at all, either. Take a look at the trees.

It’s nowhere this fast.

To brush up on high school physics, everything that you lift has a potential energy. The amount of potential energy depends on the mass of the object, how far above the ground it is and the acceleration of the free fall:

U = m*g*h

Free fall acceleration is 9.8 m/s², height is 2-3.35 km (note: ‘2 km’ number came up after the linked post was written, but I haven’t written the third revision quite yet). We’ll be using 2 km and 3.2 km for the calculations.

And now we get to the weight. We’ll assume that the lift has to lift a standard viking warship, about ten warriors and about their weight in cargo. For weight of a viking ship, we’re surely in luck. After all, Draken Harald Hårfagre — a modern reconstruction of a viking ship, constructed using traditional materials and somewhat traditional methods — is a thing that exists. With displacement of 95 tons (presumably empty), it’s pretty heavy.

It’s also 35m long, which the ships in HTTYD aren’t. Eyeballing the lift, those ships appear to be more like 15 meters long. Maybe 20m, but even 15 might be a stretch. We’ll assume uniform scale in all three dimensions. Scaling down to 15 m gives us the weight of about 8 tons. The 10 warriors at the average ideal weight of 75kg and their weight in cargo add up another tonne and a half. We’ll round the ship weight to 10 tons.

And then there are the ropes. Given this is middle ages, they’re probably using hempen ropes. And boy do we have data for that. Breaking strengths, safe load factors, weight per meter. Long story short, it quickly turns out that 2-3 km is too far for a single run of rope as its own weight blows the standard safe load factor in under a kilometer. However, even at three kilometers (and two hundred meters) we don’t blow the minimum breaking strength yet. While transfer stations would be preferred, we’ll just use a single rope and a meager safety factor instead.

Two kilometer run of 2″ rope would weight about three tons. 3200m run of rope would weight about 4.9 tons. Load at the top of the rope would be thus ~29.8 kN and ~48 kN, respectively. Minimum breaking strength is 120 kN. We want to maintain a safety factor of a measly 2, which gives us 60 kN. Rope takes out 29.8-48 kN of our 60 kN capacity, which leaves us with 30-12 kN to work with.

10 tons is 98 kN, which means we need 4-10 (It’s actually 9, but we’ll round up to keep rope counts on both ends of the ship the same).

This gives us another 12-49 tons that we have to lift. However, since weight of the rope changes with how far up the lift is, so does the weight we have to lift. In the end, ropes effectively add only 6-24.5 tons to the mass we have to lift.

Potential energy at the top of the lift comes out to be anywhere between ~315 MJ (2km) to ~1.1 GJ (3.2 km).

Energy is also power over time. If we divide the energy we need to put in with the rate at which we’re putting it in (so, power), we get the amount of time for which we need to keep putting the power in.

So let’s see how the wind speed translates into lift speed.

One lift, windmill #1
Wind speed2 km3.2 km
5 m/s 6 days (14 m/h) 21d 5h (6.3 m/h)
10 m/s 18h 24m (1.8 m/min) 2d 15h (50 m/h)
15 m/s 5h 30m (6 m/min) 19h 15m (2.8 m/min)
One lift, windmill #3
Wind speed2 km3.2 km
5 m/s 10 days (8.3 m/h) 35 days (3.8 m/h)
10 m/s 1d 6h (66.6 m/h) 4d 9h (30 m/h)
15 m/s 9h (3.7 m/min) 1d 7h 30m (1.69 m/min)
One lift, both windmills
Wind speed2 km3.2 km
5 m/s 3d 19h (21 m/h) 13d 6h 30m (10 m/h)
10 m/s 11h 25m (2.9 m/min) 1d 15h 30m (1.35 m/min)
15 m/s 3h 24m (9.8 m/min) 12h (4 m/min)
Both lifts, both windmills
Wind speed2 km3.2 km
5 m/s 7d 14h (11 m/h) 26d 13h (5 m/h)
10 m/s 22h 50m (1.4 m/min) 3d 7h (40 m/h)
15 m/s 6h 24m (5.2 m/min) 1d (2.22 m/min)

If you convert those numbers to actual speed, you’ll quickly notice that this is borderline snails pace. And mind: those are the average speeds. Speeds are going to change depending on the rope length.

Of course, that assumes they don’t use counterweights (and in the movie, it’s clear that they don’t) and that they don’t have transfer stations (cannot be determined from movie). Just by adding counterweights (about as heavy as the ship), you could drastically reduce the time you need for a trip pretty drastically — and by adding transfer stations (hopefully located near a waterfall for free water power) you could also reduce the weight associated with ropes.

But as things are in the movie … well. Better take the stairs.

Why are Snotlout’s lines in ‘How To Train Your Dragon: The Hidden World’ edgy beyond reason?

There’s gotta be an explanation, right? I might just have a theory on that …

Here’s my personal theory.

Back in 2010 when the first How To Train Your Dragon movie was released, smartphones were still fairly new and expensive and not many people had them. Because of that, people who visited movie theaters so they would see quality movies — and coincidentally, the first HTTYD movie is still the best, most carefully crafted movie of the three. But that’s beside my point.

Skip 9 years ahead. Today, it’s 2019. Popularity of smartphones has exploded and the habits of movie-goers have changed accordingly. Theaters are no longer places where people go to see movies. People go to theaters so they can tweet, facebook, snapchat et cetera in peace, undisturbed by their friends, family or significant others. Most movie theaters have changed to better adapt to the changing habits of movie-goers (though there are still some stubborn holdouts that refuse to move on with the times) and started providing free wifi.

But here’s where our problem begins.

Most theaters are in places with shit internet.

Imagine places like Australia, USA and other third world countries where people are poor or the internet infrastructure is so bad. Internet in theaters is often complete and utter shite — and that’s assuming they offer it in the first place. (To make things worse, Australia doesn’t have internet access at all! Well, sorta.)

Dreamworks’ board of directors has recognized that this is indeed a problem, and a problem they need to fix in order to improve the movie-going experience. Some time in the late 2014, they sat down in their board room and asked the fateful question:

“How do we improve people’s tweeting and facebooking and snapchatting experience at the theater?”

They started looking for solutions. When Comcast bought Dreamworks in 2016, they realized that equipping movie theaters with decent routers and internet connections would be borderline impossible and cost too much money. After all, as every American will tell you, Comcast are experts at providing unusable internet service.

For some time, it truly seemed that achieving better tweeting experience for people is a pointless goal. But then, one of the Dreamworks’ execs got a bright idea:

“But what about cellphone signal?”

Initially it seemed like a terrible idea. After all, American cellphone providers (e.g. Verizon, AT&T) are somehow even worse than the broadband providers even before you take into account that cellphone signal isn’t very good at penetrating thick concrete walls of movie theaters.

Completely out of ideas, Dreamworks execs were stumped and all hope seemed lost, so they decided to turn to the experts. Together with Dean DeBlois — the director and scriptwriter of How To Train Your Dragon: The Hidden World — they booked the first flight to Boston in order to consult with MIT on how to provide better cellphone reception in the theaters. During their stay, they learned some basics about mobile technology:

  1. GSM/GPRS was the first standard, but it cannot support a lot of people and is not designed for transferring data, as data transfer speeds cap out at low single digits kilobits per second. This is worse than having no internet connection at all.
  2. 2G, or EDGE, is a bit better, as in: you can actually go on twitter (even if it’s a bit slow)
  3. 3G is nice and fast
  4. 4G/LTE? A pipe dream

With their fresh knowledge of mobile networks, Dreamworks execs and DeBlois returned to LA. Of course, The script of Hidden World was more or less written by that part. Since the script was very much akin to abandoned half-collapsed house in Detroit, he couldn’t change it too much or the entire movie would collapse into complete ruin.

So DeBlois started to experiment with little things. He took a fairly unimportant character and started experimenting with edgy humour in attempt to provide some weak 2G signal. He started with minor tweaks to the twins, and hey: preliminary results showed promise. The movie was edgy enough to emit 3 bars of 2G signal. Curious, he turned to Snotlout and gave him edgy lines. Not only was it edgy, it was so edgy it was 3G. DeBlois started wondering how far he can take this. “Who died and made you chief?” 4G/LTE. Is it possible to go further? Let’s have Snotlout hit on Valka, with pickup lines that were so edgy that they weren’t just 3G or 4G, but provided full 5 bars of 5G signal to everyone within the movie theater, long before the standard was finalized or even thought off. DeBlois wanted to continue, but Dreamworks execs burst into his room and told him to stop. FTC had just called them and told them that improving their tech would result in a massive fine due to violation of rules governing the use of electromagnetic spectrum. Besides, the ending of the movie still hadn’t been finished, and the movie was supposed to come out in just under 4 months.

DeBlois, satisfied enough with his result, decided to call it quits, wrote the final 20 minutes of the movie in a single night and then celebrated by partying hard for the next 6 months.

When the movie was released, most of the movie-goers commended the impeccable tweeting experience they had during the movie. Dreamworks execs were very satisfied with the result — to the tune of a $100% million bonus check they cut DeBlois on top of his contractually agreed pay.

And that’s the story of why Snotlout’s lines in The Hidden World are as edgy as they are.

Bonus content:

This writeup on reddit

The issues with The Hidden World (reddit post)

Hypable: The Failure of the hidden world

Another writeup approaching a different set of issues with HTTYD: The Hidden World

Tamius’ face reveal:

Yes, I’m still salty about how trash that movie is.

How tall is New Berk, really? (Revisited)

My previous island put the settlement of New Berk at about 5 kilometers above the sea. This is obviously ridiculous, so I decided to revisit my calculations …

Not too long ago, I made a reddit post in which I calculated how tall is New Berk in How To Train Your Dragon: The Hidden World. Certain discord server ended up expressing some doubts that I misidentified the location of the lift on the full view of New Berk. While it turns out that I didn’t misidentify the location … let’s be completely fair and honest, 5 kilometers is a ridiculous height estimate. With 4K BluRay in my hands, the time has come to do a second round of calculations.

Seeing the forest for the trees

Another way to eyeball the size of Berk is to take a look at the trees. There’s spruces growing all over the island. Setting-wise, it would be reasonable to expect that these are the European kind of spruces — and these can grow up to 35-55 meters tall. Do spruces on New Berk grow this tall? Quick sanity check says they do:

Note that I didn’t bother correcting calculations for the fact that trees farther away from the camera appear smaller. We’re only doing a quick sanity check

Now that we know that our assumptions aren’t too out of the line, we can start counting pixels. Time to get our hands on some 4K footage for best results. The scene where vikings arrive to the New Berk seems to be a nice candidate for that:

Imagus users can hover over the image for fullview. The rest of you will need to click image to open it in a new tab.

That doesn’t seem to unreasonable, although it may not bode well for our initial “Berk is 5 km above the sea” estimate. Yikes. Let’s find a complete shot of New Berk.

Click image for full view

Well. There’s not much to say, really. While the original estimate was within the same order of magnitude, the 4K screenshots seem to suggest that the height of the new island is between 3,3 and 5,6 km total, with settlement being between 1.7 and 2.8 kilometers above the sea.

But we aren’t done yet.

Autism intensifies

There’s still further confirmations to be had, and chapter title like that certainly doesn’t inspire much confidence in what’s to come.

Let’s try to guess the FoV of this shot.

Can we do it? Turns out yes … but we’re gonna need math. For starters, we need four points on the image that we know real-world coordinates of. Since we know how tall the boathouse is, we can quickly pull four points out of thin air.

Now, I haven’t watched enough Rick&Morty to understand the sort of math needed to calculate the FoV and direction in which the camera is pointing, but someone over at stackoverflow has — and they were nice enough to write their answer in Python — a language that I know a very tiny bit. That answer doesn’t give us everything, though, but let’s not worry. There’s also this math stackexchange post, which pretty much seems to cover the rest.

I know what you’re thinking. That’s a lot of math, and I really want to avoid having to do said math. Especially since I haven’t watched enough Rick&Morty to even figure out how my datapoints translate to solutions described in that post. That, and I’m also lazy.

There must be an easier way, right?

There is. Behind Berk, there’s a lake. Lakes have one very nice property: unless the lake is particularly big, its surface is going to be flat. With that in mind, the New Berk shot was picked very carefully: when moving through the scene frame-by-frame, I found a frame where the lake that surrounds New Berk is aligned with horizon. With horizon known, we only need another point, for which we know the between horizon and the direction in which the camera faces towards said point.

Fortunately for us, that will turn out to be easy. We can trust that support pillars for the lifts (as well as the walkways and terraces around the lifthouse are roughly perpendicular. This means we can easily determine the directions in which the axes of the 3D coordinate system point.

Since support trusses are perpendicular to each other and parallel or perpendicular to the horizontal plane, we can use a few strokes of white to highlight the coordinate system. Note that the “vertical” axis is incorrect, as it should not be completely vertical, but we can approximate and pretend that it is.

And not only we have that: we also have Minecraft.

Welcome to my mine. We are mining diamonds. We are not a strip mine. We don’t have to fight mobs. (Haters go away.)

Turns out that in Minecraft, pressing F3 gets you some nifty developer tools. Among said tools is a reticle that’s shows the direction of the main axes of coordinate system. The tools also tell us which direction we’re facing, with second number telling us the angle relative to the x-z (horizontal) plane.

Through the magic of Linux, we can make GIMP transparent and ensure it’ll always stay on top of any other windows:

That allows us to overlay GIMP over Minecraft. We carefully align the point where all axes cross with the corner of Minecraft’s reticle and wiggle the mouse around until the minecraft cursor covers the lines we drew in GIMP:

Aligning that on a ~160 PPI monitor was pretty tough.

Let’s see whether the reticle truly fully overlaps our lines — it does. We also get to read out the angle that we need:

We have our angle. -7.7° (that’s 18.14° for our American friends).

And now we can finally calculate the FoV of the camera.

This seems to be on the edge between “fine” and “too wide.”

The results are in: the shot seems to have vertical fov of 38.1°and a horizontal FoV just shy of 90°. This feels somewhere between just about right and too wide. Angle isn’t not unreasonably wide, though: assuming this were shot on 35mm film, the lens equivalent for that would be a 18mm lens.

Now that we know the FoV, we can try verifying the island height — and not only that: we can also calculate other dimensions.

Mathrix: reloaded

Back when I was making the initial calculations, I only had a shit (low-bitrate) 1080p version of the movie, so the details weren’t really clear while pixel-licking. Fortunately, though, I now have 4K bluray, which has all the bitrate and all the detail. And on 4K version, we are actually able to make out some impressive detail. What used to be a small blob of pixels is now indeed a viking:

Resemblance is uncanny.

What is more, we can reasonably guess where the floor ends, his legs begin and where his head ends. Your garmin is about to start making noises.

[Click for full view] — The viking strat we used the other day — combined with the FoV we calculated — seems to be giving off familiar results this time around. Keep in mind that “distance to the mountain” doesn’t account for the camera being roughly 145 meters away from the viking by the lifthouse.

Would you look at that. Our optimistic estimates from earlier seem to be roughly confirmed: it’s safe to say that the island is about 3-5 kilometers tall, with Berk being 1.8 to 2.8 kilometers above the sea.

The Final Interpolation

Up until this point, all calculations have been done by estimating the island size based on some assumptions regarding tree sizes. But now that we know the distance between horizon and the bottom floor of the lifthouse, we can actually get a bit more accurate measurement.

Since this shelf is on the horizon line, we know it’s level with the lake

So we know that this bit of rock is level with the lake, and we know that the bottom of the lifthouse is roughly at the top of the rock (maybe sunk a bit deeper thanks to foundations). In theory, this means we should be quickly able to determine the height of that arch, right?

Of course not.

The top line is probably too high as it is. I’ve moved it lower in order to account for vikings standing on it. However, it seems that they removed quite a bit of the top when placing the lifthouse. I haven’t accounted for that.

It’s apparent that the shape of this rock has been at least somewhat changed when building the lift. The top is much flatter with the lift on. However, by eyeballing some things we quickly get how tall the part of the arch located under lake level is: anywhere between 17.5 and 20 meters.

As the last step, we can now pull up the screenshot that shows the Berk in its full flory, from the lift rock to the sea and re-calculate our heights:

[Click for full view] — Turns out you can’t trust trees because they’re all high and shit.

So that’s just over three kilometers for the settlement and six to six and a half for the entire island.

This seems to be the definitive, most accurate answer possible.

Follow-up maths: The Lift and transfer stations

Since the New Berk is just over three kilometers above the sea, there’s one more thing that we need to keep in mind: the ropes have a maximum possible length before they break under their own weight. Let’s see if the lift we see at the end of the movie is even possible.

I will use this as a baseline when calculating my loads. 2″ (48mm) rope would weigh about a kilo and a half per meter, and it’s gonna break when you hit 120 kN (about 12 tons). This means that once the rope is 8 kilometers long, it won’t be able to support itself. But while this number is significantly over the 3.35 kilometer worst case scenario, it includes only the weight of the rope. It doesn’t account for the force of the ship being lifted, additional friction created by the wheels — both on top of the lift, as well as wheels that keep ships on tracks (you can see guiding tracks on the screenshot) — the lateral force that the wind exerts on the rope (as rope gets longer, those forces can get very significant), and any additional stress/force exerted by wheel/rope slipping and then quickly tightening.

If you don’t want to run the risk of rope snapping halfway up, you really want to treat maximum safe load as the maximum weight you can hang from that rope. The site suggests that maximum safe load is 1/12 of the breaking point, so we’ll take that as a gospel. 1/12 out of 120 kN is 10 kN or about 1 ton, which means you’ll need to plant a lift station once every 650-700 meters along the way if you want to lift nothing at all, and 300-500 meters (depending on how much rope can you afford) if you actually want your lift to be useful.

This means we’re probably looking at 8-10 transfer stations along the way. One could argue that, vikings being vikings, they had no OSHA and other pesky safety bureaus and organizations. On the other hand, though, they probably knew their ropes and how much they can carry, and knew their limits. Even if they initially felt a bit more adventurous and cut corners on the transfer stations (having as few as three or two, maybe none) they’d eventually come to the conclusions that transfer stations are not optional and built a proper number of them.

Follow up (2019-07-31): Unofficial official height

So I’ve been thinking about making another round of “how tall is berk” calculations almost ever since this blog post went up, as I figured I could make those eyeball estimates a bit more accurate. Eventually I realised that I really can’t be bothered, though, but there’s one thing I really wanted to address — so I’ve decided to update this post instead.

There is this one redditor who claims to work for Dreamworks, and he claims that he can measure the heights of the island. The redditor was kind enough to give us the height of the lake on the New Berk (43,677 ft) and the height of the “overlook” (we can only assume they meant the rock the lift is placed on; ‘about 44,097 ft’), we get a difference of 420 ft. This gives us about 21 ft per meter. Converting those measurements back to meters using this ratio gives us the height of just shy of 2100m for the lift (and ~2080m for the lake).

That number is to be taken with a huge grain of salt, though, as the redditor claimed that ‘somewhere in the village’ was ‘about 53k feet above the sea.’ 53k ft is 2.5 km above the sea level, which makes these numbers anywhere between ‘sus af’ to ‘load of bullshit’ — judging by the screencaps, no part of the village appears to be over 400 m above the lake. Even 200m seems a bit much by eyeball estimates.

You can give the redditor a benefit of the doubt that he forgot where his initial measurement was taken from, but I’ll be sitting in the corner, smashing that X.

Spreadsheets: the best way of keeping DM notes, ever?

Note to my players: Alz and Xur. If you’re stalking my blog, skip this article because there be spoilers ahead. This works on an honor system.

Keeping track of plans and notes is probably one of the toughest parts of being a DM (right after ‘finding a group to DM’ and, even more challenging, ‘finding a group to play’). For very long time, I’ve relied on LibreOffice Writer to keep up. However, as the length of notes grows and party starts to juggle multiple side quests at the same time, scrolling up and down the document quickly gets annoying. Details quickly become hard to find, there’s page after page after page of unimportant details that you don’t need at this time, but can’t hide away and everything just becomes a mess.

I’ve been handling this limitation reasonably well for the longest time, until eventually came the time for me to dust off my “5d dungeon” thing and throw it at my discord group. But a problem soon appeared: planets are a filler. They have lots of fluff, you get to describe the environment to your players a lot, but at the end of the day there’s not all that much to do while traveling. Players quickly move from planet to planet, and I, as the DM, must scroll back and forth, searching the 60+ page document for descriptions of how planets look and who populates them.

The map of the 5D dungeon, shamelessly stolen from reddit. Keeping notes for this thing is a major mess.

Eventually, there came idea. Wouldn’t it be easier if … I don’t know, I just kept the notes for the planets in the same spreadhseet where I keep the map?

Sure, the idea initially sounds dumb. Text in my Excel? one might ask themselves. Isn’t that for numbers and shit? Aren’t those squares a bit small for text? Can a single cell even contain multiple lines of text? The answer is, of course, yes and no.

The last question is an absolute yes — ctrl+enter will add a new line into the cell (if you’re using online spreadhseet editor, you should take care that you don’t accidentally hit ctrl+r afterwards). As for the rest: the good news is that if the text is too wide to fit within a single cell, it will generally overflow and fill up the neighbouring cells (as long as they’re empty). However, a cell will not overflow up and down.

Notice how the second line of the bottom text is cut off.

In case that spread is unwanted, we can insert content (empty spaces count) to the neighbouring cells. This will hide the overflow:

You can guess in which squares the spaces are

This behaviour is great, because it allows me to hide a lot of text into very tiny area. This makes managing notes easaier: you only enter the most necessary info in the top row of the cell, and hide the fluff below the fold. Everything that’s hidden becomes visible if you double-click the cell for editing.

Since we can style text in every cell much like we can style a word document (except in a slightly more primitive way), this works great in practice. Let me explain on the example of the 5d dungeon map.

Spreadsheets note in action

Three lines above every ‘planet’ currently display only the most basic and necessary info that I need at any time: name of the planet, its size, what kind of environment the planet has, planet description, and quick demographics (with most important races in bold). If I need more info about environment, I can just click the cell that hosts environment info and I’ll get a full description until I click away:

Need to know about demographics? Let’s double-click that:

WoW, so very original. What next, you’ll rip off Guild Wars 2 as well?

All in all, that’s pretty basic stuff, and there certainly are some downsides to using spreadsheeds for what’s not their intended purpose (you have to do manual line breaks) — but damn. I wish I started using spreadsheets for notekeeping sooner. They outright excel at that task.

FAQ: Why not install [insert specialized software here] or use [insert webpage]?
A: because I hate installing too much stuff / because it probably doesn’t run on Linux / because I already have enough tabs and user accounts as it is.