Get Your YouTube Summary:
- Copy the video link.
- Paste it into the input field.
- Click 'Summarize' to get your summary with timestamps.
Important Note on Subtitles:
- Automatic summary generation requires English subtitles on the video.
- If the video has no English subtitles, the automatic download of the transcript using the link will fail.
- Manual Alternative: You can still get a summary!
- Find the transcript on YouTube (usually below the video description when viewed on a desktop browser).
- Copy the entire transcript text manually. (Need help finding/copying? Watch the 'Demo Video' linked at the top right of this page).
- (Optional) Add any additional instructions after the transcript (e.g., 'Translate the summary to German.', 'Add a glossary of medical terms and jargon to the summary.').
For videos longer than 50 minutes:
- Select a Pro model for automatic summarization. Note that Google seems to not allow free use of Pro model anymore.
- If the Pro limit is reached (or if you prefer using your own tool), use the Copy Prompt button, paste the prompt into your AI tool, and run it there.
- 0:00 The "Problem of Points": The video introduces the historical puzzle of how to fairly split a prize in an interrupted game, which unexpectedly led to the foundational concepts of probability theory, driven by the desire for fairness.
- 0:44 Slow Development of Probability: Despite randomness being a long-standing part of human life (gambling, divination), the mathematical theory of probability only emerged in the 16th and 17th centuries, with the "problem of points" being a key catalyst.
- 1:19 Example Game Scenario: A coin-flipping game for a $100 prize, where the first to three points wins, is interrupted. Player 1 has 2 points, Player 2 has 1. The challenge is to fairly divide the prize.
- 2:05 Flawed "Current Leader" Solution: An early, simplistic solution was to give all the money to the person currently leading. This is shown to be highly unfair with a counter-example (e.g., a 1-0 lead in a 1000-point game).
- 2:31 Flawed "Ratio of Current Points" Solution: Another early proposal was to split the prize based on the ratio of current points. This is also demonstrated as unfair with counter-examples (e.g., a 1-0 lead in a long game, or a 999-900 lead where one player needs 1 point and the other 100).
- 3:47 Pascal and Fermat's Breakthrough (1654): Blaise Pascal and Pierre de Fermat independently concluded that the fair solution required looking forward to the future possibilities of the game, rather than backward at past scores.
- 4:15 Introduction of Expected Value: Their combined work led to the concept of "expected value" as the fair method for prize distribution.
- 4:26 Fermat's "Future Games" Approach: Fermat determined the game would end within a certain number of future rounds and calculated all possible outcomes. For the 2-1 scenario, he found Player 1 wins in 3 out of 4 possibilities, thus Player 1 gets $75 and Player 2 gets $25.
- 5:12 Pascal's "Shifting Dollar Bills" Approach: Pascal considered the outcome of the very next round. He argued that if Player 1 wins, they get $100; if Player 2 wins, the game is tied at 2-2, and the prize would be split $50/$50. Therefore, $50 is guaranteed to Player 1, and the remaining $50 (where the risk is equal) is split, leading to $75 for Player 1 and $25 for Player 2.
- 6:21 Impact of Expected Value: The concept of expected value, born from this problem, has profoundly influenced nearly every aspect of modern life.
- 6:50 Modern Definition of Expected Value: Expected value is formally defined as the sum of (probability of each outcome × value of that outcome), functioning as a weighted average where probabilities are the weights.
- 8:13 Connection to Fairness: A game is considered "fair" if its cost equals its expected value. Similarly, in an interrupted game, fairness dictates distributing the prize according to each player's expected winnings.
- 9:04 Combinatorial Calculations: For more complex games (e.g., Player 1 needs 5 points, Player 2 needs 8), calculating winning probabilities requires combinatorics, often using Pascal's triangle to count the number of ways a player can achieve a certain score in a given number of rounds.
- 12:03 The Gambler's Ruin Problem: The video briefly mentions a related, more complex problem called "gambler's ruin," which involves players with unequal odds of winning each round, impacting their long-term probability of winning or losing everything.
-
Introduction: The Core Challenge The project aims to create a spherical, fully destructible voxel planet. The primary challenge is mapping a cubic grid to a sphere without creating severe visual distortion or breaking gameplay mechanics like building and walking, as standard grid alignment conflicts with a central gravity point.
-
Let’s Get Spherical: Surface Mapping
- Problem: Mapping a flat grid to a sphere inevitably causes distortion. A simple projection creates extreme stretching at the poles.
- Solution: The project uses a quad sphere, which maps six square faces of a cube onto the sphere. This greatly reduces distortion compared to a single rectangular map.
- Refinement: To further improve visual quality, a pre-distortion is applied to the square grid to counteract the distortion introduced during the spherical projection, resulting in blocks that look much more like squares, even at the seams between sectors.
-
Digging Deep: Handling Vertical Distortion
- Problem: On a sphere, layers have a smaller area closer to the center. Stacking identical layers results in stretched blocks near the surface and compressed blocks near the core.
- Solution: The world is divided into concentric shells. As a player moves outward into a new shell, the number of blocks per layer quadruples. This keeps the blocks' size relatively consistent.
- Trade-off: This creates perfect block alignment within a shell but results in seams at shell boundaries, where one larger block from an inner shell maps to four smaller blocks in the next shell out.
-
Planet Structure: Data Organization
- The planet is organized hierarchically for efficient data management. The structure is: Planet → 6 Sectors → Shells → Chunks (16x16x16) → Blocks.
- Each block has a unique
BlockAddressthat specifies its exact location within this structure.
-
Who’s my Neighbor?: The Biggest Hurdle
- Finding a block's neighbor is the most complex operation, especially across boundaries.
- Vertical Shell Boundaries: A block at the top of an inner shell has four neighbors "above" it in the next shell, complicating adjacency calculations.
- Sector Boundaries: The local coordinate systems of adjacent sectors are often misaligned (axes are swapped or flipped). This requires specific mapping logic for each of the 12 edge pairings on the quad sphere's cube net.
-
Miscellaneous Functionality: Gameplay Mechanics
- Player Gravity: A custom gravity system pulls the player towards the planet's center. Gravity decreases to zero at the core, and a "thruster" allows for flight and orbital mechanics.
- Terrain Generation: The system uses 3D noise sampled on a sphere, which naturally avoids the seams and distortion that would occur when mapping 2D noise. Biomes (arctic and forest) are determined by angular distance from the poles.
- Block Structures: Placing pre-built structures is achieved by navigating from an origin block using relative directions. This allows structures to be placed even across the "wonky" corner and shell boundary areas, though some distortion may occur.
-
Future Work The author plans to potentially add features like multiple planets and moons (an Outer Wilds-style system), chunk-based dynamic gravity, cave generation, and more realistic biomes.
- General Reception: The project and its detailed write-up were met with widespread praise for tackling a difficult problem with elegant solutions and for the clarity of the explanation.
- Game Comparisons: Many users compared the concept to other games with non-Euclidean or planetary physics, including Super Mario Galaxy (small planetoids), Space Engineers (spherical voxels), Outer Wilds (solar system exploration), and PlanetSmith (hexagonal voxels).
- Gravity Physics: Several comments discussed the realism of the gravity model, noting that according to the Shell Theorem, gravity should indeed fall to zero at the center of a spherically symmetric body. The weird gravity in games like Astroneer was also mentioned.
- The Quad Sphere: The choice of a quad sphere was highlighted as a critical and intelligent design decision to avoid the extreme distortion and singularity issues found at the poles of traditional latitude-longitude map projections.
- Alternative Geometries: Commenters proposed alternative approaches, such as using a geodesic sphere (based on triangles) for more uniform distortion or a torus, which would eliminate polar issues entirely but introduce its own topological challenges.
- Player Experience: Users who tried the demo reported enjoying the gameplay, particularly the ability to achieve a stable orbit around the planet using the thruster.
- 0:03 The Core Problem in AI Animation: Existing AI animation techniques suffer from a critical trade-off: methods that are controllable often produce physically unrealistic motion, while realistic methods are difficult to control.
- 0:34 AI's Potential and Current Limitations: While AI can learn to weave motion-captured animations together, current controllable techniques frequently fail to create physically viable motion, and realistic ones lack easy control.
- 1:02 Introducing "Diffuse Clock": A new AI animation method is presented, dubbed "diffuse clock," which promises to deliver both controllable and realistic character motion from a dataset of movements.
- 1:22 Key Feature 1: Static Obstacle Avoidance: The technique allows animated characters to naturally avoid static obstacles like walls.
- 1:28 Key Feature 2: Dynamic Obstacle Avoidance: Characters can also avoid collisions with other moving AI entities in dynamic environments.
- 1:42 Key Feature 3: Long Animation Sequences: The method is effective for generating extended and complex animation sequences.
- 1:46 Key Feature 4: Powerful Generalization: A significant capability is the AI's ability to generalize, performing actions in new situations it hasn't explicitly seen (e.g., jumping multiple pillars after only being trained on ground jumps).
- 2:12 Key Feature 5: Multi-Pose Specification: Unlike most other diffusion-based AI techniques, diffuse clock can generate motion between two or more user-specified poses.
- 2:23 Key Feature 6: Perturbation Resistance: The characters generated by diffuse clock are notably resistant to physical disruptions, maintaining their intended movement even when interfered with.
- 3:00 The Magic Behind Diffuse Clock: The AI learns by anticipating future movements, akin to a dancer feeling the rhythm ahead, allowing it to improvise gracefully and seamlessly weave states and actions together.
- 3:56 Efficient Training: The model can be trained on a single GPU in just 24 hours, making it highly accessible and practical.
- 4:06 Zero-Shot Learning: A major takeaway is that the model uses "zero-shot" learning, meaning it requires no retraining or task-specific tuning for new environments or challenges.
- 4:21 Diverse Applications: The technique holds immense potential for creating naturally moving game characters, realistic VR avatars, and even for controlling robots.
identifier:6443
model:gemini-2.5-flash| input-price: 0.3 output-price: 2.5 max-context-length: 128_000
host:193.8.40.126
https://www.youtube.com/watch?v=T_p3pJEGf84&pp=wgIGCgQQAhgB0gcJCRIBmk6bhtouinclude_comments:None
include_timestamps:1
include_glossary:None
output_language:en
cost:0.007309100000000001
*Abstract:* This video traces the origins of probability theory through the "problem of points," a historical challenge concerning the fair distribution of prize money in an interrupted game. It highlights how mathematicians Blaise Pascal and Pierre de Fermat independently devised the concept of "expected value" as the equitable solution. The video critiques earlier, less fair methods of prize division before detailing Pascal and Fermat's forward-looking approaches: Fermat's analysis of all possible future game scenarios and Pascal's incremental distribution based on the next move. The concept is then expanded to its modern definition as a weighted average, emphasizing its pervasive influence on contemporary decision-making and its connection to combinatorial mathematics through Pascal's triangle. *The Problem of Points: How Fairness Led to Probability Theory* * *0:00 The "Problem of Points":* The video introduces the historical puzzle of how to fairly split a prize in an interrupted game, which unexpectedly led to the foundational concepts of probability theory, driven by the desire for fairness. * *0:44 Slow Development of Probability:* Despite randomness being a long-standing part of human life (gambling, divination), the mathematical theory of probability only emerged in the 16th and 17th centuries, with the "problem of points" being a key catalyst. * *1:19 Example Game Scenario:* A coin-flipping game for a $100 prize, where the first to three points wins, is interrupted. Player 1 has 2 points, Player 2 has 1. The challenge is to fairly divide the prize. * *2:05 Flawed "Current Leader" Solution:* An early, simplistic solution was to give all the money to the person currently leading. This is shown to be highly unfair with a counter-example (e.g., a 1-0 lead in a 1000-point game). * *2:31 Flawed "Ratio of Current Points" Solution:* Another early proposal was to split the prize based on the ratio of current points. This is also demonstrated as unfair with counter-examples (e.g., a 1-0 lead in a long game, or a 999-900 lead where one player needs 1 point and the other 100). * *3:47 Pascal and Fermat's Breakthrough (1654):* Blaise Pascal and Pierre de Fermat independently concluded that the fair solution required looking *forward* to the future possibilities of the game, rather than *backward* at past scores. * *4:15 Introduction of Expected Value:* Their combined work led to the concept of "expected value" as the fair method for prize distribution. * *4:26 Fermat's "Future Games" Approach:* Fermat determined the game would end within a certain number of future rounds and calculated all possible outcomes. For the 2-1 scenario, he found Player 1 wins in 3 out of 4 possibilities, thus Player 1 gets $75 and Player 2 gets $25. * *5:12 Pascal's "Shifting Dollar Bills" Approach:* Pascal considered the outcome of the very next round. He argued that if Player 1 wins, they get $100; if Player 2 wins, the game is tied at 2-2, and the prize would be split $50/$50. Therefore, $50 is guaranteed to Player 1, and the remaining $50 (where the risk is equal) is split, leading to $75 for Player 1 and $25 for Player 2. * *6:21 Impact of Expected Value:* The concept of expected value, born from this problem, has profoundly influenced nearly every aspect of modern life. * *6:50 Modern Definition of Expected Value:* Expected value is formally defined as the sum of (probability of each outcome × value of that outcome), functioning as a weighted average where probabilities are the weights. * *8:13 Connection to Fairness:* A game is considered "fair" if its cost equals its expected value. Similarly, in an interrupted game, fairness dictates distributing the prize according to each player's expected winnings. * *9:04 Combinatorial Calculations:* For more complex games (e.g., Player 1 needs 5 points, Player 2 needs 8), calculating winning probabilities requires combinatorics, often using Pascal's triangle to count the number of ways a player can achieve a certain score in a given number of rounds. * *12:03 The Gambler's Ruin Problem:* The video briefly mentions a related, more complex problem called "gambler's ruin," which involves players with unequal odds of winning each round, impacting their long-term probability of winning or losing everything. I used gemini-2.5-flash| input-price: 0.3 output-price: 2.5 max-context-length: 128_000 on rocketrecap dot com to summarize the transcript. Cost (if I didn't use the free tier): $0.0073 Input tokens: 15872 Output tokens: 1019
Abstract:
This video traces the origins of probability theory through the "problem of points," a historical challenge concerning the fair distribution of prize money in an interrupted game. It highlights how mathematicians Blaise Pascal and Pierre de Fermat independently devised the concept of "expected value" as the equitable solution. The video critiques earlier, less fair methods of prize division before detailing Pascal and Fermat's forward-looking approaches: Fermat's analysis of all possible future game scenarios and Pascal's incremental distribution based on the next move. The concept is then expanded to its modern definition as a weighted average, emphasizing its pervasive influence on contemporary decision-making and its connection to combinatorial mathematics through Pascal's triangle.
The Problem of Points: How Fairness Led to Probability Theory
Below, I will provide input for an example video (comprising of title, description, and transcript, in this order) and the corresponding abstract and summary I expect. Afterward, I will provide a new transcript that I want you to summarize in the same format.
**Please give an abstract of the transcript and then summarize the transcript in a self-contained bullet list format.** Include starting timestamps, important details and key takeaways.
Example Input:
Fluidigm Polaris Part 2- illuminator and camera
mikeselectricstuff
131K subscribers
Subscribed
369
Share
Download
Clip
Save
5,857 views Aug 26, 2024
Fluidigm Polaris part 1 : • Fluidigm Polaris (Part 1) - Biotech g...
Ebay listings: https://www.ebay.co.uk/usr/mikeselect...
Merch https://mikeselectricstuff.creator-sp...
Transcript
Follow along using the transcript.
Show transcript
mikeselectricstuff
131K subscribers
Videos
About
Support on Patreon
40 Comments
@robertwatsonbath
6 hours ago
Thanks Mike. Ooof! - with the level of bodgery going on around 15:48 I think shame would have made me do a board re spin, out of my own pocket if I had to.
1
Reply
@Muonium1
9 hours ago
The green LED looks different from the others and uses phosphor conversion because of the "green gap" problem where green InGaN emitters suffer efficiency droop at high currents. Phosphide based emitters don't start becoming efficient until around 600nm so also can't be used for high power green emitters. See the paper and plot by Matthias Auf der Maur in his 2015 paper on alloy fluctuations in InGaN as the cause of reduced external quantum efficiency at longer (green) wavelengths.
4
Reply
1 reply
@tafsirnahian669
10 hours ago (edited)
Can this be used as an astrophotography camera?
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
6 hours ago
Yes, but may need a shutter to avoid light during readout
Reply
@2010craggy
11 hours ago
Narrowband filters we use in Astronomy (Astrophotography) are sided- they work best passing light in one direction so I guess the arrows on the filter frames indicate which way round to install them in the filter wheel.
1
Reply
@vitukz
12 hours ago
A mate with Channel @extractions&ire could use it
2
Reply
@RobertGallop
19 hours ago
That LED module says it can go up to 28 amps!!! 21 amps for 100%. You should see what it does at 20 amps!
Reply
@Prophes0r
19 hours ago
I had an "Oh SHIT!" moment when I realized that the weird trapezoidal shape of that light guide was for keystone correction of the light source.
Very clever.
6
Reply
@OneBiOzZ
20 hours ago
given the cost of the CCD you think they could have run another PCB for it
9
Reply
@tekvax01
21 hours ago
$20 thousand dollars per minute of run time!
1
Reply
@tekvax01
22 hours ago
"We spared no expense!" John Hammond Jurassic Park.
*(that's why this thing costs the same as a 50-seat Greyhound Bus coach!)
Reply
@florianf4257
22 hours ago
The smearing on the image could be due to the fact that you don't use a shutter, so you see brighter stripes under bright areas of the image as you still iluminate these pixels while the sensor data ist shifted out towards the top. I experienced this effect back at university with a LN-Cooled CCD for Spectroscopy. The stripes disapeared as soon as you used the shutter instead of disabling it in the open position (but fokussing at 100ms integration time and continuous readout with a focal plane shutter isn't much fun).
12
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
12 hours ago
I didn't think of that, but makes sense
2
Reply
@douro20
22 hours ago (edited)
The red LED reminds me of one from Roithner Lasertechnik. I have a Symbol 2D scanner which uses two very bright LEDs from that company, one red and one red-orange. The red-orange is behind a lens which focuses it into an extremely narrow beam.
1
Reply
@RicoElectrico
23 hours ago
PFG is Pulse Flush Gate according to the datasheet.
Reply
@dcallan812
23 hours ago
Very interesting. 2x
Reply
@littleboot_
1 day ago
Cool interesting device
Reply
@dav1dbone
1 day ago
I've stripped large projectors, looks similar, wonder if some of those castings are a magnesium alloy?
Reply
@kevywevvy8833
1 day ago
ironic that some of those Phlatlight modules are used in some of the cheapest disco lights.
1
Reply
1 reply
@bill6255
1 day ago
Great vid - gets right into subject in title, its packed with information, wraps up quickly. Should get a YT award! imho
3
Reply
@JAKOB1977
1 day ago (edited)
The whole sensor module incl. a 5 grand 50mpix sensor for 49 £.. highest bid atm
Though also a limited CCD sensor, but for the right buyer its a steal at these relative low sums.
Architecture Full Frame CCD (Square Pixels)
Total Number of Pixels 8304 (H) × 6220 (V) = 51.6 Mp
Number of Effective Pixels 8208 (H) × 6164 (V) = 50.5 Mp
Number of Active Pixels 8176 (H) × 6132 (V) = 50.1 Mp
Pixel Size 6.0 m (H) × 6.0 m (V)
Active Image Size 49.1 mm (H) × 36.8 mm (V)
61.3 mm (Diagonal),
645 1.1x Optical Format
Aspect Ratio 4:3
Horizontal Outputs 4
Saturation Signal 40.3 ke−
Output Sensitivity 31 V/e−
Quantum Efficiency
KAF−50100−CAA
KAF−50100−AAA
KAF−50100−ABA (with Lens)
22%, 22%, 16% (Peak R, G, B)
25%
62%
Read Noise (f = 18 MHz) 12.5 e−
Dark Signal (T = 60°C) 42 pA/cm2
Dark Current Doubling Temperature 5.7°C
Dynamic Range (f = 18 MHz) 70.2 dB
Estimated Linear Dynamic Range
(f = 18 MHz)
69.3 dB
Charge Transfer Efficiency
Horizontal
Vertical
0.999995
0.999999
Blooming Protection
(4 ms Exposure Time)
800X Saturation Exposure
Maximum Date Rate 18 MHz
Package Ceramic PGA
Cover Glass MAR Coated, 2 Sides or
Clear Glass
Features
• TRUESENSE Transparent Gate Electrode
for High Sensitivity
• Ultra-High Resolution
• Board Dynamic Range
• Low Noise Architecture
• Large Active Imaging Area
Applications
• Digitization
• Mapping/Aerial
• Photography
• Scientific
Thx for the tear down Mike, always a joy
Reply
@martinalooksatthings
1 day ago
15:49 that is some great bodging on of caps, they really didn't want to respin that PCB huh
8
Reply
@RhythmGamer
1 day ago
Was depressed today and then a new mike video dropped and now I’m genuinely happy to get my tear down fix
1
Reply
@dine9093
1 day ago (edited)
Did you transfrom into Mr Blobby for a moment there?
2
Reply
@NickNorton
1 day ago
Thanks Mike. Your videos are always interesting.
5
Reply
@KeritechElectronics
1 day ago
Heavy optics indeed... Spare no expense, cost no object. Splendid build quality. The CCD is a thing of beauty!
1
Reply
@YSoreil
1 day ago
The pricing on that sensor is about right, I looked in to these many years ago when they were still in production since it's the only large sensor you could actually buy. Really cool to see one in the wild.
2
Reply
@snik2pl
1 day ago
That leds look like from led projector
Reply
@vincei4252
1 day ago
TDI = Time Domain Integration ?
1
Reply
@wolpumba4099
1 day ago (edited)
Maybe the camera should not be illuminated during readout.
From the datasheet of the sensor (Onsemi): saturation 40300 electrons, read noise 12.5 electrons per pixel @ 18MHz (quite bad). quantum efficiency 62% (if it has micro lenses), frame rate 1 Hz. lateral overflow drain to prevent blooming protects against 800x (factor increases linearly with exposure time) saturation exposure (32e6 electrons per pixel at 4ms exposure time), microlens has +/- 20 degree acceptance angle
i guess it would be good for astrophotography
4
Reply
@txm100
1 day ago (edited)
Babe wake up a new mikeselectricstuff has dropped!
9
Reply
@vincei4252
1 day ago
That looks like a finger-lakes filter wheel, however, for astronomy they'd never use such a large stepper.
1
Reply
@MRooodddvvv
1 day ago
yaaaaay ! more overcomplicated optical stuff !
4
Reply
1 reply
@NoPegs
1 day ago
He lives!
11
Reply
1 reply
Transcript
0:00
so I've stripped all the bits of the
0:01
optical system so basically we've got
0:03
the uh the camera
0:05
itself which is mounted on this uh very
0:09
complex
0:10
adjustment thing which obviously to set
0:13
you the various tilt and uh alignment
0:15
stuff then there's two of these massive
0:18
lenses I've taken one of these apart I
0:20
think there's something like about eight
0:22
or nine Optical elements in here these
0:25
don't seem to do a great deal in terms
0:26
of electr magnification they're obiously
0:28
just about getting the image to where it
0:29
uh where it needs to be just so that
0:33
goes like that then this Optical block I
0:36
originally thought this was made of some
0:37
s crazy heavy material but it's just
0:39
really the sum of all these Optical bits
0:41
are just ridiculously heavy those lenses
0:43
are about 4 kilos each and then there's
0:45
this very heavy very solid um piece that
0:47
goes in the middle and this is so this
0:49
is the filter wheel assembly with a
0:51
hilariously oversized steper
0:53
motor driving this wheel with these very
0:57
large narrow band filters so we've got
1:00
various different shades of uh
1:03
filters there five Al together that
1:06
one's actually just showing up a silver
1:07
that's actually a a red but fairly low
1:10
transmission orangey red blue green
1:15
there's an excess cover on this side so
1:16
the filters can be accessed and changed
1:19
without taking anything else apart even
1:21
this is like ridiculous it's like solid
1:23
aluminium this is just basically a cover
1:25
the actual wavelengths of these are um
1:27
488 525 570 630 and 700 NM not sure what
1:32
the suffix on that perhaps that's the uh
1:34
the width of the spectral line say these
1:37
are very narrow band filters most of
1:39
them are you very little light through
1:41
so it's still very tight narrow band to
1:43
match the um fluoresence of the dies
1:45
they're using in the biochemical process
1:48
and obviously to reject the light that's
1:49
being fired at it from that Illuminator
1:51
box and then there's a there's a second
1:53
one of these lenses then the actual sort
1:55
of samples below that so uh very serious
1:58
amount of very uh chunky heavy Optics
2:01
okay let's take a look at this light
2:02
source made by company Lumen Dynamics
2:04
who are now part of
2:06
excelitas self-contained unit power
2:08
connector USB and this which one of the
2:11
Cable Bundle said was a TTL interface
2:14
USB wasn't used in uh the fluid
2:17
application output here and I think this
2:19
is an input for um light feedback I
2:21
don't if it's regulated or just a measur
2:23
measurement facility and the uh fiber
2:27
assembly
2:29
Square Inlet there and then there's two
2:32
outputs which have uh lens assemblies
2:35
and this small one which goes back into
2:37
that small Port just Loops out of here
2:40
straight back in So on this side we've
2:42
got the electronics which look pretty
2:44
straightforward we've got a bit of power
2:45
supply stuff over here and we've got
2:48
separate drivers for each wavelength now
2:50
interesting this is clearly been very
2:52
specifically made for this application
2:54
you I was half expecting like say some
2:56
generic drivers that could be used for a
2:58
number of different things but actually
3:00
literally specified the exact wavelength
3:02
on the PCB there is provision here for
3:04
385 NM which isn't populated but this is
3:07
clearly been designed very specifically
3:09
so these four drivers look the same but
3:10
then there's two higher power ones for
3:12
575 and
3:14
520 a slightly bigger heat sink on this
3:16
575 section there a p 24 which is
3:20
providing USB interface USB isolator the
3:23
USB interface just presents as a comport
3:26
I did have a quick look but I didn't
3:27
actually get anything sensible um I did
3:29
dump the Pi code out and there's a few
3:31
you a few sort of commands that you
3:32
could see in text but I didn't actually
3:34
manage to get it working properly I
3:36
found some software for related version
3:38
but it didn't seem to want to talk to it
3:39
but um I say that wasn't used for the
3:41
original application it might be quite
3:42
interesting to get try and get the Run
3:44
hours count out of it and the TTL
3:46
interface looks fairly straightforward
3:48
we've got positions for six opto
3:50
isolators but only five five are
3:52
installed so that corresponds with the
3:54
unused thing so I think this hopefully
3:56
should be as simple as just providing a
3:57
ttrl signal for each color to uh enable
4:00
it a big heat sink here which is there I
4:03
think there's like a big S of metal
4:04
plate through the middle of this that
4:05
all the leads are mounted on the other
4:07
side so this is heat sinking it with a
4:09
air flow from a uh just a fan in here
4:13
obviously don't have the air flow
4:14
anywhere near the Optics so conduction
4:17
cool through to this plate that's then
4:18
uh air cooled got some pots which are
4:21
presumably power
4:22
adjustments okay let's take a look at
4:24
the other side which is uh much more
4:27
interesting see we've got some uh very
4:31
uh neatly Twisted cable assemblies there
4:35
a bunch of leads so we've got one here
4:37
475 up here 430 NM 630 575 and 520
4:44
filters and dcro mirrors a quick way to
4:48
see what's white is if we just shine
4:49
some white light through
4:51
here not sure how it is is to see on the
4:54
camera but shining white light we do
4:55
actually get a bit of red a bit of blue
4:57
some yellow here so the obstacle path
5:00
575 it goes sort of here bounces off
5:03
this mirror and goes out the 520 goes
5:07
sort of down here across here and up
5:09
there 630 goes basically straight
5:13
through
5:15
430 goes across there down there along
5:17
there and the 475 goes down here and
5:20
left this is the light sensing thing
5:22
think here there's just a um I think
5:24
there a photo diode or other sensor
5:26
haven't actually taken that off and
5:28
everything's fixed down to this chunk of
5:31
aluminium which acts as the heat
5:32
spreader that then conducts the heat to
5:33
the back side for the heat
5:35
sink and the actual lead packages all
5:38
look fairly similar except for this one
5:41
on the 575 which looks quite a bit more
5:44
substantial big spay
5:46
Terminals and the interface for this
5:48
turned out to be extremely simple it's
5:50
literally a 5V TTL level to enable each
5:54
color doesn't seem to be any tensity
5:56
control but there are some additional
5:58
pins on that connector that weren't used
5:59
in the through time thing so maybe
6:01
there's some extra lines that control
6:02
that I couldn't find any data on this uh
6:05
unit and the um their current product
6:07
range is quite significantly different
6:09
so we've got the uh blue these
6:13
might may well be saturating the camera
6:16
so they might look a bit weird so that's
6:17
the 430
6:18
blue the 575
6:24
yellow uh
6:26
475 light blue
6:29
the uh 520
6:31
green and the uh 630 red now one
6:36
interesting thing I noticed for the
6:39
575 it's actually it's actually using a
6:42
white lead and then filtering it rather
6:44
than using all the other ones are using
6:46
leads which are the fundamental colors
6:47
but uh this is actually doing white and
6:50
it's a combination of this filter and
6:52
the dichroic mirrors that are turning to
6:55
Yellow if we take the filter out and a
6:57
lot of the a lot of the um blue content
7:00
is going this way the red is going
7:02
straight through these two mirrors so
7:05
this is clearly not reflecting much of
7:08
that so we end up with the yellow coming
7:10
out of uh out of there which is a fairly
7:14
light yellow color which you don't
7:16
really see from high intensity leads so
7:19
that's clearly why they've used the
7:20
white to uh do this power consumption of
7:23
the white is pretty high so going up to
7:25
about 2 and 1 half amps on that color
7:27
whereas most of the other colors are
7:28
only drawing half an amp or so at 24
7:30
volts the uh the green is up to about
7:32
1.2 but say this thing is uh much
7:35
brighter and if you actually run all the
7:38
colors at the same time you get a fairly
7:41
reasonable um looking white coming out
7:43
of it and one thing you might just be
7:45
out to notice is there is some sort
7:46
color banding around here that's not
7:49
getting uh everything s completely
7:51
concentric and I think that's where this
7:53
fiber optic thing comes
7:58
in I'll
8:00
get a couple of Fairly accurately shaped
8:04
very sort of uniform color and looking
8:06
at What's um inside here we've basically
8:09
just got this Square Rod so this is
8:12
clearly yeah the lights just bouncing
8:13
off all the all the various sides to um
8:16
get a nice uniform illumination uh this
8:19
back bit looks like it's all potted so
8:21
nothing I really do to get in there I
8:24
think this is fiber so I have come
8:26
across um cables like this which are
8:27
liquid fill but just looking through the
8:30
end of this it's probably a bit hard to
8:31
see it does look like there fiber ends
8:34
going going on there and so there's this
8:36
feedback thing which is just obviously
8:39
compensating for the any light losses
8:41
through here to get an accurate
8:43
representation of uh the light that's
8:45
been launched out of these two
8:47
fibers and you see uh
8:49
these have got this sort of trapezium
8:54
shape light guides again it's like a
8:56
sort of acrylic or glass light guide
9:00
guess projected just to make the right
9:03
rectangular
9:04
shape and look at this Center assembly
9:07
um the light output doesn't uh change
9:10
whether you feed this in or not so it's
9:11
clear not doing any internal Clos Loop
9:14
control obviously there may well be some
9:16
facility for it to do that but it's not
9:17
being used in this
9:19
application and so this output just
9:21
produces a voltage on the uh outle
9:24
connector proportional to the amount of
9:26
light that's present so there's a little
9:28
diffuser in the back there
9:30
and then there's just some kind of uh
9:33
Optical sensor looks like a
9:35
chip looking at the lead it's a very
9:37
small package on the PCB with this lens
9:40
assembly over the top and these look
9:43
like they're actually on a copper
9:44
Metalized PCB for maximum thermal
9:47
performance and yeah it's a very small
9:49
package looks like it's a ceramic
9:51
package and there's a thermister there
9:53
for temperature monitoring this is the
9:56
475 blue one this is the 520 need to
9:59
Green which is uh rather different OB
10:02
it's a much bigger D with lots of bond
10:04
wise but also this looks like it's using
10:05
a phosphor if I shine a blue light at it
10:08
lights up green so this is actually a
10:10
phosphor conversion green lead which
10:12
I've I've come across before they want
10:15
that specific wavelength so they may be
10:17
easier to tune a phosphor than tune the
10:20
um semiconductor material to get the uh
10:23
right right wavelength from the lead
10:24
directly uh red 630 similar size to the
10:28
blue one or does seem to have a uh a
10:31
lens on top of it there is a sort of red
10:33
coloring to
10:35
the die but that doesn't appear to be
10:38
fluorescent as far as I can
10:39
tell and the white one again a little
10:41
bit different sort of much higher
10:43
current
10:46
connectors a makeer name on that
10:48
connector flot light not sure if that's
10:52
the connector or the lead
10:54
itself and obviously with the phosphor
10:56
and I'd imagine that phosphor may well
10:58
be tuned to get the maximum to the uh 5
11:01
cenm and actually this white one looks
11:04
like a St fairly standard product I just
11:06
found it in Mouse made by luminous
11:09
devices in fact actually I think all
11:11
these are based on various luminous
11:13
devices modules and they're you take
11:17
looks like they taking the nearest
11:18
wavelength and then just using these
11:19
filters to clean it up to get a precise
11:22
uh spectral line out of it so quite a
11:25
nice neat and um extreme
11:30
bright light source uh sure I've got any
11:33
particular use for it so I think this
11:35
might end up on
11:36
eBay but uh very pretty to look out and
11:40
without the uh risk of burning your eyes
11:43
out like you do with lasers so I thought
11:45
it would be interesting to try and
11:46
figure out the runtime of this things
11:48
like this we usually keep some sort
11:49
record of runtime cuz leads degrade over
11:51
time I couldn't get any software to work
11:52
through the USB face but then had a
11:54
thought probably going to be writing the
11:55
runtime periodically to the e s prom so
11:58
I just just scope up that and noticed it
12:00
was doing right every 5 minutes so I
12:02
just ran it for a while periodically
12:04
reading the E squ I just held the pick
12:05
in in reset and um put clip over to read
12:07
the square prom and found it was writing
12:10
one location per color every 5 minutes
12:12
so if one color was on it would write
12:14
that location every 5 minutes and just
12:16
increment it by one so after doing a few
12:18
tests with different colors of different
12:19
time periods it looked extremely
12:21
straightforward it's like a four bite
12:22
count for each color looking at the
12:24
original data that was in it all the
12:26
colors apart from Green were reading
12:28
zero and the green was reading four
12:30
indicating a total 20 minutes run time
12:32
ever if it was turned on run for a short
12:34
time then turned off that might not have
12:36
been counted but even so indicates this
12:37
thing wasn't used a great deal the whole
12:40
s process of doing a run can be several
12:42
hours but it'll only be doing probably
12:43
the Imaging at the end of that so you
12:46
wouldn't expect to be running for a long
12:47
time but say a single color for 20
12:50
minutes over its whole lifetime does
12:52
seem a little bit on the low side okay
12:55
let's look at the camera un fortunately
12:57
I managed to not record any sound when I
12:58
did this it's also a couple of months
13:00
ago so there's going to be a few details
13:02
that I've forgotten so I'm just going to
13:04
dub this over the original footage so um
13:07
take the lid off see this massive great
13:10
heat sink so this is a pel cool camera
13:12
we've got this blower fan producing a
13:14
fair amount of air flow through
13:16
it the connector here there's the ccds
13:19
mounted on the board on the
13:24
right this unplugs so we've got a bit of
13:27
power supply stuff on here
13:29
USB interface I think that's the Cyprus
13:32
microcontroller High speeded USB
13:34
interface there's a zyink spon fpga some
13:40
RAM and there's a couple of ATD
13:42
converters can't quite read what those
13:45
those are but anal
13:47
devices um little bit of bodgery around
13:51
here extra decoupling obviously they
13:53
have having some noise issues this is
13:55
around the ram chip quite a lot of extra
13:57
capacitors been added there
13:59
uh there's a couple of amplifiers prior
14:01
to the HD converter buffers or Andor
14:05
amplifiers taking the CCD
14:08
signal um bit more power spy stuff here
14:11
this is probably all to do with
14:12
generating the various CCD bias voltages
14:14
they uh need quite a lot of exotic
14:18
voltages next board down is just a
14:20
shield and an interconnect
14:24
boardly shielding the power supply stuff
14:26
from some the more sensitive an log
14:28
stuff
14:31
and this is the bottom board which is
14:32
just all power supply
14:34
stuff as you can see tons of capacitors
14:37
or Transformer in
14:42
there and this is the CCD which is a uh
14:47
very impressive thing this is a kf50 100
14:50
originally by true sense then codec
14:53
there ON
14:54
Semiconductor it's 50 megapixels uh the
14:58
only price I could find was this one
15:00
5,000 bucks and the architecture you can
15:03
see there actually two separate halves
15:04
which explains the Dual AZ converters
15:06
and two amplifiers it's literally split
15:08
down the middle and duplicated so it's
15:10
outputting two streams in parallel just
15:13
to keep the bandwidth sensible and it's
15:15
got this amazing um diffraction effects
15:18
it's got micro lenses over the pixel so
15:20
there's there's a bit more Optics going
15:22
on than on a normal
15:25
sensor few more bodges on the CCD board
15:28
including this wire which isn't really
15:29
tacked down very well which is a bit uh
15:32
bit of a mess quite a few bits around
15:34
this board where they've uh tacked
15:36
various bits on which is not super
15:38
impressive looks like CCD drivers on the
15:40
left with those 3 ohm um damping
15:43
resistors on the
15:47
output get a few more little bodges
15:50
around here some of
15:52
the and there's this separator the
15:54
silica gel to keep the moisture down but
15:56
there's this separator that actually
15:58
appears to be cut from piece of
15:59
antistatic
16:04
bag and this sort of thermal block on
16:06
top of this stack of three pel Cola
16:12
modules so as with any Stacks they get
16:16
um larger as they go back towards the
16:18
heat sink because each P's got to not
16:20
only take the heat from the previous but
16:21
also the waste heat which is quite
16:27
significant you see a little temperature
16:29
sensor here that copper block which
16:32
makes contact with the back of the
16:37
CCD and this's the back of the
16:40
pelas this then contacts the heat sink
16:44
on the uh rear there a few thermal pads
16:46
as well for some of the other power
16:47
components on this
16:51
PCB okay I've connected this uh camera
16:54
up I found some drivers on the disc that
16:56
seem to work under Windows 7 couldn't
16:58
get to install under Windows 11 though
17:01
um in the absence of any sort of lens or
17:03
being bothered to the proper amount I've
17:04
just put some f over it and put a little
17:06
pin in there to make a pinhole lens and
17:08
software gives a few options I'm not
17:11
entirely sure what all these are there's
17:12
obviously a clock frequency 22 MHz low
17:15
gain and with PFG no idea what that is
17:19
something something game programmable
17:20
Something game perhaps ver exposure
17:23
types I think focus is just like a
17:25
continuous grab until you tell it to
17:27
stop not entirely sure all these options
17:30
are obviously exposure time uh triggers
17:33
there ex external hardware trigger inut
17:35
you just trigger using a um thing on
17:37
screen so the resolution is 8176 by
17:40
6132 and you can actually bin those
17:42
where you combine multiple pixels to get
17:46
increased gain at the expense of lower
17:48
resolution down this is a 10sec exposure
17:51
obviously of the pin hole it's very uh
17:53
intensitive so we just stand still now
17:56
downloading it there's the uh exposure
17:59
so when it's
18:01
um there's a little status thing down
18:03
here so that tells you the um exposure
18:07
[Applause]
18:09
time it's this is just it
18:15
downloading um it is quite I'm seeing
18:18
quite a lot like smearing I think that I
18:20
don't know whether that's just due to
18:21
pixels overloading or something else I
18:24
mean yeah it's not it's not um out of
18:26
the question that there's something not
18:27
totally right about this camera
18:28
certainly was bodge wise on there um I
18:31
don't I'd imagine a camera like this
18:32
it's got a fairly narrow range of
18:34
intensities that it's happy with I'm not
18:36
going to spend a great deal of time on
18:38
this if you're interested in this camera
18:40
maybe for astronomy or something and
18:42
happy to sort of take the risk of it may
18:44
not be uh perfect I'll um I think I'll
18:47
stick this on eBay along with the
18:48
Illuminator I'll put a link down in the
18:50
description to the listing take your
18:52
chances to grab a bargain so for example
18:54
here we see this vertical streaking so
18:56
I'm not sure how normal that is this is
18:58
on fairly bright scene looking out the
19:02
window if I cut the exposure time down
19:04
on that it's now 1 second
19:07
exposure again most of the image
19:09
disappears again this is looks like it's
19:11
possibly over still overloading here go
19:14
that go down to say say quarter a
19:16
second so again I think there might be
19:19
some Auto gain control going on here um
19:21
this is with the PFG option let's try
19:23
turning that off and see what
19:25
happens so I'm not sure this is actually
19:27
more streaking or which just it's
19:29
cranked up the gain all the dis display
19:31
gray scale to show what um you know the
19:33
range of things that it's captured
19:36
there's one of one of 12 things in the
19:38
software there's um you can see of you
19:40
can't seem to read out the temperature
19:42
of the pelta cooler but you can set the
19:44
temperature and if you said it's a
19:46
different temperature you see the power
19:48
consumption jump up running the cooler
19:50
to get the temperature you requested but
19:52
I can't see anything anywhere that tells
19:54
you whether the cool is at the at the
19:56
temperature other than the power
19:57
consumption going down and there's no
19:59
temperature read out
20:03
here and just some yeah this is just
20:05
sort of very basic software I'm sure
20:07
there's like an API for more
20:09
sophisticated
20:10
applications but so if you know anything
20:12
more about these cameras please um stick
20:14
in the
20:15
comments um incidentally when I was
20:18
editing I didn't notice there was a bent
20:19
pin on the um CCD but I did fix that
20:22
before doing these tests and also
20:24
reactivated the um silica gel desicant
20:26
cuz I noticed it was uh I was getting
20:28
bit of condensation on the window but um
20:31
yeah so a couple of uh interesting but
20:34
maybe not particularly uh useful pieces
20:37
of Kit except for someone that's got a
20:38
very specific use so um I'll stick a
20:42
I'll stick these on eBay put a link in
20:44
the description and say hopefully
20:45
someone could actually make some uh good
20:47
use of these things
Example Output:
**Abstract:**
This video presents Part 2 of a teardown focusing on the optical components of a Fluidigm Polaris biotechnology instrument, specifically the multi-wavelength illuminator and the high-resolution CCD camera.
The Lumen Dynamics illuminator unit is examined in detail, revealing its construction using multiple high-power LEDs (430nm, 475nm, 520nm, 575nm, 630nm) combined via dichroic mirrors and filters. A square fiber optic rod is used to homogenize the light. A notable finding is the use of a phosphor-converted white LED filtered to achieve the 575nm output. The unit features simple TTL activation for each color, conduction cooling, and internal homogenization optics. Analysis of its EEPROM suggests extremely low operational runtime.
The camera module teardown showcases a 50 Megapixel ON Semiconductor KAF-50100 CCD sensor with micro-lenses, cooled by a multi-stage Peltier stack. The control electronics include an FPGA and a USB interface. Significant post-manufacturing modifications ("bodges") are observed on the camera's circuit boards. Basic functional testing using vendor software and a pinhole lens confirms image capture but reveals prominent vertical streaking artifacts, the cause of which remains uncertain (potential overload, readout artifact, or fault).
**Exploring the Fluidigm Polaris: A Detailed Look at its High-End Optics and Camera System**
* **0:00 High-End Optics:** The system utilizes heavy, high-quality lenses and mirrors for precise imaging, weighing around 4 kilos each.
* **0:49 Narrow Band Filters:** A filter wheel with five narrow band filters (488, 525, 570, 630, and 700 nm) ensures accurate fluorescence detection and rejection of excitation light.
* **2:01 Customizable Illumination:** The Lumen Dynamics light source offers five individually controllable LED wavelengths (430, 475, 520, 575, 630 nm) with varying power outputs. The 575nm yellow LED is uniquely achieved using a white LED with filtering.
* **3:45 TTL Control:** The light source is controlled via a simple TTL interface, enabling easy on/off switching for each LED color.
* **12:55 Sophisticated Camera:** The system includes a 50-megapixel Kodak KAI-50100 CCD camera with a Peltier cooling system for reduced noise.
* **14:54 High-Speed Data Transfer:** The camera features dual analog-to-digital converters to manage the high data throughput of the 50-megapixel sensor, which is effectively two 25-megapixel sensors operating in parallel.
* **18:11 Possible Issues:** The video creator noted some potential issues with the camera, including image smearing.
* **18:11 Limited Dynamic Range:** The camera's sensor has a limited dynamic range, making it potentially challenging to capture scenes with a wide range of brightness levels.
* **11:45 Low Runtime:** Internal data suggests the system has seen minimal usage, with only 20 minutes of recorded runtime for the green LED.
* **20:38 Availability on eBay:** Both the illuminator and camera are expected to be listed for sale on eBay.
Here is the real transcript. Please summarize it:
00:00:02 Imagine that we're playing a game with a
00:00:02 $100 prize. The game is interrupted. We
00:00:05 have to stop before there's a winner.
00:00:08 How should we fairly split the prize
00:00:10 money? This seemingly simple question
00:00:13 led to the invention or discovery of one
00:00:16 of the earliest and most important
00:00:18 concepts in probability theory. What I
00:00:21 like about this story is that on the
00:00:23 surface, the question has nothing to do
00:00:26 with probability. It's not about
00:00:28 randomness or chance. It's about
00:00:30 fairness. How should we fairly split the
00:00:33 prize money? So, how did fairness become
00:00:37 randomness?
00:00:44 Randomness has been a part of daily life
00:00:44 for a very long time. People used animal
00:00:47 bones and carved stones as dice. They
00:00:50 used randomness for gambling, religious
00:00:52 or divine interpretation, to adjudicate
00:00:55 disputes or make political decisions,
00:00:58 and to predict the future like a magic
00:01:00 eightball. But surprisingly, the basic
00:01:02 mathematical ideas of probability theory
00:01:05 really only started in the 16th and 17th
00:01:08 centuries. And one of the driving
00:01:11 questions was the problem of points.
00:01:19 You and I are flipping a coin. If it
00:01:19 lands on the smiley face, then you get a
00:01:21 point. And if it lands on the chalk,
00:01:23 then I get a point. The first person to
00:01:26 three points wins. I realize that this
00:01:28 game sounds very boring, so to make it
00:01:30 more interesting, there is a $100 prize
00:01:33 for the winner. You win the first two
00:01:35 rounds and then I win the next. But then
00:01:37 the game is interrupted. Maybe it's
00:01:40 something dramatic like an alien
00:01:41 invasion, but more likely we just
00:01:43 realize that this game is very boring
00:01:45 and stopped. Either way, we can't play
00:01:47 anymore. How should we fairly split the
00:01:50 prize money, the $100?
00:01:52 You can pause here and come up with a
00:01:54 rule, but remember, you have to convince
00:01:57 everyone else that it's fair.
00:02:05 Arguably, the simplest option is just to
00:02:05 give all the money to the person who
00:02:07 currently has the most points. So,
00:02:09 that's you. You might like the solution
00:02:12 right now, but it can be very unfair.
00:02:15 Imagine this. We're playing to a,000
00:02:17 points. I win the first point and then
00:02:19 the aliens invade. We're interrupted. I
00:02:22 would get all the prize money, but we
00:02:24 both still need roughly a thousand
00:02:26 points to win. That seems like a bad
00:02:29 solution. In 1494, this guy argued that
00:02:33 the players should split the prize
00:02:34 according to the ratio of the current
00:02:36 points. So, in our example, we played
00:02:39 three rounds. You won two, so you get 23
00:02:42 of the prize. That's $67ish.
00:02:46 and I won one, so I get onethird of the
00:02:48 prize. That's $33ish.
00:02:51 This seems like a better solution.
00:02:54 But then some other Italian Renaissance
00:02:56 mathematicians like this guy and this
00:02:58 guy had a pretty good counter example.
00:03:01 Imagine again that we are playing to
00:03:03 1,000 points and again I win the first
00:03:06 point and then we're interrupted. I get
00:03:08 all the money just like before. This
00:03:11 probably seems unfair to you. or you
00:03:14 have 999 points and I have 900.
00:03:17 According to the ratio rule, you should
00:03:19 get 53% of the prize money and I should
00:03:22 get 47%.
00:03:24 But you only need one point to win and I
00:03:26 need 100. So the only way I can win is
00:03:28 if the coin lands on my side 100 times
00:03:31 in a row without ever landing on your
00:03:33 side. Given that imbalance, it seems
00:03:36 unfair to split the prize money roughly
00:03:38 in half.
00:03:40 This is a pretty good objection to
00:03:42 splitting the prize based on the ratio
00:03:44 of current points. Instead of looking at
00:03:47 how many points we have already earned,
00:03:49 we should count how many points each
00:03:51 player still needs to earn to win. We
00:03:54 should look into the future.
00:04:03 In 1654, Bla1 Pascal and Pierre de Ferma
00:04:03 exchanged a series of letters about the
00:04:06 problem of points. They have two
00:04:08 different approaches, but both of them
00:04:09 know that the key is to look forward to
00:04:12 the future, not backward to the past.
00:04:15 They both argue that a fair solution is
00:04:17 the average of the future possible
00:04:19 games. And this is a spoiler for later
00:04:22 in the video. They both compute
00:04:24 something we now know is the expected
00:04:26 value. For MA starts by noting that the
00:04:30 game will end within two coin flips,
00:04:33 within two rounds. There are four
00:04:35 possibilities for those two coin flips,
00:04:37 the four possible futures for the game.
00:04:40 As FA writes, this fiction of extending
00:04:43 the game to a certain number of plays
00:04:45 serves only to make the rule easier and
00:04:47 according to my opinion to make the
00:04:49 chances equal. In three of the four
00:04:52 possible future games, you win. In the
00:04:54 other one, I win. Since each outcome is
00:04:56 equally likely for ma reasons, that your
00:04:59 chances of winning are three quarters.
00:05:01 And therefore, if the game is
00:05:03 interrupted right now, you should get
00:05:06 three quarters of the prize money, $75,
00:05:08 and I get $25. And this is the fair
00:05:12 solution. Pascal reaches the same
00:05:14 conclusion, but he looks just one round
00:05:17 into the future. On the next coin flip,
00:05:20 either you win and get all $100,
00:05:24 or we tie, and if we stop, then we
00:05:27 should split the money 50/50. Therefore,
00:05:29 he argues, either way, these $50 belong
00:05:32 to you and these $50. Perhaps I will
00:05:36 have them and perhaps you will have
00:05:37 them. The risk is equal. In other words,
00:05:40 we're equally likely to win those $50.
00:05:43 So, we should split them. $25 for each
00:05:46 of us, which gives you $75 and me $25.
00:05:51 What I love about his style, his
00:05:54 phrasing, is that he's arguing about the
00:05:56 solution in the way you might settle a
00:05:58 dispute while playing a board game with
00:06:00 friends. It's concrete and specific.
00:06:03 It's about what happens to these
00:06:05 particular dollar bills, not abstract
00:06:08 numbers or theorems. And most
00:06:11 importantly, it's about fairness, which
00:06:13 is driving this whole debate.
00:06:21 Within a few letters back and forth, you
00:06:21 can see Pascal and FMA struggling to
00:06:23 build and defend their ideas. They're
00:06:26 approaching from two different angles,
00:06:28 but they land in the same place, a new
00:06:31 concept, expected value, which has come
00:06:34 to influence practically every aspect of
00:06:36 our life. The math in these letters,
00:06:39 which can sometimes be confusing as real
00:06:42 time thinking tends to be, was later
00:06:44 written down systematically textbook
00:06:47 style, and it's now absolutely standard.
00:06:50 Nowadays, a typical first example of
00:06:53 expected value is your winnings from one
00:06:55 of those carnival spinning wheels. Each
00:06:58 segment has a specific prize. The
00:07:01 expected value is a big sum. It's the
00:07:04 probability of each outcome times the
00:07:07 value of that outcome all added
00:07:09 together. There's a one quarter chance
00:07:11 of winning $1, a 1/16th chance of
00:07:14 winning $19, a 1/2 chance of winning $0,
00:07:17 a 1/16th chance of winning $5, and a 1/8
00:07:21 chance of winning $2. So your expected
00:07:24 winnings are $2. You win on average $2.
00:07:30 Another word for expected value or
00:07:32 expectation is average or mean, except
00:07:36 it's really a type of weighted average.
00:07:39 For example, if these are your scores on
00:07:41 four different exams, then the average
00:07:43 is 70%. Just add them up and divide by
00:07:46 four. Or alternatively, multiply each
00:07:48 one by one quarter and add them up.
00:07:50 They're equally weighted, all worth one
00:07:53 quarter of your grade. But maybe the
00:07:54 first and last exam are worth more, 30%,
00:07:57 and the middle two are worth 20%. The
00:08:00 grades have different weights. This is a
00:08:02 weighted average. The expected value,
00:08:04 for example, of your carnival winnings
00:08:06 is the weighted average, where the
00:08:08 weights are the probability of that
00:08:11 specific outcome.
00:08:13 If it costs $2 to spin the wheel and you
00:08:16 do it a bunch of times, then you will
00:08:18 neither win nor lose money. So $2 is a
00:08:21 fair price. Similarly, when our game was
00:08:24 interrupted, it's fair to give each of
00:08:26 us our expected winnings. The
00:08:28 probability of winning times the prize.
00:08:32 Drawing this connection between fairness
00:08:34 and probability theory, the expected
00:08:36 value was a struggle for Pascal and FMA,
00:08:39 two giants of mathematics. But now we
00:08:42 use expected value to decide when to
00:08:45 bring an umbrella or whether to invest
00:08:47 in a house or how late is too late to
00:08:49 drink a cup of coffee. You might not be
00:08:52 walking around with a calculator
00:08:54 crunching the numbers, but this
00:08:55 perspective is baked into our daily
00:08:58 life.
00:09:04 Form's coin counting and Pascal's
00:09:04 shifting dollar bills gave us the
00:09:07 concept of expected value. But
00:09:10 understanding a mathematical concept is
00:09:12 different than being able to calculate
00:09:14 it. To find your expected winnings in a
00:09:17 different game, say we stop when you
00:09:20 have five points and I have two and
00:09:22 we're playing to 10. We need to be able
00:09:24 to calculate your probability of
00:09:27 winning. Here's where Pascal needed to
00:09:30 work some combinatorial magic. I need
00:09:33 eight points to win and you need five.
00:09:36 After 11 rounds, it's possible that
00:09:38 we're both very close to winning, but
00:09:40 nobody has won. But after 12 more
00:09:43 rounds, one of us will have won. So we
00:09:47 need to analyze what happens after 12
00:09:49 more coin flips. These are the
00:09:52 extensions, the possible futures for our
00:09:54 game. Your probability of winning is
00:09:57 equal to the number of extended games
00:09:59 that you win divided by the total number
00:10:02 of extended games. Here's the problem.
00:10:05 There are 2 to the 12th, which is 4,096
00:10:09 possibilities. That's way too many to
00:10:11 write out the way Forma did. So, how do
00:10:15 we calculate what number of them you
00:10:18 won? Well, you win if you get at least
00:10:21 five points. So, any game extension
00:10:25 where you get 5 6 7 8 9 10 11 or 12
00:10:29 points is a win for you. But of course,
00:10:33 this is not the only way you can get
00:10:34 five points. You can get five points
00:10:37 like this or this or this or more. There
00:10:40 are 12 choose five ways to get exactly
00:10:44 five points and 12 choose six ways to
00:10:47 get exactly six points and so on. These
00:10:51 numbers are a row in Pascal's famous
00:10:53 triangle or another person's famous
00:10:56 triangle depending on the time and
00:10:58 place. The triangle is most easily
00:11:01 described by saying that every entry is
00:11:03 the sum of the two entries above it.
00:11:06 Alternatively, you can say that the kth
00:11:08 entry in the nth row, we always start
00:11:11 counting from zero, is the number of
00:11:13 ways to choose k objects from n objects.
00:11:18 So the 12th row describes the possible
00:11:20 outcomes of 12 coin tosses. How many
00:11:23 ways you can get zero points, one point,
00:11:25 two points, and so on. If you get at
00:11:27 least five points, you win. That's 792 +
00:11:32 9924 + 792 + 495 + 220 + 66 + 12 + 1,
00:11:40 which is 3,32
00:11:44 possible games that you win. So, your
00:11:47 chances of winning are 3,32
00:11:50 divided by 4,96,
00:11:52 which is roughly 80%. So, your expected
00:11:55 winnings are $80.
00:12:03 Two years after their exchange about the
00:12:03 problem of points, Pascal and Vermont
00:12:06 briefly corresponded again about a
00:12:08 problem now known as gamblers ruin.
00:12:11 Again, you and I are playing a game in
00:12:13 rounds. But now, we have unequal odds of
00:12:16 winning, which really changes the
00:12:18 problem. It's like a weighted coin. You
00:12:21 have a 514th chance of winning and I
00:12:24 have a 914th chance of winning. Each
00:12:27 round, the winner gains one point and
00:12:29 the loser loses one point. The game ends
00:12:31 when one person has 12 more points than
00:12:34 the other. What is the probability that
00:12:36 you win? Form replied with the correct
00:12:40 numerical answer to this question, but
00:12:42 he didn't show his work, which seems to
00:12:44 be a theme with FMA. Correct answers
00:12:46 without explanation. You can think about
00:12:49 how to solve this gamblers's ruin
00:12:51 problem yourself. And if you want, leave
00:12:54 your answer in the comments. But please
identifier:6442
model:gemini-2.5-pro| input-price: 1.25 output-price: 10 max-context-length: 200_000
host:194.230.161.72
https://news.ycombinator.com/item?id=45055205include_comments:None
include_timestamps:1
include_glossary:None
output_language:en
cost:0.04445625
*Abstract:*
This document summarizes a detailed technical blog post by "Bowerbyte" about "Blocky Planet," a tech demo that maps a Minecraft-style voxel world onto a sphere, along with a corresponding Hacker News discussion.
The blog post outlines the significant challenges and novel solutions involved. Key among these is the use of a "quad sphere" projection to map the world's surface, which minimizes distortion compared to standard projections. To address vertical distortion as players dig inward, a system of nested "shells" is implemented, where the number of blocks per layer quadruples at set intervals to maintain consistent block sizes. The author details the complex data structure (Sector → Shell → Chunk → Block) and the logic for finding neighboring blocks, especially across the tricky sector and shell boundaries. The post also covers custom gravity, terrain generation using 3D noise, and a system for placing pre-built structures.
The Hacker News discussion reflects a highly positive reception, praising the project's technical depth and clear explanation. Commenters draw comparisons to games like *Super Mario Galaxy*, *Space Engineers*, and *Outer Wilds*, discussing the various approaches to spherical worlds. Key technical points from the community include the importance of the quad sphere to avoid polar singularities, the physics of zero gravity at a planet's core (Shell Theorem), and suggestions for alternative geometric bases like geodesic spheres or toruses.
*Blocky Planet: A Technical Deep Dive into a Spherical Voxel World*
* *Introduction: The Core Challenge*
The project aims to create a spherical, fully destructible voxel planet. The primary challenge is mapping a cubic grid to a sphere without creating severe visual distortion or breaking gameplay mechanics like building and walking, as standard grid alignment conflicts with a central gravity point.
* *Let’s Get Spherical: Surface Mapping*
* *Problem:* Mapping a flat grid to a sphere inevitably causes distortion. A simple projection creates extreme stretching at the poles.
* *Solution:* The project uses a *quad sphere,* which maps six square faces of a cube onto the sphere. This greatly reduces distortion compared to a single rectangular map.
* *Refinement:* To further improve visual quality, a pre-distortion is applied to the square grid to counteract the distortion introduced during the spherical projection, resulting in blocks that look much more like squares, even at the seams between sectors.
* *Digging Deep: Handling Vertical Distortion*
* *Problem:* On a sphere, layers have a smaller area closer to the center. Stacking identical layers results in stretched blocks near the surface and compressed blocks near the core.
* *Solution:* The world is divided into concentric *shells.* As a player moves outward into a new shell, the number of blocks per layer quadruples. This keeps the blocks' size relatively consistent.
* *Trade-off:* This creates perfect block alignment *within* a shell but results in seams at shell boundaries, where one larger block from an inner shell maps to four smaller blocks in the next shell out.
* *Planet Structure: Data Organization*
* The planet is organized hierarchically for efficient data management. The structure is: *Planet → 6 Sectors → Shells → Chunks (16x16x16) → Blocks.*
* Each block has a unique `BlockAddress` that specifies its exact location within this structure.
* *Who’s my Neighbor?: The Biggest Hurdle*
* Finding a block's neighbor is the most complex operation, especially across boundaries.
* *Vertical Shell Boundaries:* A block at the top of an inner shell has *four* neighbors "above" it in the next shell, complicating adjacency calculations.
* *Sector Boundaries:* The local coordinate systems of adjacent sectors are often misaligned (axes are swapped or flipped). This requires specific mapping logic for each of the 12 edge pairings on the quad sphere's cube net.
* *Miscellaneous Functionality: Gameplay Mechanics*
* *Player Gravity:* A custom gravity system pulls the player towards the planet's center. Gravity decreases to zero at the core, and a "thruster" allows for flight and orbital mechanics.
* *Terrain Generation:* The system uses *3D noise sampled on a sphere,* which naturally avoids the seams and distortion that would occur when mapping 2D noise. Biomes (arctic and forest) are determined by angular distance from the poles.
* *Block Structures:* Placing pre-built structures is achieved by navigating from an origin block using relative directions. This allows structures to be placed even across the "wonky" corner and shell boundary areas, though some distortion may occur.
* *Future Work*
The author plans to potentially add features like multiple planets and moons (an *Outer Wilds*-style system), chunk-based dynamic gravity, cave generation, and more realistic biomes.
*Key Points from the Hacker News Discussion*
* *General Reception:* The project and its detailed write-up were met with widespread praise for tackling a difficult problem with elegant solutions and for the clarity of the explanation.
* *Game Comparisons:* Many users compared the concept to other games with non-Euclidean or planetary physics, including *Super Mario Galaxy* (small planetoids), *Space Engineers* (spherical voxels), *Outer Wilds* (solar system exploration), and *PlanetSmith* (hexagonal voxels).
* *Gravity Physics:* Several comments discussed the realism of the gravity model, noting that according to the *Shell Theorem,* gravity should indeed fall to zero at the center of a spherically symmetric body. The weird gravity in games like *Astroneer* was also mentioned.
* *The Quad Sphere:* The choice of a quad sphere was highlighted as a critical and intelligent design decision to avoid the extreme distortion and singularity issues found at the poles of traditional latitude-longitude map projections.
* *Alternative Geometries:* Commenters proposed alternative approaches, such as using a geodesic sphere (based on triangles) for more uniform distortion or a torus, which would eliminate polar issues entirely but introduce its own topological challenges.
* *Player Experience:* Users who tried the demo reported enjoying the gameplay, particularly the ability to achieve a stable orbit around the planet using the thruster.
I used gemini-2.5-pro| input-price: 1.25 output-price: 10 max-context-length: 200_000 on rocketrecap dot com to summarize the transcript.
Cost (if I didn't use the free tier): $0.04
Input tokens: 24973
Output tokens: 1324 Abstract:
This document summarizes a detailed technical blog post by "Bowerbyte" about "Blocky Planet," a tech demo that maps a Minecraft-style voxel world onto a sphere, along with a corresponding Hacker News discussion.
The blog post outlines the significant challenges and novel solutions involved. Key among these is the use of a "quad sphere" projection to map the world's surface, which minimizes distortion compared to standard projections. To address vertical distortion as players dig inward, a system of nested "shells" is implemented, where the number of blocks per layer quadruples at set intervals to maintain consistent block sizes. The author details the complex data structure (Sector → Shell → Chunk → Block) and the logic for finding neighboring blocks, especially across the tricky sector and shell boundaries. The post also covers custom gravity, terrain generation using 3D noise, and a system for placing pre-built structures.
The Hacker News discussion reflects a highly positive reception, praising the project's technical depth and clear explanation. Commenters draw comparisons to games like Super Mario Galaxy, Space Engineers, and Outer Wilds, discussing the various approaches to spherical worlds. Key technical points from the community include the importance of the quad sphere to avoid polar singularities, the physics of zero gravity at a planet's core (Shell Theorem), and suggestions for alternative geometric bases like geodesic spheres or toruses.
Blocky Planet: A Technical Deep Dive into a Spherical Voxel World
Key Points from the Hacker News Discussion
Below, I will provide input for an example video (comprising of title, description, and transcript, in this order) and the corresponding abstract and summary I expect. Afterward, I will provide a new transcript that I want you to summarize in the same format.
**Please give an abstract of the transcript and then summarize the transcript in a self-contained bullet list format.** Include starting timestamps, important details and key takeaways.
Example Input:
Fluidigm Polaris Part 2- illuminator and camera
mikeselectricstuff
131K subscribers
Subscribed
369
Share
Download
Clip
Save
5,857 views Aug 26, 2024
Fluidigm Polaris part 1 : • Fluidigm Polaris (Part 1) - Biotech g...
Ebay listings: https://www.ebay.co.uk/usr/mikeselect...
Merch https://mikeselectricstuff.creator-sp...
Transcript
Follow along using the transcript.
Show transcript
mikeselectricstuff
131K subscribers
Videos
About
Support on Patreon
40 Comments
@robertwatsonbath
6 hours ago
Thanks Mike. Ooof! - with the level of bodgery going on around 15:48 I think shame would have made me do a board re spin, out of my own pocket if I had to.
1
Reply
@Muonium1
9 hours ago
The green LED looks different from the others and uses phosphor conversion because of the "green gap" problem where green InGaN emitters suffer efficiency droop at high currents. Phosphide based emitters don't start becoming efficient until around 600nm so also can't be used for high power green emitters. See the paper and plot by Matthias Auf der Maur in his 2015 paper on alloy fluctuations in InGaN as the cause of reduced external quantum efficiency at longer (green) wavelengths.
4
Reply
1 reply
@tafsirnahian669
10 hours ago (edited)
Can this be used as an astrophotography camera?
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
6 hours ago
Yes, but may need a shutter to avoid light during readout
Reply
@2010craggy
11 hours ago
Narrowband filters we use in Astronomy (Astrophotography) are sided- they work best passing light in one direction so I guess the arrows on the filter frames indicate which way round to install them in the filter wheel.
1
Reply
@vitukz
12 hours ago
A mate with Channel @extractions&ire could use it
2
Reply
@RobertGallop
19 hours ago
That LED module says it can go up to 28 amps!!! 21 amps for 100%. You should see what it does at 20 amps!
Reply
@Prophes0r
19 hours ago
I had an "Oh SHIT!" moment when I realized that the weird trapezoidal shape of that light guide was for keystone correction of the light source.
Very clever.
6
Reply
@OneBiOzZ
20 hours ago
given the cost of the CCD you think they could have run another PCB for it
9
Reply
@tekvax01
21 hours ago
$20 thousand dollars per minute of run time!
1
Reply
@tekvax01
22 hours ago
"We spared no expense!" John Hammond Jurassic Park.
*(that's why this thing costs the same as a 50-seat Greyhound Bus coach!)
Reply
@florianf4257
22 hours ago
The smearing on the image could be due to the fact that you don't use a shutter, so you see brighter stripes under bright areas of the image as you still iluminate these pixels while the sensor data ist shifted out towards the top. I experienced this effect back at university with a LN-Cooled CCD for Spectroscopy. The stripes disapeared as soon as you used the shutter instead of disabling it in the open position (but fokussing at 100ms integration time and continuous readout with a focal plane shutter isn't much fun).
12
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
12 hours ago
I didn't think of that, but makes sense
2
Reply
@douro20
22 hours ago (edited)
The red LED reminds me of one from Roithner Lasertechnik. I have a Symbol 2D scanner which uses two very bright LEDs from that company, one red and one red-orange. The red-orange is behind a lens which focuses it into an extremely narrow beam.
1
Reply
@RicoElectrico
23 hours ago
PFG is Pulse Flush Gate according to the datasheet.
Reply
@dcallan812
23 hours ago
Very interesting. 2x
Reply
@littleboot_
1 day ago
Cool interesting device
Reply
@dav1dbone
1 day ago
I've stripped large projectors, looks similar, wonder if some of those castings are a magnesium alloy?
Reply
@kevywevvy8833
1 day ago
ironic that some of those Phlatlight modules are used in some of the cheapest disco lights.
1
Reply
1 reply
@bill6255
1 day ago
Great vid - gets right into subject in title, its packed with information, wraps up quickly. Should get a YT award! imho
3
Reply
@JAKOB1977
1 day ago (edited)
The whole sensor module incl. a 5 grand 50mpix sensor for 49 £.. highest bid atm
Though also a limited CCD sensor, but for the right buyer its a steal at these relative low sums.
Architecture Full Frame CCD (Square Pixels)
Total Number of Pixels 8304 (H) × 6220 (V) = 51.6 Mp
Number of Effective Pixels 8208 (H) × 6164 (V) = 50.5 Mp
Number of Active Pixels 8176 (H) × 6132 (V) = 50.1 Mp
Pixel Size 6.0 m (H) × 6.0 m (V)
Active Image Size 49.1 mm (H) × 36.8 mm (V)
61.3 mm (Diagonal),
645 1.1x Optical Format
Aspect Ratio 4:3
Horizontal Outputs 4
Saturation Signal 40.3 ke−
Output Sensitivity 31 V/e−
Quantum Efficiency
KAF−50100−CAA
KAF−50100−AAA
KAF−50100−ABA (with Lens)
22%, 22%, 16% (Peak R, G, B)
25%
62%
Read Noise (f = 18 MHz) 12.5 e−
Dark Signal (T = 60°C) 42 pA/cm2
Dark Current Doubling Temperature 5.7°C
Dynamic Range (f = 18 MHz) 70.2 dB
Estimated Linear Dynamic Range
(f = 18 MHz)
69.3 dB
Charge Transfer Efficiency
Horizontal
Vertical
0.999995
0.999999
Blooming Protection
(4 ms Exposure Time)
800X Saturation Exposure
Maximum Date Rate 18 MHz
Package Ceramic PGA
Cover Glass MAR Coated, 2 Sides or
Clear Glass
Features
• TRUESENSE Transparent Gate Electrode
for High Sensitivity
• Ultra-High Resolution
• Board Dynamic Range
• Low Noise Architecture
• Large Active Imaging Area
Applications
• Digitization
• Mapping/Aerial
• Photography
• Scientific
Thx for the tear down Mike, always a joy
Reply
@martinalooksatthings
1 day ago
15:49 that is some great bodging on of caps, they really didn't want to respin that PCB huh
8
Reply
@RhythmGamer
1 day ago
Was depressed today and then a new mike video dropped and now I’m genuinely happy to get my tear down fix
1
Reply
@dine9093
1 day ago (edited)
Did you transfrom into Mr Blobby for a moment there?
2
Reply
@NickNorton
1 day ago
Thanks Mike. Your videos are always interesting.
5
Reply
@KeritechElectronics
1 day ago
Heavy optics indeed... Spare no expense, cost no object. Splendid build quality. The CCD is a thing of beauty!
1
Reply
@YSoreil
1 day ago
The pricing on that sensor is about right, I looked in to these many years ago when they were still in production since it's the only large sensor you could actually buy. Really cool to see one in the wild.
2
Reply
@snik2pl
1 day ago
That leds look like from led projector
Reply
@vincei4252
1 day ago
TDI = Time Domain Integration ?
1
Reply
@wolpumba4099
1 day ago (edited)
Maybe the camera should not be illuminated during readout.
From the datasheet of the sensor (Onsemi): saturation 40300 electrons, read noise 12.5 electrons per pixel @ 18MHz (quite bad). quantum efficiency 62% (if it has micro lenses), frame rate 1 Hz. lateral overflow drain to prevent blooming protects against 800x (factor increases linearly with exposure time) saturation exposure (32e6 electrons per pixel at 4ms exposure time), microlens has +/- 20 degree acceptance angle
i guess it would be good for astrophotography
4
Reply
@txm100
1 day ago (edited)
Babe wake up a new mikeselectricstuff has dropped!
9
Reply
@vincei4252
1 day ago
That looks like a finger-lakes filter wheel, however, for astronomy they'd never use such a large stepper.
1
Reply
@MRooodddvvv
1 day ago
yaaaaay ! more overcomplicated optical stuff !
4
Reply
1 reply
@NoPegs
1 day ago
He lives!
11
Reply
1 reply
Transcript
0:00
so I've stripped all the bits of the
0:01
optical system so basically we've got
0:03
the uh the camera
0:05
itself which is mounted on this uh very
0:09
complex
0:10
adjustment thing which obviously to set
0:13
you the various tilt and uh alignment
0:15
stuff then there's two of these massive
0:18
lenses I've taken one of these apart I
0:20
think there's something like about eight
0:22
or nine Optical elements in here these
0:25
don't seem to do a great deal in terms
0:26
of electr magnification they're obiously
0:28
just about getting the image to where it
0:29
uh where it needs to be just so that
0:33
goes like that then this Optical block I
0:36
originally thought this was made of some
0:37
s crazy heavy material but it's just
0:39
really the sum of all these Optical bits
0:41
are just ridiculously heavy those lenses
0:43
are about 4 kilos each and then there's
0:45
this very heavy very solid um piece that
0:47
goes in the middle and this is so this
0:49
is the filter wheel assembly with a
0:51
hilariously oversized steper
0:53
motor driving this wheel with these very
0:57
large narrow band filters so we've got
1:00
various different shades of uh
1:03
filters there five Al together that
1:06
one's actually just showing up a silver
1:07
that's actually a a red but fairly low
1:10
transmission orangey red blue green
1:15
there's an excess cover on this side so
1:16
the filters can be accessed and changed
1:19
without taking anything else apart even
1:21
this is like ridiculous it's like solid
1:23
aluminium this is just basically a cover
1:25
the actual wavelengths of these are um
1:27
488 525 570 630 and 700 NM not sure what
1:32
the suffix on that perhaps that's the uh
1:34
the width of the spectral line say these
1:37
are very narrow band filters most of
1:39
them are you very little light through
1:41
so it's still very tight narrow band to
1:43
match the um fluoresence of the dies
1:45
they're using in the biochemical process
1:48
and obviously to reject the light that's
1:49
being fired at it from that Illuminator
1:51
box and then there's a there's a second
1:53
one of these lenses then the actual sort
1:55
of samples below that so uh very serious
1:58
amount of very uh chunky heavy Optics
2:01
okay let's take a look at this light
2:02
source made by company Lumen Dynamics
2:04
who are now part of
2:06
excelitas self-contained unit power
2:08
connector USB and this which one of the
2:11
Cable Bundle said was a TTL interface
2:14
USB wasn't used in uh the fluid
2:17
application output here and I think this
2:19
is an input for um light feedback I
2:21
don't if it's regulated or just a measur
2:23
measurement facility and the uh fiber
2:27
assembly
2:29
Square Inlet there and then there's two
2:32
outputs which have uh lens assemblies
2:35
and this small one which goes back into
2:37
that small Port just Loops out of here
2:40
straight back in So on this side we've
2:42
got the electronics which look pretty
2:44
straightforward we've got a bit of power
2:45
supply stuff over here and we've got
2:48
separate drivers for each wavelength now
2:50
interesting this is clearly been very
2:52
specifically made for this application
2:54
you I was half expecting like say some
2:56
generic drivers that could be used for a
2:58
number of different things but actually
3:00
literally specified the exact wavelength
3:02
on the PCB there is provision here for
3:04
385 NM which isn't populated but this is
3:07
clearly been designed very specifically
3:09
so these four drivers look the same but
3:10
then there's two higher power ones for
3:12
575 and
3:14
520 a slightly bigger heat sink on this
3:16
575 section there a p 24 which is
3:20
providing USB interface USB isolator the
3:23
USB interface just presents as a comport
3:26
I did have a quick look but I didn't
3:27
actually get anything sensible um I did
3:29
dump the Pi code out and there's a few
3:31
you a few sort of commands that you
3:32
could see in text but I didn't actually
3:34
manage to get it working properly I
3:36
found some software for related version
3:38
but it didn't seem to want to talk to it
3:39
but um I say that wasn't used for the
3:41
original application it might be quite
3:42
interesting to get try and get the Run
3:44
hours count out of it and the TTL
3:46
interface looks fairly straightforward
3:48
we've got positions for six opto
3:50
isolators but only five five are
3:52
installed so that corresponds with the
3:54
unused thing so I think this hopefully
3:56
should be as simple as just providing a
3:57
ttrl signal for each color to uh enable
4:00
it a big heat sink here which is there I
4:03
think there's like a big S of metal
4:04
plate through the middle of this that
4:05
all the leads are mounted on the other
4:07
side so this is heat sinking it with a
4:09
air flow from a uh just a fan in here
4:13
obviously don't have the air flow
4:14
anywhere near the Optics so conduction
4:17
cool through to this plate that's then
4:18
uh air cooled got some pots which are
4:21
presumably power
4:22
adjustments okay let's take a look at
4:24
the other side which is uh much more
4:27
interesting see we've got some uh very
4:31
uh neatly Twisted cable assemblies there
4:35
a bunch of leads so we've got one here
4:37
475 up here 430 NM 630 575 and 520
4:44
filters and dcro mirrors a quick way to
4:48
see what's white is if we just shine
4:49
some white light through
4:51
here not sure how it is is to see on the
4:54
camera but shining white light we do
4:55
actually get a bit of red a bit of blue
4:57
some yellow here so the obstacle path
5:00
575 it goes sort of here bounces off
5:03
this mirror and goes out the 520 goes
5:07
sort of down here across here and up
5:09
there 630 goes basically straight
5:13
through
5:15
430 goes across there down there along
5:17
there and the 475 goes down here and
5:20
left this is the light sensing thing
5:22
think here there's just a um I think
5:24
there a photo diode or other sensor
5:26
haven't actually taken that off and
5:28
everything's fixed down to this chunk of
5:31
aluminium which acts as the heat
5:32
spreader that then conducts the heat to
5:33
the back side for the heat
5:35
sink and the actual lead packages all
5:38
look fairly similar except for this one
5:41
on the 575 which looks quite a bit more
5:44
substantial big spay
5:46
Terminals and the interface for this
5:48
turned out to be extremely simple it's
5:50
literally a 5V TTL level to enable each
5:54
color doesn't seem to be any tensity
5:56
control but there are some additional
5:58
pins on that connector that weren't used
5:59
in the through time thing so maybe
6:01
there's some extra lines that control
6:02
that I couldn't find any data on this uh
6:05
unit and the um their current product
6:07
range is quite significantly different
6:09
so we've got the uh blue these
6:13
might may well be saturating the camera
6:16
so they might look a bit weird so that's
6:17
the 430
6:18
blue the 575
6:24
yellow uh
6:26
475 light blue
6:29
the uh 520
6:31
green and the uh 630 red now one
6:36
interesting thing I noticed for the
6:39
575 it's actually it's actually using a
6:42
white lead and then filtering it rather
6:44
than using all the other ones are using
6:46
leads which are the fundamental colors
6:47
but uh this is actually doing white and
6:50
it's a combination of this filter and
6:52
the dichroic mirrors that are turning to
6:55
Yellow if we take the filter out and a
6:57
lot of the a lot of the um blue content
7:00
is going this way the red is going
7:02
straight through these two mirrors so
7:05
this is clearly not reflecting much of
7:08
that so we end up with the yellow coming
7:10
out of uh out of there which is a fairly
7:14
light yellow color which you don't
7:16
really see from high intensity leads so
7:19
that's clearly why they've used the
7:20
white to uh do this power consumption of
7:23
the white is pretty high so going up to
7:25
about 2 and 1 half amps on that color
7:27
whereas most of the other colors are
7:28
only drawing half an amp or so at 24
7:30
volts the uh the green is up to about
7:32
1.2 but say this thing is uh much
7:35
brighter and if you actually run all the
7:38
colors at the same time you get a fairly
7:41
reasonable um looking white coming out
7:43
of it and one thing you might just be
7:45
out to notice is there is some sort
7:46
color banding around here that's not
7:49
getting uh everything s completely
7:51
concentric and I think that's where this
7:53
fiber optic thing comes
7:58
in I'll
8:00
get a couple of Fairly accurately shaped
8:04
very sort of uniform color and looking
8:06
at What's um inside here we've basically
8:09
just got this Square Rod so this is
8:12
clearly yeah the lights just bouncing
8:13
off all the all the various sides to um
8:16
get a nice uniform illumination uh this
8:19
back bit looks like it's all potted so
8:21
nothing I really do to get in there I
8:24
think this is fiber so I have come
8:26
across um cables like this which are
8:27
liquid fill but just looking through the
8:30
end of this it's probably a bit hard to
8:31
see it does look like there fiber ends
8:34
going going on there and so there's this
8:36
feedback thing which is just obviously
8:39
compensating for the any light losses
8:41
through here to get an accurate
8:43
representation of uh the light that's
8:45
been launched out of these two
8:47
fibers and you see uh
8:49
these have got this sort of trapezium
8:54
shape light guides again it's like a
8:56
sort of acrylic or glass light guide
9:00
guess projected just to make the right
9:03
rectangular
9:04
shape and look at this Center assembly
9:07
um the light output doesn't uh change
9:10
whether you feed this in or not so it's
9:11
clear not doing any internal Clos Loop
9:14
control obviously there may well be some
9:16
facility for it to do that but it's not
9:17
being used in this
9:19
application and so this output just
9:21
produces a voltage on the uh outle
9:24
connector proportional to the amount of
9:26
light that's present so there's a little
9:28
diffuser in the back there
9:30
and then there's just some kind of uh
9:33
Optical sensor looks like a
9:35
chip looking at the lead it's a very
9:37
small package on the PCB with this lens
9:40
assembly over the top and these look
9:43
like they're actually on a copper
9:44
Metalized PCB for maximum thermal
9:47
performance and yeah it's a very small
9:49
package looks like it's a ceramic
9:51
package and there's a thermister there
9:53
for temperature monitoring this is the
9:56
475 blue one this is the 520 need to
9:59
Green which is uh rather different OB
10:02
it's a much bigger D with lots of bond
10:04
wise but also this looks like it's using
10:05
a phosphor if I shine a blue light at it
10:08
lights up green so this is actually a
10:10
phosphor conversion green lead which
10:12
I've I've come across before they want
10:15
that specific wavelength so they may be
10:17
easier to tune a phosphor than tune the
10:20
um semiconductor material to get the uh
10:23
right right wavelength from the lead
10:24
directly uh red 630 similar size to the
10:28
blue one or does seem to have a uh a
10:31
lens on top of it there is a sort of red
10:33
coloring to
10:35
the die but that doesn't appear to be
10:38
fluorescent as far as I can
10:39
tell and the white one again a little
10:41
bit different sort of much higher
10:43
current
10:46
connectors a makeer name on that
10:48
connector flot light not sure if that's
10:52
the connector or the lead
10:54
itself and obviously with the phosphor
10:56
and I'd imagine that phosphor may well
10:58
be tuned to get the maximum to the uh 5
11:01
cenm and actually this white one looks
11:04
like a St fairly standard product I just
11:06
found it in Mouse made by luminous
11:09
devices in fact actually I think all
11:11
these are based on various luminous
11:13
devices modules and they're you take
11:17
looks like they taking the nearest
11:18
wavelength and then just using these
11:19
filters to clean it up to get a precise
11:22
uh spectral line out of it so quite a
11:25
nice neat and um extreme
11:30
bright light source uh sure I've got any
11:33
particular use for it so I think this
11:35
might end up on
11:36
eBay but uh very pretty to look out and
11:40
without the uh risk of burning your eyes
11:43
out like you do with lasers so I thought
11:45
it would be interesting to try and
11:46
figure out the runtime of this things
11:48
like this we usually keep some sort
11:49
record of runtime cuz leads degrade over
11:51
time I couldn't get any software to work
11:52
through the USB face but then had a
11:54
thought probably going to be writing the
11:55
runtime periodically to the e s prom so
11:58
I just just scope up that and noticed it
12:00
was doing right every 5 minutes so I
12:02
just ran it for a while periodically
12:04
reading the E squ I just held the pick
12:05
in in reset and um put clip over to read
12:07
the square prom and found it was writing
12:10
one location per color every 5 minutes
12:12
so if one color was on it would write
12:14
that location every 5 minutes and just
12:16
increment it by one so after doing a few
12:18
tests with different colors of different
12:19
time periods it looked extremely
12:21
straightforward it's like a four bite
12:22
count for each color looking at the
12:24
original data that was in it all the
12:26
colors apart from Green were reading
12:28
zero and the green was reading four
12:30
indicating a total 20 minutes run time
12:32
ever if it was turned on run for a short
12:34
time then turned off that might not have
12:36
been counted but even so indicates this
12:37
thing wasn't used a great deal the whole
12:40
s process of doing a run can be several
12:42
hours but it'll only be doing probably
12:43
the Imaging at the end of that so you
12:46
wouldn't expect to be running for a long
12:47
time but say a single color for 20
12:50
minutes over its whole lifetime does
12:52
seem a little bit on the low side okay
12:55
let's look at the camera un fortunately
12:57
I managed to not record any sound when I
12:58
did this it's also a couple of months
13:00
ago so there's going to be a few details
13:02
that I've forgotten so I'm just going to
13:04
dub this over the original footage so um
13:07
take the lid off see this massive great
13:10
heat sink so this is a pel cool camera
13:12
we've got this blower fan producing a
13:14
fair amount of air flow through
13:16
it the connector here there's the ccds
13:19
mounted on the board on the
13:24
right this unplugs so we've got a bit of
13:27
power supply stuff on here
13:29
USB interface I think that's the Cyprus
13:32
microcontroller High speeded USB
13:34
interface there's a zyink spon fpga some
13:40
RAM and there's a couple of ATD
13:42
converters can't quite read what those
13:45
those are but anal
13:47
devices um little bit of bodgery around
13:51
here extra decoupling obviously they
13:53
have having some noise issues this is
13:55
around the ram chip quite a lot of extra
13:57
capacitors been added there
13:59
uh there's a couple of amplifiers prior
14:01
to the HD converter buffers or Andor
14:05
amplifiers taking the CCD
14:08
signal um bit more power spy stuff here
14:11
this is probably all to do with
14:12
generating the various CCD bias voltages
14:14
they uh need quite a lot of exotic
14:18
voltages next board down is just a
14:20
shield and an interconnect
14:24
boardly shielding the power supply stuff
14:26
from some the more sensitive an log
14:28
stuff
14:31
and this is the bottom board which is
14:32
just all power supply
14:34
stuff as you can see tons of capacitors
14:37
or Transformer in
14:42
there and this is the CCD which is a uh
14:47
very impressive thing this is a kf50 100
14:50
originally by true sense then codec
14:53
there ON
14:54
Semiconductor it's 50 megapixels uh the
14:58
only price I could find was this one
15:00
5,000 bucks and the architecture you can
15:03
see there actually two separate halves
15:04
which explains the Dual AZ converters
15:06
and two amplifiers it's literally split
15:08
down the middle and duplicated so it's
15:10
outputting two streams in parallel just
15:13
to keep the bandwidth sensible and it's
15:15
got this amazing um diffraction effects
15:18
it's got micro lenses over the pixel so
15:20
there's there's a bit more Optics going
15:22
on than on a normal
15:25
sensor few more bodges on the CCD board
15:28
including this wire which isn't really
15:29
tacked down very well which is a bit uh
15:32
bit of a mess quite a few bits around
15:34
this board where they've uh tacked
15:36
various bits on which is not super
15:38
impressive looks like CCD drivers on the
15:40
left with those 3 ohm um damping
15:43
resistors on the
15:47
output get a few more little bodges
15:50
around here some of
15:52
the and there's this separator the
15:54
silica gel to keep the moisture down but
15:56
there's this separator that actually
15:58
appears to be cut from piece of
15:59
antistatic
16:04
bag and this sort of thermal block on
16:06
top of this stack of three pel Cola
16:12
modules so as with any Stacks they get
16:16
um larger as they go back towards the
16:18
heat sink because each P's got to not
16:20
only take the heat from the previous but
16:21
also the waste heat which is quite
16:27
significant you see a little temperature
16:29
sensor here that copper block which
16:32
makes contact with the back of the
16:37
CCD and this's the back of the
16:40
pelas this then contacts the heat sink
16:44
on the uh rear there a few thermal pads
16:46
as well for some of the other power
16:47
components on this
16:51
PCB okay I've connected this uh camera
16:54
up I found some drivers on the disc that
16:56
seem to work under Windows 7 couldn't
16:58
get to install under Windows 11 though
17:01
um in the absence of any sort of lens or
17:03
being bothered to the proper amount I've
17:04
just put some f over it and put a little
17:06
pin in there to make a pinhole lens and
17:08
software gives a few options I'm not
17:11
entirely sure what all these are there's
17:12
obviously a clock frequency 22 MHz low
17:15
gain and with PFG no idea what that is
17:19
something something game programmable
17:20
Something game perhaps ver exposure
17:23
types I think focus is just like a
17:25
continuous grab until you tell it to
17:27
stop not entirely sure all these options
17:30
are obviously exposure time uh triggers
17:33
there ex external hardware trigger inut
17:35
you just trigger using a um thing on
17:37
screen so the resolution is 8176 by
17:40
6132 and you can actually bin those
17:42
where you combine multiple pixels to get
17:46
increased gain at the expense of lower
17:48
resolution down this is a 10sec exposure
17:51
obviously of the pin hole it's very uh
17:53
intensitive so we just stand still now
17:56
downloading it there's the uh exposure
17:59
so when it's
18:01
um there's a little status thing down
18:03
here so that tells you the um exposure
18:07
[Applause]
18:09
time it's this is just it
18:15
downloading um it is quite I'm seeing
18:18
quite a lot like smearing I think that I
18:20
don't know whether that's just due to
18:21
pixels overloading or something else I
18:24
mean yeah it's not it's not um out of
18:26
the question that there's something not
18:27
totally right about this camera
18:28
certainly was bodge wise on there um I
18:31
don't I'd imagine a camera like this
18:32
it's got a fairly narrow range of
18:34
intensities that it's happy with I'm not
18:36
going to spend a great deal of time on
18:38
this if you're interested in this camera
18:40
maybe for astronomy or something and
18:42
happy to sort of take the risk of it may
18:44
not be uh perfect I'll um I think I'll
18:47
stick this on eBay along with the
18:48
Illuminator I'll put a link down in the
18:50
description to the listing take your
18:52
chances to grab a bargain so for example
18:54
here we see this vertical streaking so
18:56
I'm not sure how normal that is this is
18:58
on fairly bright scene looking out the
19:02
window if I cut the exposure time down
19:04
on that it's now 1 second
19:07
exposure again most of the image
19:09
disappears again this is looks like it's
19:11
possibly over still overloading here go
19:14
that go down to say say quarter a
19:16
second so again I think there might be
19:19
some Auto gain control going on here um
19:21
this is with the PFG option let's try
19:23
turning that off and see what
19:25
happens so I'm not sure this is actually
19:27
more streaking or which just it's
19:29
cranked up the gain all the dis display
19:31
gray scale to show what um you know the
19:33
range of things that it's captured
19:36
there's one of one of 12 things in the
19:38
software there's um you can see of you
19:40
can't seem to read out the temperature
19:42
of the pelta cooler but you can set the
19:44
temperature and if you said it's a
19:46
different temperature you see the power
19:48
consumption jump up running the cooler
19:50
to get the temperature you requested but
19:52
I can't see anything anywhere that tells
19:54
you whether the cool is at the at the
19:56
temperature other than the power
19:57
consumption going down and there's no
19:59
temperature read out
20:03
here and just some yeah this is just
20:05
sort of very basic software I'm sure
20:07
there's like an API for more
20:09
sophisticated
20:10
applications but so if you know anything
20:12
more about these cameras please um stick
20:14
in the
20:15
comments um incidentally when I was
20:18
editing I didn't notice there was a bent
20:19
pin on the um CCD but I did fix that
20:22
before doing these tests and also
20:24
reactivated the um silica gel desicant
20:26
cuz I noticed it was uh I was getting
20:28
bit of condensation on the window but um
20:31
yeah so a couple of uh interesting but
20:34
maybe not particularly uh useful pieces
20:37
of Kit except for someone that's got a
20:38
very specific use so um I'll stick a
20:42
I'll stick these on eBay put a link in
20:44
the description and say hopefully
20:45
someone could actually make some uh good
20:47
use of these things
Example Output:
**Abstract:**
This video presents Part 2 of a teardown focusing on the optical components of a Fluidigm Polaris biotechnology instrument, specifically the multi-wavelength illuminator and the high-resolution CCD camera.
The Lumen Dynamics illuminator unit is examined in detail, revealing its construction using multiple high-power LEDs (430nm, 475nm, 520nm, 575nm, 630nm) combined via dichroic mirrors and filters. A square fiber optic rod is used to homogenize the light. A notable finding is the use of a phosphor-converted white LED filtered to achieve the 575nm output. The unit features simple TTL activation for each color, conduction cooling, and internal homogenization optics. Analysis of its EEPROM suggests extremely low operational runtime.
The camera module teardown showcases a 50 Megapixel ON Semiconductor KAF-50100 CCD sensor with micro-lenses, cooled by a multi-stage Peltier stack. The control electronics include an FPGA and a USB interface. Significant post-manufacturing modifications ("bodges") are observed on the camera's circuit boards. Basic functional testing using vendor software and a pinhole lens confirms image capture but reveals prominent vertical streaking artifacts, the cause of which remains uncertain (potential overload, readout artifact, or fault).
**Exploring the Fluidigm Polaris: A Detailed Look at its High-End Optics and Camera System**
* **0:00 High-End Optics:** The system utilizes heavy, high-quality lenses and mirrors for precise imaging, weighing around 4 kilos each.
* **0:49 Narrow Band Filters:** A filter wheel with five narrow band filters (488, 525, 570, 630, and 700 nm) ensures accurate fluorescence detection and rejection of excitation light.
* **2:01 Customizable Illumination:** The Lumen Dynamics light source offers five individually controllable LED wavelengths (430, 475, 520, 575, 630 nm) with varying power outputs. The 575nm yellow LED is uniquely achieved using a white LED with filtering.
* **3:45 TTL Control:** The light source is controlled via a simple TTL interface, enabling easy on/off switching for each LED color.
* **12:55 Sophisticated Camera:** The system includes a 50-megapixel Kodak KAI-50100 CCD camera with a Peltier cooling system for reduced noise.
* **14:54 High-Speed Data Transfer:** The camera features dual analog-to-digital converters to manage the high data throughput of the 50-megapixel sensor, which is effectively two 25-megapixel sensors operating in parallel.
* **18:11 Possible Issues:** The video creator noted some potential issues with the camera, including image smearing.
* **18:11 Limited Dynamic Range:** The camera's sensor has a limited dynamic range, making it potentially challenging to capture scenes with a wide range of brightness levels.
* **11:45 Low Runtime:** Internal data suggests the system has seen minimal usage, with only 20 minutes of recorded runtime for the green LED.
* **20:38 Availability on eBay:** Both the illuminator and camera are expected to be listed for sale on eBay.
Here is the real transcript. Please summarize it:
About
Posts
Toggle theme
Header image for Blocky Planet — Making Minecraft Spherical
Blocky Planet — Making Minecraft Spherical
August 24, 2025
Blocky Planet is a tech demo I created in the Unity game engine that attempts to map Minecraft’s cubic voxels onto a spherical planet. The planet is procedurally generated and fully destructible, allowing players to place or remove more than 20 different block types.
While much of the implementation relies on common techniques you’d expect from your average Kirkland brand Minecraft clone, the spherical structure introduces a number of unique design considerations. This post will focus on these more novel challenges.
FAQ
How can I play it?
The latest build is available for free on my Itch.io page here. While it’s optimized to run natively for Windows, there is a playable web build available to run in the browser (some jankiness may apply).
Why did you make this?
I was inspired by an old tech demo by Jordan Peck that I happened to stumble across. As someone who loves procedural geometry and voxel games, recreating it seemed like a fun challenge. There were also some missing features that I hoped to implement in my version (block textures, large-scale destruction, etc.).
Are you going to make this into a full game?
Probably not, or at least not to a level of polish I would feel comfortable charging for. Unfortunately working full time doesn’t leave much room for these side projects, and the amount of work to go from tech demo to finished product can be monumental. Though there’s a good chance I’ll push an update from time to time.
How long did it take to make?
It took me a little over a month to code, during which time I was able to dedicate about 15 hours per week. I did have previous experience with voxels, so the main challenge was just making it spherical. Ironically, it took over twice as long to write/illustrate this blog post.
What did you use to make it?
I built the project with Unity 6 using C#. While I made heavy use of Unity’s Job system and Burst compiler, I didn’t opt to go all in on DOTS. From my (admittedly limited) understanding, it seems like a significant amount of effort for a small-to-moderate performance gain, while still lacking in some basic features.
Can I see the source code?
Not currently, but I may make it public later. The current state of the code isn’t the cleanest, so my sense of pride prevents me from sharing it.
Which texture pack did you use for the blocks?
All textures were painstakingly crafted by yours truly, either using a pixel art editor or programmatically via scripts. On an unrelated note, a surprising amount of Minecraft textures can be approximated by color-tinting random noise.
I have a cool idea or question for you. Where should I ask it?
Great! Please leave any questions or feedback on the corresponding reddit post here.
If a suggestion is reasonable I might just add it (no promises though).
Let’s Get Spherical
Building a sphere out of blocks — while tricky to do by hand — is trivial with code. You can just filter for blocks whose centers lie within some distance from a central point, and voilà: a blocky sphere!
Left: 2D blocks (squares) selected if their center lies within the red disk.
Right: 3D blocks (cubes) selected if their center lies within the red ball.
This works great for architecture, but makes for a rather lackluster planet. The issue is that the surface of our blocky sphere does not align with the direction of gravity. This causes problems when trying to build “upward” on the planet or walk along its surface.
Left: 2D representation of planet constructed from grid-aligned blocks.
Right: Planet with gravity-aligned blocks.
So what we want instead is a way to arrange our blocks such that their vertical faces always align with the direction of gravity (top face points towards space, bottom face points towards planet center).
There are two (2) parts to this problem:
Mapping a 2D square grid onto a 3D sphere
Preserving block width as you move outward
Like most things in life, these problems don’t have a single “right” answer — only a bunch of potential solutions with tradeoffs. Let’s take a look at the solutions I settled on.
Cartographer’s Bane
Thanks to Gauss, we know that mapping a flat grid to a sphere is impossible without some distortion. This problem has plagued cartographers for centuries, and in their madness drove them to invent dozens of map projections, each one wrong in its own special way.
Many of these projections attempt to map the entire globe to a single rectangle. This results in an unfortunate artifact where the entire top of the rectangle represents the same point on the sphere, leading to rather extreme distortion.
Example of latitudinal distortion with an equirectangular projection. Left: 2D world map. Center: World map projected onto the globe. Right: 2D world map adjusted to show relative projected size.
To avoid this, many game developers use something called a quad sphere. Instead of mapping a single rectangle to the entire globe, quad spheres divide it into six (6) equivalent sectors, one for each face of a cube. Then a separate square can be mapped to each sector, resulting in much less distortion overall.
Six (6) squares (left) being mapped to their corresponding spherical sectors on the quad sphere (right).
The recipe to construct a quad sphere is fairly straightforward:
Start with a cube centered at the origin
Subdivide each face into a square grid
Push each vertex (corner in the grid) outward until it is exactly one (1) unit distance from the origin
Step 3 is done by normalizing each vertex point, which is equivalent to projecting it onto the unit sphere. Visually, I like to think of this as inflating the cube like you would a balloon.
Process of constructing a quad sphere. Left: Cube centered at origin. Center: Cube with subdivided faces. Right: Cube projected onto unit sphere by normalizing each vertex.
Due to mapping distortion, the projected squares are, well, no longer squares. So instead we refer to them by the more general term quads (hence the name quad sphere).
While some distortion is unavoidable, the default quad sphere has far too much for my liking. Luckily, there are some ways to reduce how much our poor quads get squished and stretched. I initially included the full explanation here, but out of respect for your time I decided to move it to a separate post (still a WIP). The gist is we want to pre-distort our square grid to counteract the distortion introduced during normalization. The outcome is quads that do a much better job of preserving the area, angles, and side lengths of the original squares.
Left: Default quad sphere mapping. Right: Improved mapping for reduced quad distortion.
To convey the importance of reducing quad distortion in practice, let’s take a look at how blocks in the same location along the border of two (2) sectors differ between mappings.
Left: Block pattern with default quad sphere normalization. Right: Block pattern with reduced distortion mapping.
The blocks with the default mapping are clearly squeezed into rectangles, while with the improved mapping they look much more like squares. This is even more noticeable when actually playing the game.
And just for fun — let’s look at a small blocky planet before and after applying any spherical projection.
The same small blocky planet before projecting vertices onto the sphere (left) and after projecting vertices (right).
Technically the pre-projection version is fully playable. Though it feels like you’re constantly walking on a slope since gravity still pushes you towards the planet center.
Digging Deep
Now that we have a fairly nice surface mapping, we need to handle the distortion that comes with depth.
Depth in a flat blocky world is simple — you can just keep stacking identical layers on top of one another without issue. However, on a spherical blocky world this will lead to thin blocks near the the planet’s center and wide blocks near the surface (assuming constant block height, which we want).
Left: 2D block column from a flat world. Right: 2D block column from a spherical world using a constant number of blocks per layer.
The way to minimize this distortion is to add more blocks to each layer as you move outward from the center. We could technically calculate the ideal number of blocks for each layer and use that, but this would cause the edges of blocks to not align properly — making for unsatisfying walls and pillars.
Left: 2D block column from a flat world. Right: 2D block column from a spherical world using the “ideal” number of blocks per layer.
A compromise is to only add more blocks to a layer when the block distortion becomes too great. In addition, to ensure that the seams of the previous layer align with those of the next layer, we need to increase the number of blocks by some integer multiple. We could use any integer ≥ 2, though using the smallest value of 2 will lead to the least distortion.
This results in our block layers being grouped into shells, where within each shell all the block sides will align nicely. But as we move outward, each shell quadruples (2^2) the number of blocks per layer to keep their size roughly consistent. This does mean that the blocks at the bottom of a shell will be a quarter of the size of the blocks at the top, but I consider that a fair compromise for edge alignment. It also has the added benefit of organizing the blocks of each shell into a regular grid, which will make the code much cleaner and more efficient.
Left: 2D block column from a flat world. Right: 2D block column from a spherical world divided into shells. In the 2D case, each shell doubles the number of blocks per layer, as well as increases in the number of layers per shell as you move outward.
Planet Structure
Now that we’ve addressed the various distortions, let’s focus on how the planet is represented in practice.
In a flat blocky world, the structure for storing blocks is fairly simple. You have the world divided into column chunks, which span from the minimum to maximum build heights. Each column chunk is then subdivided vertically into render chunks. For instance, Minecraft uses column chunks of size 16x320x16 blocks, which get divided into render chunks of size 16x16x16 blocks.
Left: Flat blocky world divided into column chunks. Center: Single column chunk. Right: Zoomed-in view of single render chunk.
In contrast, the spherical world is divided into six (6) wedge-like sectors, one for each axis direction. This comes from our choice to represent the planet surface with a quad sphere.
Each sector is then subdivided “vertically” into shells. As you move alway from the planet origin, these shells get larger both in terms of the number of layers, as well as the number of blocks per layer. There is no restriction on the number of shells, meaning this structure can “cover” all of 3D space (for now I do set a max build height, but that’s not a limit of the planet structure itself).
For efficiency, I further separate these variable-sized shells into regularly sized chunks with dimension 16x16x16 blocks.
Left: Spherical blocky world divided into six (6) sectors. Center: Single sector split into shells (three shown here). Right: Zoomed-in view of single chunk from outer shell.
To give you an idea of how this looks in-game, here are two (2) screenshots of from early versions of Blocky Planet that show an exploded view of the world.
Screenshots showing a spherical planet “exploded” into its distinct sectors and shells with a glowing core.
Left: Randomly colored chunks with every other block missing. Right: Fully filled shells with more natural colors.
What’s my address?
For mechanics like placing blocks, we need to be able to take a world position and get the corresponding block address.
A block address specifies the exact location of a block’s data within the planet’s overall structure. It works much like a postal address that becomes increasingly precise, going from Country → State → City → Building. For a block address, the sequence is Sector → Shell → Chunk → Block.
If code is more your thing, here’s an example of how I represent this address as a C# struct:
struct BlockAddress
{
public int sectorIndex; // 0 - 5
public int shellIndex; // 0 - +Infinity
public int3 chunkIndex; // [0-n, 0-n, 0-n]
public int3 blockIndex; // [0-15, 0-15, 0-15]
}
Finding the address from a world position requires a few steps that you probably don’t care about, so I’ll skip them for now. Oh, and in case you were wondering, this is all trivial to do on a flat blocky world.
Who’s my Neighbor?
A vital operation in any blocky game is the ability to efficiently find neighboring blocks. This is used for mechanics like placing/breaking multiple blocks at once, as well as optimizations like only drawing block faces that are visible to the player. As you can probably guess, finding neighboring blocks is trivial in a flat voxel world. However, I found solving this problem consistently to be the most challenging part of this project (and to be honest, I think I still missed an edge case).
Goal: Given an block address and one of six (6) axis directions, return the address of the neighboring block in that direction.
These axis directions correspond to the positive and negative directions of the 3D coordinate axes, which are: Left = -X, Right = +X, Down = -Y, Up = +Y, Back = -Z, and Front = +Z.
Diagram of six (6) axis directions where a block can have a neighbor.
If the neighbor is within the same chunk, or even within the same shell, their address is fairly easy to find. However, it gets trickier when crossing shell boundaries.
Vertical Shell Boundaries
Vertical shell boundaries already break one of our assumptions — that a block only has a single neighbor in a given direction. How very inconvenient…
This comes from our attempt to minimize depth distortion by adding more blocks in successive shells. In my case, that means a block at the top of shell N will map to four (4) separate blocks at the bottom of shell N+1. The inverse is also true — those four (4) blocks will share a single downward neighbor.
This complicates the code a bit, but isn’t too difficult to account for. It just means some extra checks when handling vertical neighbors.
Diagram showing how one block can have four (4) neighbors in the up direction. Each of these neighbors will be a quarter the size of the base block.
And in case you’re curious, here’s how these vertical shell boundaries look in-game:
Screenshot showing a vertical shell boundary. Four (4) blocks of different types are placed on top of a single glass block in a lower shell.
Sector Boundaries
Sector boundaries are tricky because unlike neighboring chunks, we cannot assume the neighboring sector will share the same local alignment. For example, let’s consider the flat squares that corresponds to our six (6) sectors (think back to the quad sphere). Each square will have its own local 2D coordinate system, which I’ll refer to here using the variables u and v.
Six (6) sector squares with local (u, v) coordinate systems.
From left-to-right and top-to-bottom: Front, Up, Down, Left, Right, Back.
In order to assemble the planet surface from these squares, we have to glue their edges together. This results in twelve (12) edge pairings. Where things get difficult is that each pairing can be misaligned in one or both of the following ways:
Axes are mismatched (a u axis glued to a v axis)
Axes are flipped (pointed in opposite directions)
Diagram showing all four (4) alignment combinations between sector faces.
These misalignments are unavoidable, but can be accounted for by swapping/flipping indices. Though the matter of how each pairing is misaligned comes down to how you decide to glue everything together. This is an arbitrary decision, but it’s important to stay consistent once decided. The diagram below shows the cube net corresponding to my choices for how to glue the sides of my planet together.
Cube net representing the way sector faces are joined in Blocky Planet (think of this as an unrolled cube).
Miscellaneous Functionality
Whew! That concludes the discussion of the more structural aspects of making a spherical blocky planet. Now the rest of this post will touch on a few other considerations regarding gravity and world generation.
Player Gravity
The player uses a fairly standard physics-driven controller that applies forces to a rigidbody to move around. However, in order to stop the player from just falling off the side of the planet, I disable the built-in downward gravity and apply my own custom gravity that accelerates the player towards the center of the planet.
While I do adjust the strength of gravity based on distance, it’s more vibes-based than physically accurate. I keep the gravity constant when above the surface terrain so the gameplay stays predictable. However as you dig towards the planet’s center the gravity decreases towards zero (0) to simulate the planet pulling on you equally in all directions.
I also added a “thruster” ability that can be triggered by holding SPACE while in the air. This applies an opposite force to counteract and overpower gravity, making it easy to get into orbit around the planet.
Diagram showing gravity accelerating the player towards the center of the planet. Players can fly using their thruster, and with enough horizontal velocity they can even get into a stable orbit. Gravity decreases towards zero (0) near the center of the planet.
Terrain Generation
Like most terrain generators, I use smooth noise to determine the terrain height. Once the height is known, the types for all the blocks can be calculated using the following steps:
Set all blocks to empty (air) blocks
If a block falls below the terrain height, set it to stone
Convert blocks to grass or dirt depending on their distance from the top of their respective column
If a block falls below the planetary water level, then make the following conversions:
Grass → Sand
Air → Water
Process of generating chunks based on terrain height.
The specifics of exactly how the terrain height is generated for all the columns is where spherical worlds differ from flat ones. Games with flat worlds (i.e. most of them) use 2D noise to generate a height map. You can then just look up a column’s corresponding height using its (x,z) coordinates.
There are two (2) issues that make this challenging to apply to a spherical world:
The noise values need to smoothly tile across the sphere (i.e. produce no visible seams)
Mapping 2D noise to the sphere will introduce some distortion (see first half of this post)
Luckily, there’s a far easier solution — sample a 3D noise function on a sphere. This solves both the tiling problem (since there are no seams) and the distortion problem (since we’re not converting from 2D to 3D). We can sample the unit sphere by default, but we are free to sample spheres with a different radii to create noise at different scales (for different planet sizes). In addition, we can translate the sphere in our noise space to implement random seeds.
This type of noise could also be used for a biome system like in the real Minecraft, however for now I use a simpler approach. My planets only have two (2) biomes — forest and arctic. To determine if a given block column is in the arctic biome, I look at its angular distance to either pole (North and South). If this falls below some threshold angle, it’s considered to be arctic, otherwise it’s forest. I also add some smooth noise to this threshold to prevent a perfect circular border between these two (2) biomes.
Screenshot showing planet’s arctic biome surrounding the North pole. Notice the irregular border where snow turns to grass.
Block Structures
I consider block structures to be any saved arrangement of blocks that can be pasted into the world. This includes natural structures like trees that get placed during world generation, as well as saved player-built structures like this house below.
Example of two (2) types of block structures: oak trees and a player-built house.
These structures are saved as 3D arrays of blocks (referred to below as the source zone). In theory placing them should be as straightforward as:
Determining the destination zone on the planet where the structure should be placed
Copying each block from the source zone to its corresponding position in the destination zone
Example of source zone (blue) being mapped to a corresponding destination zone (orange) on the blocky planet.
But as we’ve seen many times now, nothing is ever easy on a spherical blocky world.
When it comes to placing block structures, there are two (2) edge cases that can throw a wrench into things:
The corners where three (3) sectors meet break the regular horizontal grid topology, since three (3) blocks meet at the corner instead of four (4)
Vertical shell boundaries break the regular vertical grid topology, since a block can have four (4) vertical neighbors instead of just one (1)
This means that there are places on our planet where it’s impossible to define a box-shaped zone of blocks that corresponds to the block structure’s source zone. I could just detect and prevent structures from being placed at these locations, but I opted for a more general solution.
Instead of viewing the block structure as a single box being placed at once, I interpret it as placing an origin block that I then build out from to create the structure. This results in each block having its own series of directions from the origin block to its relative address. We can then leverage the previous work we did for finding neighboring block addresses to navigate using these directions.
Visualization of block structures stored as relative directions from an origin block. In this case, the player would only need to place the destination origin block, and then the rest of structure would “grow” out from it.
Placing structures will now “work” everywhere, though it can get a little wonky around the problematic areas. Still, I prefer this to having dead zones where no structures can be placed at all.
Screenshot showing house structure being placed across a vertical shell boundary. This results in the roof blocks appearing shrunk to a quarter the size of the base blocks since they are in the higher shell.
Screenshot showing house structure placed on the corner of three (3) sectors. This causes the house to “wrap” in upon itself. In cases like this, some blocks in the structure may navigate to the same block address, causing them to overwrite one another.
Future Work
I’m not sure how much time I’ll spend on Blocky Planet going forward. Nevertheless, I already have a long backlog of features I’d like to implement. Some have already been mentioned earlier in this post, but I’ll repeat them here for clarity.
Multiple Planets/Moons: Since starting this project I’ve envisioned an Outer Wilds style solar system filled with blocky planets that the player can navigate between. These planets could follow a simple clockwork style movement, or use a more advanced gravity simulation (ex. Sebastian Lague’s solar system project).
Chunk-Based Gravity: Gravity should be calculated dynamically per chunk based on the blocks in said chunk. This should be doable with little to no performance hit, and would result in more “realistic” gravity when inside a planet.
Planet Collisions: Assuming multiple planet’s are implemented, I’d like to support some form of collision between them (ex. blocky asteroids crashing into planets). However, just thinking about implementing this gives me a headache, so I wouldn’t expect it in the near future (if ever).
Cave Generation: As fun as walking on the planet is, I think exploring caves leading from the surface to the planet’s core would be even better.
Proper Biomes: Procedural generation on a planet allows for more realistic biome generation, since you can take into account factors like distance to the equator.
Voxel-Based Lighting: I currently use Unity’s direct lighting and shadowing system for the planet. This works well enough, though to get better global illumination I’d like to combine this direct lighting with a proper voxel-based lighting system (similar to actual Minecraft).
If there’s any features you would like me to implement, or if you have any feedback in general, feel free to leave a comment on the Reddit post here.
Bowerbyte
Pages
Home
About
Posts
Projects
also summarize the discussion:
Hacker Newsnew | past | comments | ask | show | jobs | submit login
Making Minecraft Spherical (bowerbyte.com)
660 points by iamwil 19 hours ago | hide | past | favorite | 89 comments
mrtracy 15 hours ago | next [–]
Wonderful write-up of attempting to tackle this problem. I believe there must be a significant number of people who have played both Minecraft and Super Mario Galaxy, and had something like this sequence of thoughts - although you have followed it all the way to an actual demonstration, and written up your thoughts along the way so clearly.
The vertical distortion is the biggest issue IMO, there are a few reasonably satisfying ways to approach the horizontal tiling of each “shell”. For example, you can make your world a donut instead of a sphere, and now you have a perfect grid at each level! Of course, this introduces a level of distortion between the interior and exterior, so you also twist the donut once, and now you’ve both solved your distortion problem and invented the stellarator fusion device.
reply
simooooo 2 hours ago | parent | next [–]
There are shader packs for actual Minecraft that make the world spherical, it’s a nice addition
reply
tantalor 9 hours ago | parent | prev | next [–]
Never played Super Mario Galaxy. How does it relate to this topic?
reply
mrtracy 6 hours ago | root | parent | next [–]
Many of the levels in that game take place on tiny planetoids with spherical surfaces and central gravity. "Spherical" sells it short, there were some truly wild topologies around which Mario could run and jump.
reply
kg 7 hours ago | root | parent | prev | next [–]
It has lots of little planets with their own gravity you can jump between.
reply
fennecbutt 11 hours ago | parent | prev | next [–]
Space engineers
reply
reactordev 15 hours ago | prev | next [–]
You should definitely have a look at space engineers. They have a similar spherical problem with their voxels and I don’t think they went half as far as you did when implementing “orbital bodies”.
As someone who is rather keen on space, gfx, and the algorithms that render them. Kudos. The problems were known to me, which is why I didn’t attempt it, however - the distortion correction, the chunking, I’m thinking if you just limit how far down you can dig (half way to the “core”) it will be fine. You won’t run into those tiny squished blocks that make up the core.
It’s also important to call out the quad-sphere. This is what makes it doable. Naive devs may just map lat long to sin cos spherical coordinates and call it a day, not realizing that their poles are jacked up. The cartography problem. I’m really glad to see that called out as people don’t realize WGS84 sucks for mapping a sphere.
reply
lsaferite 15 hours ago | parent | next [–]
Not allowing excavation to the core solves weird gravity issue as well. Astroneer had super weird gravity at their planet core. You can get stuck oscillating there.
reply
reactordev 15 hours ago | root | parent | next [–]
If you really wanted to go for realism, there would be NO GRAVITY at the core. :P
As you dig down you would get lighter and lighter on your feet.
Any mass you are below (within the sphere of Earth) will exert a gravitational pull in one direction, while the mass above you (also within the Earth) will exert an equal and opposite pull.
reply
hdjrudni 5 minutes ago | root | parent | next [–]
If earth was just full of water.... as you swam deeper and deeper there would be more and more pressure upon you. Would there be a point where that pressure would start to lessen as the water is pulled in all directions?
reply
nomdep 6 hours ago | root | parent | prev | next [–]
If you REALLY want to aim for realism, gravity should depend on all quads on the planet. So, if you were to build a huge floating island, the gravity between it and the planet would be less than the usual
reply
DrewADesign 5 hours ago | root | parent | next [–]
If you really truly wanted to aim for realism, digging to the core would require a huge budget and an international coalition that would get bogged down in politics and mismanagement and it would never happen.
reply
reactordev 41 minutes ago | root | parent | next [–]
30 year pension plan.
reply
lsaferite 14 hours ago | root | parent | prev | next [–]
Yeah, I'm mostly aware of that. Weird didn't mean 'wrong' in this case, just weird for a terrestrial-bound human. :)
reply
reactordev 14 hours ago | root | parent | next [–]
There’s all sorts of weird physics in the universe ;)
reply
ricardobeat 14 hours ago | root | parent | prev | next [–]
That's how it's implemented in the game!
reply
jacquesm 15 hours ago | root | parent | prev | next [–]
That actually sounds pretty close to what I would expect to happen IRL. After all the mass is mostly all around you at that point and depending on how far you are towards the core you might build up speed, overshoot the target and then do it all over again.
But hollow planets are hard to come by so this is just my imagination, I'm sure someone has worked out exactly what would happen.
reply
gizmo686 12 hours ago | root | parent | next [–]
Newton worked this out in what is now know as the shell theorem. If you have a hollow spherically symmetric body, then any point inside of the body experiences no net gravitational force. In contrast, points outside of the shell experience the same force as if the body were a point mass.
For ideal (spherically symmetric) planets where a point is underground, you can divide the planet into 2 regions. The shell of the planet "above" the point has no net effect, while the shell below has the full effect, resulting in the gravity falling towards 0 as you approach the center.
In practice, planets are not actually spherically symmetric, but are close enough for it to be a good approximation.
reply
jacquesm 11 hours ago | root | parent | next [–]
That's super interesting, thank you for posting this!
reply
Aeolun 7 hours ago | root | parent | prev | next [–]
I think the outer wilds did this perfectly. I seem to remember falling towards the core and gravity just disappearing.
reply
RA2lover 12 hours ago | parent | prev | next [–]
My understanding is Space Engineers takes the "blocky sphere" approach mentioned early in the post, works around the "walk along its surface" part of the problem by making gravity direction point towards a fixed point, and bypasses the "trying to build 'upward'" part of it by not allowing voxel construction. It doesn't use a quad-sphere at all.
reply
reactordev 10 hours ago | root | parent | next [–]
Correct, which is why I said they didn’t go half as far as the OP did. Most stop at quadsphere after realizing their blocks are no longer square.
reply
cyptus 10 hours ago | parent | prev | next [–]
thats why a liquid core is needed in the matrix
reply
pvankessel 4 hours ago | root | parent | next [–]
Curious about this, is there actually a canonical explanation in the trilogy somewhere?
reply
accrual 15 hours ago | prev | next [–]
This is SO fun! You have the foundation for a cool voxel-y interplanetary game if that's your jam. I had fun "getting into orbit" and watching my velocity increase at periapsis and decrease at apoapsis, then descending and landing with the rocket power button ([Space]). I would love a Minecraft + Kerbal Space Program fusion game and most of the pieces for it are already here. :D
reply
RA2lover 12 hours ago | prev | next [–]
Eco: Global Survival (https://play.eco/) bypassed the distortion problem entirely by using an undistorted flat voxel grid, but rendering the globe view as a torisphere.
It still has the tradeoff of making travel close to the center take longer than it should on a sphere (worked around by limiting diggable height), but i find it a more elegant solution.
reply
mrtracy 11 hours ago | parent | next [–]
It's an elegant rendering trick, but if their worlds are represented as a torus, then I expect this would make rotation on a spherical globe view unintuitive.
One example of this: I would expect each location would not have a single antipode (opposite coordinate) but would instead have three. If you were to start at location A, rotate travel 180 degrees along the latitudinal axis to location B, then 180 degrees around the longitudinal axis... on a sphere you would expect to be back at location A, albeit upside down. But on a torus, you are in a completely different location, which is the 'C' antipode. Rotating 180 degrees latitudinally from here will bring you to point D, the last of the antipode set.
reply
RA2lover 8 hours ago | root | parent | next [–]
I don't find it to be a problem as planning a route from A to B isn't done by looking directly for it, but by subconsciously referring to and plotting a path through landmarks along the way that aren't close to antipodal.
One of the worlds i played on had road planning from the start and a set of roadways covering the entire world in a 4x4 square grid. Pathing to point D was just a matter of going 2 blocks in one direction, and 2 blocks in an orthogonal to it.
In a world without such roadways, you'd look for landmarks such as oceans and continents instead.
Ultimately, you don't care if somewhere is antipodal or not because you never see the antipodes to where the globe is currently looking at without rotating the globe.
reply
superb_dev 9 hours ago | parent | prev | next [–]
I had a similar idea while reading this article, it’s very cool to see someone implemented it!
reply
exDM69 16 hours ago | prev | next [–]
The article doesn't describe the way to avoid the difference in rectangle size in a cubesphere, so let me.
The bad way: - Generate a cube - Subdivide each face using linear interpolation (lerp) - Normalize each vector to put it on a unit sphere
The good way: - Generate a cube - Subdivide using spherical linear interpolation (slerp) - done!
The cubesphere has lots of interesting geometric properties, particularly in texture mapping.
reply
mikepurvis 11 hours ago | prev | next [–]
Given how naturally you can map a grid of quads onto a strip of adjacent triangular faces, I wonder if you might end up with a better distribution of the distortion using a geodesic sphere rather than a puffed-out cube as the basis— at the cost, of course, of an even more hair-raising coordinate scheme for actually addressing it all.
Anyway, you're never going to avoid the existence of some special nodes where three corners come together, and this does nothing to address the altitude problem, but I think it might result in a more uniform surface especially as the overall diameter goes up.
reply
ChrisGreenHeur 1 hour ago | prev | next [–]
Should have used a tetrahedra the size of the world sphere, and subdivided it until the smallest size of a voxel is reached, based on camera location. Then convert it to triangles where it intersects with air.
Then you get automatic LOD.
reply
gatane 13 hours ago | prev | next [–]
This reminded me of another attempt, but in Minetest:
- https://youtu.be/ztAg643gJBA?si=8vDgg0rFCOj9I7no
This person has another, more technical video where they talk about the math behind it btw
reply
wolframhempel 16 hours ago | prev | next [–]
This was beautifully written and illustrated.
reply
cantor_S_drug 11 hours ago | parent | next [–]
I think Tiny Glade and games like it are the advanced iterations of minecraft.
reply
bckr 15 hours ago | parent | prev | next [–]
Yep, pure joy to read.
reply
perihelions 15 hours ago | prev | next [–]
I suppose the same shell trick could also work on hyperbolic maps too, right? I've wondered what Minecraft would look like on a hyperbolic plane, if you were to squeeze an exponential amount of terrain within a linear radius. It's a strange thing to say, but I think it's more "practical" than Euclidean geometry in the sense that every is very close to everything, but there's still plenty of room.
reply
boriskourt 15 hours ago | prev | next [–]
I wonder if this is also how Eskil Steenberg's 'Love' worked. [0]
It had a spherical 'block' world as well.
[0]: https://www.quelsolaar.com/love/
reply
iamacyborg 8 hours ago | parent | next [–]
I came here to also mention this game, it suffered from a bunch of gameplay issues but the tech was absolutely fascinating.
reply
Tremeschin 12 hours ago | prev | next [–]
Earlier versions of the now abandoned Seed of Andromeda [0] [1] had planet-scale voxels with physics! I remember causing huge avalanches with explosions, or watching many pools of water flowing downhill [2] myself, it had so much potential..
There was a dev blog or two I couldn't find in Wayback except a YouTube video [3] on how they mapped the sphere to voxels. Not that one would notice much local effects at these scales (Flat Earth illusion), but Blocky Planet showcases the other end of the extremes, where Distant Horizons' curvature option or some other rounded world shaders out there could never achieve! (+Outer Wilds vibes)
[0]: https://github.com/RegrowthStudios
[1]: https://web.archive.org/web/20210416224527/https://www.seedo...
[2]: https://youtu.be/qCoyNH6y7CU?t=529 + at 9:23
[3]: https://youtu.be/bJr4QlDxEME
reply
eclipticplane 3 hours ago | prev | next [–]
Loved the writeup.
Are there any Minecraft clones that operate on a cubic world? Could be really fun building out a base on an edge, or on a corner!
reply
jeffparsons 6 hours ago | prev | next [–]
I took a swing at something vaguely similar a long time ago now: https://github.com/jeffparsons/planetkit
My approach was to build a hex grid on a geodesic sphere. It's a very different trade-off.
reply
vova_hn 14 hours ago | prev | next [–]
I wonder if it is possible to avoid "digging deep" problem by first building a cube out of voxels and then applying the type of distortion that turns the cube into quad sphere not just to the surface of the cube but also to the insides of the cube.
I don't know how to explain it better, perhaps I should try to write some code, lol
reply
seabass-labrax 10 hours ago | parent | next [–]
I see what you mean. An assumption in Minecraft-style games is the character stays the same size, but this needn't be the case. Your character could get smaller the further you dig down in order to match the decreasing size of the interior voxels. This would even create a kind of forced-perspective effect when looking down a hole, as objects at the bottom would look far more distant than they really are.
reply
skybrian 13 hours ago | parent | prev | next [–]
It seems like the easiest way would be if you hit immutable lava at some point.
reply
sixo 12 hours ago | root | parent | next [–]
Just like in real life. Wait a sec...
reply
torial 9 hours ago | prev | next [–]
In a similar voxel system, for Roblox there is: https://web.roblox.com/games/4597506405/Gravity-Controller, my youngest son made a game based on it: https://www.robloxgo.com/game/4617217359/Gravity-Combat
reply
programjames 10 hours ago | prev | next [–]
I wonder if there's a way to do something similar to Rectangular Surface Parameterization[1] with voxels. It would allow you to get pretty even-volumed voxels, and also simplify vertex identification (same three coordinates, nonlinear connection).
[1]: https://www.cs.cmu.edu/~kmcrane/Projects/RectangularSurfaceP...
reply
sureglymop 10 hours ago | prev | next [–]
Super cool demo!
I think the only thing that could dethrone Minecraft would be a voxel game with much smaller voxels (relative to the first person view). Maybe 1/8th the size of Minecraft blocks.
reply
redundantly 13 hours ago | prev | next [–]
I had a bit of fun playing with the orbital mechanics of it. First soaring around the planet core, then around the planet itself.
At one point I flew far enough into space that I passed the star objects and everything got dark. That was a bit disquieting.
Very cool little game!
reply
mikestaas 6 hours ago | prev | next [–]
This is a problem I have spent quite some time thinking about but never came up with such an elegant solution. Fantastic write-up, thanks. I do hope you open source it at some stage, would love to have a play around with the code.
reply
al_borland 15 hours ago | prev | next [–]
Flying up too high becomes quite interesting. Eventually you hit the point where you're missing the ground and end up on an upward spiral... essentially falling up. You have to go backward to find a place where you can start falling down back toward the ground.
reply
andrewclunn 14 hours ago | parent | next [–]
This could be fixed by adding a barrier at a high enough altitude. A firmament if you will. This would allow the minecraft map to appear round, when we all know it's really flat...
reply
yencabulator 12 hours ago | prev | next [–]
This made me think of Google's S2. 64-bit ID for every less-than-1cm^2 roughly-square area on Earth's surface, less bits used for bigger areas.
https://s2geometry.io/
https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSn...
reply
Tepix 3 hours ago | parent | next [–]
In the case of Minecraft and similar games, just targeting the surface isn‘t enough.
reply
yencabulator 3 hours ago | root | parent | next [–]
The article added a z-coordinate, same thing applies.
reply
ekusiadadus 4 hours ago | prev | next [–]
It would be nice to have an edge transition table, but implementing it sounds pretty tough.
reply
mkaic 13 hours ago | prev | next [–]
My favorite Spherical Minecraft-like gamedev project is PlanetSmith [0], which uses hexagonal voxels (and a few pentagonal voxels). The devlogs are very well produced and I highly recommend checking them out.
[0] https://youtube.com/@incandescentgames
reply
seabass-labrax 10 hours ago | parent | next [–]
This is mentioned in the article:
> You can even reduce the amount of visible distortion by restricting players to a portion of a shell, so they never see the full difference in block size at its top and bottom.
> From what I can tell, this seems to be the approach used by the upcoming game PlanetSmith for its hexagonal-blocky planets.
reply
newswangerd 12 hours ago | prev | next [–]
Huh, I submitted this article last week when it came out and it didn’t get any attention at all.
This demo is super cool! I’ve been dreaming about a game with an engine like this for the last 5 years. Super happy to see people experimenting with it!
reply
jamilton 14 hours ago | prev | next [–]
Neat. Reminds me of Planet Smith, a work in progress game with a similar concept (spherical Minecraft), except it uses hexes instead of cubes. Hexes reduce distortion, but add their own complexity. There’s a small number of pentagons on the surface, too, to make the tiling work.
reply
jitl 12 hours ago | prev | next [–]
Wow, Minecraft X Outer Wilds… I should really finish Outer Wilds. It’s incredible and super fun to explore the solar system but I find many of the challenges quite difficult to navigate with the zero g thrusters.
reply
pgt 14 hours ago | prev | next [–]
Getting `ERR_SSL_VERSION_OR_CIPHER_MISMATCH` for link, but non-HTTPS works: http://www.bowerbyte.com/posts/blocky-planet/
reply
s20n 14 hours ago | parent | next [–]
I got the same error but I refreshed the page and it let me right through.
also, the certificate on this website was created less than an hour ago: Mon, 01 Sep 2025 15:24:40 GMT
reply
mparrett 11 hours ago | prev | next [–]
Nice work! I've tinkered with this idea a bit in an unpublished project. How do you handle the singularities at the cube corners where three faces meet?
reply
Waterluvian 14 hours ago | prev | next [–]
> dozens of map projections.
This has plagued me for decades and I’ve been exposed to hundreds of projections. Probably thousands if you consider each UTM or MGRS zone to be its own projection.
God do I wish the Earth was flat.
reply
s0a 14 hours ago | prev | next [–]
how about making the player smaller as you get closer to the core? then each layer appears the same. would be no seams where layers double/halve.
reply
wmichelin 7 hours ago | prev | next [–]
I chuckled when I got to the Core and it was a cube
reply
magicmicah85 13 hours ago | prev | next [–]
This is a great demo. I love the laser, just destroying an entire voxel planet was pretty fun.
reply
johnisgood 13 hours ago | prev | next [–]
I could access the site a minute ago, but now I get "ERR_QUIC_PROTOCOL_ERROR". It works again.
> Not currently, but I may make it public later. The current state of the code isn’t the cleanest, so my sense of pride prevents me from sharing it.
Felt that.
reply
themanmaran 8 hours ago | prev | next [–]
All these squares make a circle.
reply
durhamg 11 hours ago | prev | next [–]
I made a planetoid Minecraft demo back in the day, but I left the planet as a cube. Each cube had a defined gravity direction, so you could rig it so that no matter what face you were on, gravity pointed "down". Having gravity be a customizable per cube allowed for cool things like having the center of the planet have reversed gravity, so if you dug too deep you'd find a cavern and could walk on the inner surface of the planet , effectively upside down. Or you could have two planets near each other and build upwards until you entered the others gravity well. I also added portals, so you could even jump through a portal fast enough to get thrown up to a neighbouring planet.
Obligatory awkward demo: https://youtu.be/PDZGzL4GRF0?si=K9vfMhbcg5Vvd1_A
reply
tomrod 15 hours ago | prev | next [–]
I wish minecraft would adopt this mode! I'd love limited collab worlds.
reply
card_zero 11 hours ago | prev | next [–]
I tried making spherical grid planets before, and keep on wondering about the best compromises. Looking at the description, your version presumably has:
Certain blocks corresponding to the corners of the cube, where despite anti-distortion efforts the blocks will have one corner at 120° instead of 90°,
Triplets of blocks at these locations, where turning twice gets you back to the first block,
Blocks that get smaller as you mine down, and then suddenly double in size,
Somewhere, down at the core, a regular polyhedron (what shape is it? Must be a cube) made of pyramid blocks that all come to a point in the center.
OK who's fucking downvoting me for thinking about geometry? If one of these assumptions isn't true, go ahead and tell me.
reply
crazygringo 11 hours ago | parent | next [–]
I didn't downvote you, but you're just repeating what's in the article. And you say "presumably" so it sounds like you're guessing without fully reading? Which isn't adding anything to the conversation.
reply
card_zero 11 hours ago | root | parent | next [–]
I think only the part about blocks getting smaller as you go down and then doubling in size again is in the article. Will check.
I'm saying "presumably" because of points the article didn't spell out. Edit: I re-read and it doesn't talk about the very much non-cuboid blocks at the corners, or the pointed blocks at the core. Not in words, anyway. They're implied in the pictures.
If you want comments that build on this ... it's the triplets of quads that really bother me. They only appear at eight places on the surface of the planet, but it would mess with strategy in a strategy game (my own efforts were inspired by trying to create Civ on a true sphere) if routes between tiles are sometimes short-circuited. It would also distort house architecture in a sims-like, and mess up city grids if one of these triplet corners happens to be in the middle of your city, which would then go from having north-south and east-west streets to having ... six cardinal directions?
reply
crazygringo 10 hours ago | root | parent | next [–]
They do mention it:
> When it comes to placing block structures, there are two (2) edge cases that can throw a wrench into things:
> 1. The corners where three (3) sectors meet break the regular horizontal grid topology, since three (3) blocks meet at the corner instead of four (4)
> 2. Vertical shell boundaries break the regular vertical grid topology, since a block can have four (4) vertical neighbors instead of just one (1)
> This means that there are places on our planet where it’s impossible to define a box-shaped zone of blocks that corresponds to the block structure’s source zone. I could just detect and prevent structures from being placed at these locations, but I opted for a more general solution.
> Placing structures will now “work” everywhere, though it can get a little wonky around the problematic areas. Still, I prefer this to having dead zones where no structures can be placed at all.
reply
card_zero 10 hours ago | root | parent | next [–]
I am pressed for time now, so I'll just say thank you. Gotta rush off ...
reply
lloydatkinson 15 hours ago | prev | next [–]
Press E and Q for some lasers
reply
s0a 14 hours ago | prev | next [–]
how about making the player smaller as you get closer to the core? then each layer would be the same. there would be no seams where layers double/halve.
reply
scotty79 9 hours ago | prev | next [–]
Instead of having weird 8 points in the world where 3 instead of 4 quads meet at a vertex, for minecraft like game it would make more sense to have barrel-like mapping with ice caps being weird zones where you can't build on or you transition from barrel mapping to flat mapping for ice caps, so you have unbuildable ring just on the ice boundary.
reply
lstodd 9 hours ago | prev | next [–]
on a tangential note I once tried to get pathfinding working on a rhombic dodecahedral honeycomb feeling as regular 3-ish level octtree Dwarf Fortress of 2014-ish vintage was insufficiently weird.
this did not end well, but was hilarious. just to visualise the stuff I had to spend a week gluing cardboard rhombododecahedrons from pizza boxes.
what I learned is that they make much more fun toys than plain old cubes.
and that shallow sparse octtree-like things are in fact better for those kind of games (or GIS for that matter).
reply
jaybrendansmith 16 hours ago | prev | next [–]
This looks so cool
reply
scotty79 10 hours ago | prev | next [–]
Could you just cheat and render part of larger square map (with top wrapped to bottom and left wrapped to right) inside a circle and deform it so it just gives illusion but isn't really a sphere?
Quick experiments in blender show me that you can create a cube, then use subdivision modifier to get a fake sphere like the one in the article. Then put camera close to the surface and give it very low focal length. This way it looks like a sphere but the strange points where 3 quads meet are way out of the view so I basically see just one face of 6 sided sphere.
If I now textured this side so that it displays roughly 50% of the square texture containing the world map and scrolled and rotated the texture as I try to "rotate" the sphere I should pretty much not be able tell it from a real sphere but have a 100% normal 2d square Minecraft grid on top of it.
It looks quite nice, even and natural:
https://postimg.cc/XXNgCYF8
Texturing is a bit weird because polar caps are just two regions of the world with stuff in between them in all directions so you need to put them at the right distance and size them properly so they show up. And even then they disappear as you rotate the world by scrolling in W-E direction. To make them visible at all times, you'd need to make them half of your world. Which might be fine for your game to have vast, icy biome connecting north and south of your planet. Or even two separate zones of the planet separated by northern and southern walls of ice.
https://postimg.cc/34GCKkDj
I'm not sure how well lightning is going to work with such low focal length but it might be fine.
https://postimg.cc/ThGWyN8v
reply
scotty79 11 hours ago | prev | next [–]
Why can't you cover spherical surface with quads so that 4 lines meet at every vertex? How would the proof of that look?
reply
crazygringo 11 hours ago | parent | next [–]
> If you want only quadrilaterals, and you want most vertices to be a meeting between 4 quadrilaterals, but some places 3 quadrilaterals meet, you can use the Euler characteristic to deduce that there must be 8 of these degenerate vertices.
https://math.stackexchange.com/a/4904806
reply
fritzo 12 hours ago | prev | next [–]
A torus would have been easier.
reply
bobsmooth 14 hours ago | prev | next [–]
I like the shader you used for the core.
reply
jiggawatts 4 hours ago | prev [–]
Another game that allows building on spherical surfaces is Dyson Sphere Program: https://store.steampowered.com/app/1366540/Dyson_Sphere_Prog...
reply
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Search:
identifier:6441
model:gemini-2.5-flash| input-price: 0.3 output-price: 2.5 max-context-length: 128_000
host:194.230.161.72
https://www.youtube.com/watch?v=nHBgc_oNfQwinclude_comments:None
include_timestamps:1
include_glossary:None
output_language:en
cost:0.005699999999999999
*Abstract:* This video introduces "diffuse clock," a novel AI animation technique designed to overcome the limitations of current methods, which often force a trade-off between physical realism and controllability. Traditional animation is labor-intensive, while existing AI approaches either produce unrealistic motion when controllable or lack control when realistic. Diffuse clock is presented as a "best of both worlds" solution, generating controllable and physically viable character movements from a "soup" of motion-captured data. Its capabilities include static and dynamic obstacle avoidance, handling long animation sequences, demonstrating strong generalization to unseen scenarios (e.g., multi-pillar jumping from ground-jump training), generating motion between specified poses, and exhibiting robustness against physical perturbations. The system operates via a learned anticipatory rhythm, seamlessly weaving states and actions. Notably, it supports zero-shot learning, requiring no retraining or task-specific tuning, and can be trained efficiently on a single GPU in 24 hours, paving the way for naturally moving game characters, VR avatars, and robots. *Summarizing "Diffuse Clock": A Breakthrough in Controllable, Realistic AI Animation* * *0:03 The Core Problem in AI Animation:* Existing AI animation techniques suffer from a critical trade-off: methods that are controllable often produce physically unrealistic motion, while realistic methods are difficult to control. * *0:34 AI's Potential and Current Limitations:* While AI can learn to weave motion-captured animations together, current controllable techniques frequently fail to create physically viable motion, and realistic ones lack easy control. * *1:02 Introducing "Diffuse Clock":* A new AI animation method is presented, dubbed "diffuse clock," which promises to deliver both controllable and realistic character motion from a dataset of movements. * *1:22 Key Feature 1: Static Obstacle Avoidance:* The technique allows animated characters to naturally avoid static obstacles like walls. * *1:28 Key Feature 2: Dynamic Obstacle Avoidance:* Characters can also avoid collisions with other moving AI entities in dynamic environments. * *1:42 Key Feature 3: Long Animation Sequences:* The method is effective for generating extended and complex animation sequences. * *1:46 Key Feature 4: Powerful Generalization:* A significant capability is the AI's ability to generalize, performing actions in new situations it hasn't explicitly seen (e.g., jumping multiple pillars after only being trained on ground jumps). * *2:12 Key Feature 5: Multi-Pose Specification:* Unlike most other diffusion-based AI techniques, diffuse clock can generate motion between two or more user-specified poses. * *2:23 Key Feature 6: Perturbation Resistance:* The characters generated by diffuse clock are notably resistant to physical disruptions, maintaining their intended movement even when interfered with. * *3:00 The Magic Behind Diffuse Clock:* The AI learns by anticipating future movements, akin to a dancer feeling the rhythm ahead, allowing it to improvise gracefully and seamlessly weave states and actions together. * *3:56 Efficient Training:* The model can be trained on a single GPU in just 24 hours, making it highly accessible and practical. * *4:06 Zero-Shot Learning:* A major takeaway is that the model uses "zero-shot" learning, meaning it requires no retraining or task-specific tuning for new environments or challenges. * *4:21 Diverse Applications:* The technique holds immense potential for creating naturally moving game characters, realistic VR avatars, and even for controlling robots. I used gemini-2.5-flash| input-price: 0.3 output-price: 2.5 max-context-length: 128_000 on rocketrecap dot com to summarize the transcript. Cost (if I didn't use the free tier): $0.0057 Input tokens: 12750 Output tokens: 750
Abstract:
This video introduces "diffuse clock," a novel AI animation technique designed to overcome the limitations of current methods, which often force a trade-off between physical realism and controllability. Traditional animation is labor-intensive, while existing AI approaches either produce unrealistic motion when controllable or lack control when realistic. Diffuse clock is presented as a "best of both worlds" solution, generating controllable and physically viable character movements from a "soup" of motion-captured data. Its capabilities include static and dynamic obstacle avoidance, handling long animation sequences, demonstrating strong generalization to unseen scenarios (e.g., multi-pillar jumping from ground-jump training), generating motion between specified poses, and exhibiting robustness against physical perturbations. The system operates via a learned anticipatory rhythm, seamlessly weaving states and actions. Notably, it supports zero-shot learning, requiring no retraining or task-specific tuning, and can be trained efficiently on a single GPU in 24 hours, paving the way for naturally moving game characters, VR avatars, and robots.
Summarizing "Diffuse Clock": A Breakthrough in Controllable, Realistic AI Animation
Below, I will provide input for an example video (comprising of title, description, and transcript, in this order) and the corresponding abstract and summary I expect. Afterward, I will provide a new transcript that I want you to summarize in the same format.
**Please give an abstract of the transcript and then summarize the transcript in a self-contained bullet list format.** Include starting timestamps, important details and key takeaways.
Example Input:
Fluidigm Polaris Part 2- illuminator and camera
mikeselectricstuff
131K subscribers
Subscribed
369
Share
Download
Clip
Save
5,857 views Aug 26, 2024
Fluidigm Polaris part 1 : • Fluidigm Polaris (Part 1) - Biotech g...
Ebay listings: https://www.ebay.co.uk/usr/mikeselect...
Merch https://mikeselectricstuff.creator-sp...
Transcript
Follow along using the transcript.
Show transcript
mikeselectricstuff
131K subscribers
Videos
About
Support on Patreon
40 Comments
@robertwatsonbath
6 hours ago
Thanks Mike. Ooof! - with the level of bodgery going on around 15:48 I think shame would have made me do a board re spin, out of my own pocket if I had to.
1
Reply
@Muonium1
9 hours ago
The green LED looks different from the others and uses phosphor conversion because of the "green gap" problem where green InGaN emitters suffer efficiency droop at high currents. Phosphide based emitters don't start becoming efficient until around 600nm so also can't be used for high power green emitters. See the paper and plot by Matthias Auf der Maur in his 2015 paper on alloy fluctuations in InGaN as the cause of reduced external quantum efficiency at longer (green) wavelengths.
4
Reply
1 reply
@tafsirnahian669
10 hours ago (edited)
Can this be used as an astrophotography camera?
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
6 hours ago
Yes, but may need a shutter to avoid light during readout
Reply
@2010craggy
11 hours ago
Narrowband filters we use in Astronomy (Astrophotography) are sided- they work best passing light in one direction so I guess the arrows on the filter frames indicate which way round to install them in the filter wheel.
1
Reply
@vitukz
12 hours ago
A mate with Channel @extractions&ire could use it
2
Reply
@RobertGallop
19 hours ago
That LED module says it can go up to 28 amps!!! 21 amps for 100%. You should see what it does at 20 amps!
Reply
@Prophes0r
19 hours ago
I had an "Oh SHIT!" moment when I realized that the weird trapezoidal shape of that light guide was for keystone correction of the light source.
Very clever.
6
Reply
@OneBiOzZ
20 hours ago
given the cost of the CCD you think they could have run another PCB for it
9
Reply
@tekvax01
21 hours ago
$20 thousand dollars per minute of run time!
1
Reply
@tekvax01
22 hours ago
"We spared no expense!" John Hammond Jurassic Park.
*(that's why this thing costs the same as a 50-seat Greyhound Bus coach!)
Reply
@florianf4257
22 hours ago
The smearing on the image could be due to the fact that you don't use a shutter, so you see brighter stripes under bright areas of the image as you still iluminate these pixels while the sensor data ist shifted out towards the top. I experienced this effect back at university with a LN-Cooled CCD for Spectroscopy. The stripes disapeared as soon as you used the shutter instead of disabling it in the open position (but fokussing at 100ms integration time and continuous readout with a focal plane shutter isn't much fun).
12
Reply
mikeselectricstuff
·
1 reply
@mikeselectricstuff
12 hours ago
I didn't think of that, but makes sense
2
Reply
@douro20
22 hours ago (edited)
The red LED reminds me of one from Roithner Lasertechnik. I have a Symbol 2D scanner which uses two very bright LEDs from that company, one red and one red-orange. The red-orange is behind a lens which focuses it into an extremely narrow beam.
1
Reply
@RicoElectrico
23 hours ago
PFG is Pulse Flush Gate according to the datasheet.
Reply
@dcallan812
23 hours ago
Very interesting. 2x
Reply
@littleboot_
1 day ago
Cool interesting device
Reply
@dav1dbone
1 day ago
I've stripped large projectors, looks similar, wonder if some of those castings are a magnesium alloy?
Reply
@kevywevvy8833
1 day ago
ironic that some of those Phlatlight modules are used in some of the cheapest disco lights.
1
Reply
1 reply
@bill6255
1 day ago
Great vid - gets right into subject in title, its packed with information, wraps up quickly. Should get a YT award! imho
3
Reply
@JAKOB1977
1 day ago (edited)
The whole sensor module incl. a 5 grand 50mpix sensor for 49 £.. highest bid atm
Though also a limited CCD sensor, but for the right buyer its a steal at these relative low sums.
Architecture Full Frame CCD (Square Pixels)
Total Number of Pixels 8304 (H) × 6220 (V) = 51.6 Mp
Number of Effective Pixels 8208 (H) × 6164 (V) = 50.5 Mp
Number of Active Pixels 8176 (H) × 6132 (V) = 50.1 Mp
Pixel Size 6.0 m (H) × 6.0 m (V)
Active Image Size 49.1 mm (H) × 36.8 mm (V)
61.3 mm (Diagonal),
645 1.1x Optical Format
Aspect Ratio 4:3
Horizontal Outputs 4
Saturation Signal 40.3 ke−
Output Sensitivity 31 V/e−
Quantum Efficiency
KAF−50100−CAA
KAF−50100−AAA
KAF−50100−ABA (with Lens)
22%, 22%, 16% (Peak R, G, B)
25%
62%
Read Noise (f = 18 MHz) 12.5 e−
Dark Signal (T = 60°C) 42 pA/cm2
Dark Current Doubling Temperature 5.7°C
Dynamic Range (f = 18 MHz) 70.2 dB
Estimated Linear Dynamic Range
(f = 18 MHz)
69.3 dB
Charge Transfer Efficiency
Horizontal
Vertical
0.999995
0.999999
Blooming Protection
(4 ms Exposure Time)
800X Saturation Exposure
Maximum Date Rate 18 MHz
Package Ceramic PGA
Cover Glass MAR Coated, 2 Sides or
Clear Glass
Features
• TRUESENSE Transparent Gate Electrode
for High Sensitivity
• Ultra-High Resolution
• Board Dynamic Range
• Low Noise Architecture
• Large Active Imaging Area
Applications
• Digitization
• Mapping/Aerial
• Photography
• Scientific
Thx for the tear down Mike, always a joy
Reply
@martinalooksatthings
1 day ago
15:49 that is some great bodging on of caps, they really didn't want to respin that PCB huh
8
Reply
@RhythmGamer
1 day ago
Was depressed today and then a new mike video dropped and now I’m genuinely happy to get my tear down fix
1
Reply
@dine9093
1 day ago (edited)
Did you transfrom into Mr Blobby for a moment there?
2
Reply
@NickNorton
1 day ago
Thanks Mike. Your videos are always interesting.
5
Reply
@KeritechElectronics
1 day ago
Heavy optics indeed... Spare no expense, cost no object. Splendid build quality. The CCD is a thing of beauty!
1
Reply
@YSoreil
1 day ago
The pricing on that sensor is about right, I looked in to these many years ago when they were still in production since it's the only large sensor you could actually buy. Really cool to see one in the wild.
2
Reply
@snik2pl
1 day ago
That leds look like from led projector
Reply
@vincei4252
1 day ago
TDI = Time Domain Integration ?
1
Reply
@wolpumba4099
1 day ago (edited)
Maybe the camera should not be illuminated during readout.
From the datasheet of the sensor (Onsemi): saturation 40300 electrons, read noise 12.5 electrons per pixel @ 18MHz (quite bad). quantum efficiency 62% (if it has micro lenses), frame rate 1 Hz. lateral overflow drain to prevent blooming protects against 800x (factor increases linearly with exposure time) saturation exposure (32e6 electrons per pixel at 4ms exposure time), microlens has +/- 20 degree acceptance angle
i guess it would be good for astrophotography
4
Reply
@txm100
1 day ago (edited)
Babe wake up a new mikeselectricstuff has dropped!
9
Reply
@vincei4252
1 day ago
That looks like a finger-lakes filter wheel, however, for astronomy they'd never use such a large stepper.
1
Reply
@MRooodddvvv
1 day ago
yaaaaay ! more overcomplicated optical stuff !
4
Reply
1 reply
@NoPegs
1 day ago
He lives!
11
Reply
1 reply
Transcript
0:00
so I've stripped all the bits of the
0:01
optical system so basically we've got
0:03
the uh the camera
0:05
itself which is mounted on this uh very
0:09
complex
0:10
adjustment thing which obviously to set
0:13
you the various tilt and uh alignment
0:15
stuff then there's two of these massive
0:18
lenses I've taken one of these apart I
0:20
think there's something like about eight
0:22
or nine Optical elements in here these
0:25
don't seem to do a great deal in terms
0:26
of electr magnification they're obiously
0:28
just about getting the image to where it
0:29
uh where it needs to be just so that
0:33
goes like that then this Optical block I
0:36
originally thought this was made of some
0:37
s crazy heavy material but it's just
0:39
really the sum of all these Optical bits
0:41
are just ridiculously heavy those lenses
0:43
are about 4 kilos each and then there's
0:45
this very heavy very solid um piece that
0:47
goes in the middle and this is so this
0:49
is the filter wheel assembly with a
0:51
hilariously oversized steper
0:53
motor driving this wheel with these very
0:57
large narrow band filters so we've got
1:00
various different shades of uh
1:03
filters there five Al together that
1:06
one's actually just showing up a silver
1:07
that's actually a a red but fairly low
1:10
transmission orangey red blue green
1:15
there's an excess cover on this side so
1:16
the filters can be accessed and changed
1:19
without taking anything else apart even
1:21
this is like ridiculous it's like solid
1:23
aluminium this is just basically a cover
1:25
the actual wavelengths of these are um
1:27
488 525 570 630 and 700 NM not sure what
1:32
the suffix on that perhaps that's the uh
1:34
the width of the spectral line say these
1:37
are very narrow band filters most of
1:39
them are you very little light through
1:41
so it's still very tight narrow band to
1:43
match the um fluoresence of the dies
1:45
they're using in the biochemical process
1:48
and obviously to reject the light that's
1:49
being fired at it from that Illuminator
1:51
box and then there's a there's a second
1:53
one of these lenses then the actual sort
1:55
of samples below that so uh very serious
1:58
amount of very uh chunky heavy Optics
2:01
okay let's take a look at this light
2:02
source made by company Lumen Dynamics
2:04
who are now part of
2:06
excelitas self-contained unit power
2:08
connector USB and this which one of the
2:11
Cable Bundle said was a TTL interface
2:14
USB wasn't used in uh the fluid
2:17
application output here and I think this
2:19
is an input for um light feedback I
2:21
don't if it's regulated or just a measur
2:23
measurement facility and the uh fiber
2:27
assembly
2:29
Square Inlet there and then there's two
2:32
outputs which have uh lens assemblies
2:35
and this small one which goes back into
2:37
that small Port just Loops out of here
2:40
straight back in So on this side we've
2:42
got the electronics which look pretty
2:44
straightforward we've got a bit of power
2:45
supply stuff over here and we've got
2:48
separate drivers for each wavelength now
2:50
interesting this is clearly been very
2:52
specifically made for this application
2:54
you I was half expecting like say some
2:56
generic drivers that could be used for a
2:58
number of different things but actually
3:00
literally specified the exact wavelength
3:02
on the PCB there is provision here for
3:04
385 NM which isn't populated but this is
3:07
clearly been designed very specifically
3:09
so these four drivers look the same but
3:10
then there's two higher power ones for
3:12
575 and
3:14
520 a slightly bigger heat sink on this
3:16
575 section there a p 24 which is
3:20
providing USB interface USB isolator the
3:23
USB interface just presents as a comport
3:26
I did have a quick look but I didn't
3:27
actually get anything sensible um I did
3:29
dump the Pi code out and there's a few
3:31
you a few sort of commands that you
3:32
could see in text but I didn't actually
3:34
manage to get it working properly I
3:36
found some software for related version
3:38
but it didn't seem to want to talk to it
3:39
but um I say that wasn't used for the
3:41
original application it might be quite
3:42
interesting to get try and get the Run
3:44
hours count out of it and the TTL
3:46
interface looks fairly straightforward
3:48
we've got positions for six opto
3:50
isolators but only five five are
3:52
installed so that corresponds with the
3:54
unused thing so I think this hopefully
3:56
should be as simple as just providing a
3:57
ttrl signal for each color to uh enable
4:00
it a big heat sink here which is there I
4:03
think there's like a big S of metal
4:04
plate through the middle of this that
4:05
all the leads are mounted on the other
4:07
side so this is heat sinking it with a
4:09
air flow from a uh just a fan in here
4:13
obviously don't have the air flow
4:14
anywhere near the Optics so conduction
4:17
cool through to this plate that's then
4:18
uh air cooled got some pots which are
4:21
presumably power
4:22
adjustments okay let's take a look at
4:24
the other side which is uh much more
4:27
interesting see we've got some uh very
4:31
uh neatly Twisted cable assemblies there
4:35
a bunch of leads so we've got one here
4:37
475 up here 430 NM 630 575 and 520
4:44
filters and dcro mirrors a quick way to
4:48
see what's white is if we just shine
4:49
some white light through
4:51
here not sure how it is is to see on the
4:54
camera but shining white light we do
4:55
actually get a bit of red a bit of blue
4:57
some yellow here so the obstacle path
5:00
575 it goes sort of here bounces off
5:03
this mirror and goes out the 520 goes
5:07
sort of down here across here and up
5:09
there 630 goes basically straight
5:13
through
5:15
430 goes across there down there along
5:17
there and the 475 goes down here and
5:20
left this is the light sensing thing
5:22
think here there's just a um I think
5:24
there a photo diode or other sensor
5:26
haven't actually taken that off and
5:28
everything's fixed down to this chunk of
5:31
aluminium which acts as the heat
5:32
spreader that then conducts the heat to
5:33
the back side for the heat
5:35
sink and the actual lead packages all
5:38
look fairly similar except for this one
5:41
on the 575 which looks quite a bit more
5:44
substantial big spay
5:46
Terminals and the interface for this
5:48
turned out to be extremely simple it's
5:50
literally a 5V TTL level to enable each
5:54
color doesn't seem to be any tensity
5:56
control but there are some additional
5:58
pins on that connector that weren't used
5:59
in the through time thing so maybe
6:01
there's some extra lines that control
6:02
that I couldn't find any data on this uh
6:05
unit and the um their current product
6:07
range is quite significantly different
6:09
so we've got the uh blue these
6:13
might may well be saturating the camera
6:16
so they might look a bit weird so that's
6:17
the 430
6:18
blue the 575
6:24
yellow uh
6:26
475 light blue
6:29
the uh 520
6:31
green and the uh 630 red now one
6:36
interesting thing I noticed for the
6:39
575 it's actually it's actually using a
6:42
white lead and then filtering it rather
6:44
than using all the other ones are using
6:46
leads which are the fundamental colors
6:47
but uh this is actually doing white and
6:50
it's a combination of this filter and
6:52
the dichroic mirrors that are turning to
6:55
Yellow if we take the filter out and a
6:57
lot of the a lot of the um blue content
7:00
is going this way the red is going
7:02
straight through these two mirrors so
7:05
this is clearly not reflecting much of
7:08
that so we end up with the yellow coming
7:10
out of uh out of there which is a fairly
7:14
light yellow color which you don't
7:16
really see from high intensity leads so
7:19
that's clearly why they've used the
7:20
white to uh do this power consumption of
7:23
the white is pretty high so going up to
7:25
about 2 and 1 half amps on that color
7:27
whereas most of the other colors are
7:28
only drawing half an amp or so at 24
7:30
volts the uh the green is up to about
7:32
1.2 but say this thing is uh much
7:35
brighter and if you actually run all the
7:38
colors at the same time you get a fairly
7:41
reasonable um looking white coming out
7:43
of it and one thing you might just be
7:45
out to notice is there is some sort
7:46
color banding around here that's not
7:49
getting uh everything s completely
7:51
concentric and I think that's where this
7:53
fiber optic thing comes
7:58
in I'll
8:00
get a couple of Fairly accurately shaped
8:04
very sort of uniform color and looking
8:06
at What's um inside here we've basically
8:09
just got this Square Rod so this is
8:12
clearly yeah the lights just bouncing
8:13
off all the all the various sides to um
8:16
get a nice uniform illumination uh this
8:19
back bit looks like it's all potted so
8:21
nothing I really do to get in there I
8:24
think this is fiber so I have come
8:26
across um cables like this which are
8:27
liquid fill but just looking through the
8:30
end of this it's probably a bit hard to
8:31
see it does look like there fiber ends
8:34
going going on there and so there's this
8:36
feedback thing which is just obviously
8:39
compensating for the any light losses
8:41
through here to get an accurate
8:43
representation of uh the light that's
8:45
been launched out of these two
8:47
fibers and you see uh
8:49
these have got this sort of trapezium
8:54
shape light guides again it's like a
8:56
sort of acrylic or glass light guide
9:00
guess projected just to make the right
9:03
rectangular
9:04
shape and look at this Center assembly
9:07
um the light output doesn't uh change
9:10
whether you feed this in or not so it's
9:11
clear not doing any internal Clos Loop
9:14
control obviously there may well be some
9:16
facility for it to do that but it's not
9:17
being used in this
9:19
application and so this output just
9:21
produces a voltage on the uh outle
9:24
connector proportional to the amount of
9:26
light that's present so there's a little
9:28
diffuser in the back there
9:30
and then there's just some kind of uh
9:33
Optical sensor looks like a
9:35
chip looking at the lead it's a very
9:37
small package on the PCB with this lens
9:40
assembly over the top and these look
9:43
like they're actually on a copper
9:44
Metalized PCB for maximum thermal
9:47
performance and yeah it's a very small
9:49
package looks like it's a ceramic
9:51
package and there's a thermister there
9:53
for temperature monitoring this is the
9:56
475 blue one this is the 520 need to
9:59
Green which is uh rather different OB
10:02
it's a much bigger D with lots of bond
10:04
wise but also this looks like it's using
10:05
a phosphor if I shine a blue light at it
10:08
lights up green so this is actually a
10:10
phosphor conversion green lead which
10:12
I've I've come across before they want
10:15
that specific wavelength so they may be
10:17
easier to tune a phosphor than tune the
10:20
um semiconductor material to get the uh
10:23
right right wavelength from the lead
10:24
directly uh red 630 similar size to the
10:28
blue one or does seem to have a uh a
10:31
lens on top of it there is a sort of red
10:33
coloring to
10:35
the die but that doesn't appear to be
10:38
fluorescent as far as I can
10:39
tell and the white one again a little
10:41
bit different sort of much higher
10:43
current
10:46
connectors a makeer name on that
10:48
connector flot light not sure if that's
10:52
the connector or the lead
10:54
itself and obviously with the phosphor
10:56
and I'd imagine that phosphor may well
10:58
be tuned to get the maximum to the uh 5
11:01
cenm and actually this white one looks
11:04
like a St fairly standard product I just
11:06
found it in Mouse made by luminous
11:09
devices in fact actually I think all
11:11
these are based on various luminous
11:13
devices modules and they're you take
11:17
looks like they taking the nearest
11:18
wavelength and then just using these
11:19
filters to clean it up to get a precise
11:22
uh spectral line out of it so quite a
11:25
nice neat and um extreme
11:30
bright light source uh sure I've got any
11:33
particular use for it so I think this
11:35
might end up on
11:36
eBay but uh very pretty to look out and
11:40
without the uh risk of burning your eyes
11:43
out like you do with lasers so I thought
11:45
it would be interesting to try and
11:46
figure out the runtime of this things
11:48
like this we usually keep some sort
11:49
record of runtime cuz leads degrade over
11:51
time I couldn't get any software to work
11:52
through the USB face but then had a
11:54
thought probably going to be writing the
11:55
runtime periodically to the e s prom so
11:58
I just just scope up that and noticed it
12:00
was doing right every 5 minutes so I
12:02
just ran it for a while periodically
12:04
reading the E squ I just held the pick
12:05
in in reset and um put clip over to read
12:07
the square prom and found it was writing
12:10
one location per color every 5 minutes
12:12
so if one color was on it would write
12:14
that location every 5 minutes and just
12:16
increment it by one so after doing a few
12:18
tests with different colors of different
12:19
time periods it looked extremely
12:21
straightforward it's like a four bite
12:22
count for each color looking at the
12:24
original data that was in it all the
12:26
colors apart from Green were reading
12:28
zero and the green was reading four
12:30
indicating a total 20 minutes run time
12:32
ever if it was turned on run for a short
12:34
time then turned off that might not have
12:36
been counted but even so indicates this
12:37
thing wasn't used a great deal the whole
12:40
s process of doing a run can be several
12:42
hours but it'll only be doing probably
12:43
the Imaging at the end of that so you
12:46
wouldn't expect to be running for a long
12:47
time but say a single color for 20
12:50
minutes over its whole lifetime does
12:52
seem a little bit on the low side okay
12:55
let's look at the camera un fortunately
12:57
I managed to not record any sound when I
12:58
did this it's also a couple of months
13:00
ago so there's going to be a few details
13:02
that I've forgotten so I'm just going to
13:04
dub this over the original footage so um
13:07
take the lid off see this massive great
13:10
heat sink so this is a pel cool camera
13:12
we've got this blower fan producing a
13:14
fair amount of air flow through
13:16
it the connector here there's the ccds
13:19
mounted on the board on the
13:24
right this unplugs so we've got a bit of
13:27
power supply stuff on here
13:29
USB interface I think that's the Cyprus
13:32
microcontroller High speeded USB
13:34
interface there's a zyink spon fpga some
13:40
RAM and there's a couple of ATD
13:42
converters can't quite read what those
13:45
those are but anal
13:47
devices um little bit of bodgery around
13:51
here extra decoupling obviously they
13:53
have having some noise issues this is
13:55
around the ram chip quite a lot of extra
13:57
capacitors been added there
13:59
uh there's a couple of amplifiers prior
14:01
to the HD converter buffers or Andor
14:05
amplifiers taking the CCD
14:08
signal um bit more power spy stuff here
14:11
this is probably all to do with
14:12
generating the various CCD bias voltages
14:14
they uh need quite a lot of exotic
14:18
voltages next board down is just a
14:20
shield and an interconnect
14:24
boardly shielding the power supply stuff
14:26
from some the more sensitive an log
14:28
stuff
14:31
and this is the bottom board which is
14:32
just all power supply
14:34
stuff as you can see tons of capacitors
14:37
or Transformer in
14:42
there and this is the CCD which is a uh
14:47
very impressive thing this is a kf50 100
14:50
originally by true sense then codec
14:53
there ON
14:54
Semiconductor it's 50 megapixels uh the
14:58
only price I could find was this one
15:00
5,000 bucks and the architecture you can
15:03
see there actually two separate halves
15:04
which explains the Dual AZ converters
15:06
and two amplifiers it's literally split
15:08
down the middle and duplicated so it's
15:10
outputting two streams in parallel just
15:13
to keep the bandwidth sensible and it's
15:15
got this amazing um diffraction effects
15:18
it's got micro lenses over the pixel so
15:20
there's there's a bit more Optics going
15:22
on than on a normal
15:25
sensor few more bodges on the CCD board
15:28
including this wire which isn't really
15:29
tacked down very well which is a bit uh
15:32
bit of a mess quite a few bits around
15:34
this board where they've uh tacked
15:36
various bits on which is not super
15:38
impressive looks like CCD drivers on the
15:40
left with those 3 ohm um damping
15:43
resistors on the
15:47
output get a few more little bodges
15:50
around here some of
15:52
the and there's this separator the
15:54
silica gel to keep the moisture down but
15:56
there's this separator that actually
15:58
appears to be cut from piece of
15:59
antistatic
16:04
bag and this sort of thermal block on
16:06
top of this stack of three pel Cola
16:12
modules so as with any Stacks they get
16:16
um larger as they go back towards the
16:18
heat sink because each P's got to not
16:20
only take the heat from the previous but
16:21
also the waste heat which is quite
16:27
significant you see a little temperature
16:29
sensor here that copper block which
16:32
makes contact with the back of the
16:37
CCD and this's the back of the
16:40
pelas this then contacts the heat sink
16:44
on the uh rear there a few thermal pads
16:46
as well for some of the other power
16:47
components on this
16:51
PCB okay I've connected this uh camera
16:54
up I found some drivers on the disc that
16:56
seem to work under Windows 7 couldn't
16:58
get to install under Windows 11 though
17:01
um in the absence of any sort of lens or
17:03
being bothered to the proper amount I've
17:04
just put some f over it and put a little
17:06
pin in there to make a pinhole lens and
17:08
software gives a few options I'm not
17:11
entirely sure what all these are there's
17:12
obviously a clock frequency 22 MHz low
17:15
gain and with PFG no idea what that is
17:19
something something game programmable
17:20
Something game perhaps ver exposure
17:23
types I think focus is just like a
17:25
continuous grab until you tell it to
17:27
stop not entirely sure all these options
17:30
are obviously exposure time uh triggers
17:33
there ex external hardware trigger inut
17:35
you just trigger using a um thing on
17:37
screen so the resolution is 8176 by
17:40
6132 and you can actually bin those
17:42
where you combine multiple pixels to get
17:46
increased gain at the expense of lower
17:48
resolution down this is a 10sec exposure
17:51
obviously of the pin hole it's very uh
17:53
intensitive so we just stand still now
17:56
downloading it there's the uh exposure
17:59
so when it's
18:01
um there's a little status thing down
18:03
here so that tells you the um exposure
18:07
[Applause]
18:09
time it's this is just it
18:15
downloading um it is quite I'm seeing
18:18
quite a lot like smearing I think that I
18:20
don't know whether that's just due to
18:21
pixels overloading or something else I
18:24
mean yeah it's not it's not um out of
18:26
the question that there's something not
18:27
totally right about this camera
18:28
certainly was bodge wise on there um I
18:31
don't I'd imagine a camera like this
18:32
it's got a fairly narrow range of
18:34
intensities that it's happy with I'm not
18:36
going to spend a great deal of time on
18:38
this if you're interested in this camera
18:40
maybe for astronomy or something and
18:42
happy to sort of take the risk of it may
18:44
not be uh perfect I'll um I think I'll
18:47
stick this on eBay along with the
18:48
Illuminator I'll put a link down in the
18:50
description to the listing take your
18:52
chances to grab a bargain so for example
18:54
here we see this vertical streaking so
18:56
I'm not sure how normal that is this is
18:58
on fairly bright scene looking out the
19:02
window if I cut the exposure time down
19:04
on that it's now 1 second
19:07
exposure again most of the image
19:09
disappears again this is looks like it's
19:11
possibly over still overloading here go
19:14
that go down to say say quarter a
19:16
second so again I think there might be
19:19
some Auto gain control going on here um
19:21
this is with the PFG option let's try
19:23
turning that off and see what
19:25
happens so I'm not sure this is actually
19:27
more streaking or which just it's
19:29
cranked up the gain all the dis display
19:31
gray scale to show what um you know the
19:33
range of things that it's captured
19:36
there's one of one of 12 things in the
19:38
software there's um you can see of you
19:40
can't seem to read out the temperature
19:42
of the pelta cooler but you can set the
19:44
temperature and if you said it's a
19:46
different temperature you see the power
19:48
consumption jump up running the cooler
19:50
to get the temperature you requested but
19:52
I can't see anything anywhere that tells
19:54
you whether the cool is at the at the
19:56
temperature other than the power
19:57
consumption going down and there's no
19:59
temperature read out
20:03
here and just some yeah this is just
20:05
sort of very basic software I'm sure
20:07
there's like an API for more
20:09
sophisticated
20:10
applications but so if you know anything
20:12
more about these cameras please um stick
20:14
in the
20:15
comments um incidentally when I was
20:18
editing I didn't notice there was a bent
20:19
pin on the um CCD but I did fix that
20:22
before doing these tests and also
20:24
reactivated the um silica gel desicant
20:26
cuz I noticed it was uh I was getting
20:28
bit of condensation on the window but um
20:31
yeah so a couple of uh interesting but
20:34
maybe not particularly uh useful pieces
20:37
of Kit except for someone that's got a
20:38
very specific use so um I'll stick a
20:42
I'll stick these on eBay put a link in
20:44
the description and say hopefully
20:45
someone could actually make some uh good
20:47
use of these things
Example Output:
**Abstract:**
This video presents Part 2 of a teardown focusing on the optical components of a Fluidigm Polaris biotechnology instrument, specifically the multi-wavelength illuminator and the high-resolution CCD camera.
The Lumen Dynamics illuminator unit is examined in detail, revealing its construction using multiple high-power LEDs (430nm, 475nm, 520nm, 575nm, 630nm) combined via dichroic mirrors and filters. A square fiber optic rod is used to homogenize the light. A notable finding is the use of a phosphor-converted white LED filtered to achieve the 575nm output. The unit features simple TTL activation for each color, conduction cooling, and internal homogenization optics. Analysis of its EEPROM suggests extremely low operational runtime.
The camera module teardown showcases a 50 Megapixel ON Semiconductor KAF-50100 CCD sensor with micro-lenses, cooled by a multi-stage Peltier stack. The control electronics include an FPGA and a USB interface. Significant post-manufacturing modifications ("bodges") are observed on the camera's circuit boards. Basic functional testing using vendor software and a pinhole lens confirms image capture but reveals prominent vertical streaking artifacts, the cause of which remains uncertain (potential overload, readout artifact, or fault).
**Exploring the Fluidigm Polaris: A Detailed Look at its High-End Optics and Camera System**
* **0:00 High-End Optics:** The system utilizes heavy, high-quality lenses and mirrors for precise imaging, weighing around 4 kilos each.
* **0:49 Narrow Band Filters:** A filter wheel with five narrow band filters (488, 525, 570, 630, and 700 nm) ensures accurate fluorescence detection and rejection of excitation light.
* **2:01 Customizable Illumination:** The Lumen Dynamics light source offers five individually controllable LED wavelengths (430, 475, 520, 575, 630 nm) with varying power outputs. The 575nm yellow LED is uniquely achieved using a white LED with filtering.
* **3:45 TTL Control:** The light source is controlled via a simple TTL interface, enabling easy on/off switching for each LED color.
* **12:55 Sophisticated Camera:** The system includes a 50-megapixel Kodak KAI-50100 CCD camera with a Peltier cooling system for reduced noise.
* **14:54 High-Speed Data Transfer:** The camera features dual analog-to-digital converters to manage the high data throughput of the 50-megapixel sensor, which is effectively two 25-megapixel sensors operating in parallel.
* **18:11 Possible Issues:** The video creator noted some potential issues with the camera, including image smearing.
* **18:11 Limited Dynamic Range:** The camera's sensor has a limited dynamic range, making it potentially challenging to capture scenes with a wide range of brightness levels.
* **11:45 Low Runtime:** Internal data suggests the system has seen minimal usage, with only 20 minutes of recorded runtime for the green LED.
* **20:38 Availability on eBay:** Both the illuminator and camera are expected to be listed for sale on eBay.
Here is the real transcript. Please summarize it:
00:00:03 Here is an animation technique that oh
00:00:03 no, what is going on here? This problem
00:00:05 is a bit like an orchestra with a genius
00:00:08 conductor, but the musicians are useless
00:00:11 inflatable tubemen. Okay, so we need a
00:00:14 new AI animation technique that we can
00:00:17 control properly. Now, I am not saying
00:00:20 that animated movie and video game
00:00:22 characters can't walk. Of course, they
00:00:24 can. Although not so sure about this
00:00:26 one. Now these classical animation
00:00:29 techniques are produced for every single
00:00:31 motion by an artist. However, AI based
00:00:34 techniques offer something incredible.
00:00:37 Just taking a soup of motion captured
00:00:39 animations and learning how to use them
00:00:42 and weave them together. But there is a
00:00:45 problem. The AI based animation
00:00:47 techniques that are controllable often
00:00:49 fail to create physically viable motion.
00:00:52 And there are ones that are realistic,
00:00:54 but those are unfortunately not easily
00:00:57 controllable. So, does this new
00:00:59 technique perform the impossible? Let's
00:01:02 see the intro sequence with the new
00:01:04 method called diffuse clock. And oh yes,
00:01:09 excellent. This is the best of both
00:01:12 worlds. Controllable realistic motion
00:01:14 from a soup of data. And here's the best
00:01:17 part. It can also do five other amazing
00:01:20 things, too. One, it can do static
00:01:23 obstacle avoidance, so it won't walk
00:01:26 into walls. That's a start. But now,
00:01:28 check this out. Dynamic avoidance, too,
00:01:31 where you put together a bunch of AI
00:01:33 people, and they hopefully won't bump
00:01:35 into each other when everyone is moving.
00:01:38 Let's see. Yep, I think this one checks
00:01:41 out. Two, it works for longer animation
00:01:44 sequences, too. Three, my favorite. Now,
00:01:47 hold on to your papers, fellow scholars.
00:01:49 For generalization, this character only
00:01:52 saw jumping sequences on the ground, but
00:01:55 now three pillars.
00:01:58 Let's see if it can do it. One, two,
00:02:01 three. Excellent. I think this really
00:02:04 highlights how powerful these learning
00:02:06 methods are. They can do things in ways
00:02:09 they haven't seen before. Amazing. Four,
00:02:12 it can specify two or more poses and it
00:02:15 will generate the motion between them.
00:02:18 This is not possible with most other
00:02:20 diffusion-based AI techniques. Five. Of
00:02:24 course, you can grab this character and
00:02:26 try to disrupt its movement. With
00:02:28 previous methods, this was H. Well, was
00:02:32 it fun? Yes, very fun. Was it disrupted?
00:02:36 Oh, yes. So, how did the new method do?
00:02:39 Now, as you see, it is not perfect. It
00:02:42 still looks a bit like someone who had a
00:02:45 couple drinks, but it is pretty
00:02:47 resistant to these perturbations. Loving
00:02:50 this. This is what we researchers do in
00:02:53 our work hours, and we call it work. And
00:02:55 we even get paid for this. Best job in
00:02:58 the world. And this is an incredible
00:03:00 leap forward. So, how is all this
00:03:02 possible? How did they do all this
00:03:04 magic? Dear fellow scholars, this is two
00:03:07 minute papers with Dr. Carola, Dr.
00:03:10 Carol. So remember, all this should work
00:03:12 from a bunch of unconnected input
00:03:15 motions. No information on how to weave
00:03:17 them together. No information on how to
00:03:20 use these in new situations. No
00:03:22 obstacles, no other people. This is all
00:03:25 learned behavior. And this new AI is
00:03:28 like teaching a dancer not just the
00:03:31 steps, but also how to feel the rhythm a
00:03:34 few seconds ahead. So every move already
00:03:37 anticipates what comes next. The dancer
00:03:40 isn't blindly following choreography
00:03:42 anymore. No, it can improvise while
00:03:45 staying graceful. That's exactly how
00:03:47 this system weaves states and actions
00:03:50 into one seamless motion. Absolutely
00:03:53 incredible. What a time to be alive. And
00:03:56 all this is trained on a single GPU in
00:04:00 24 hours. something you can easily do in
00:04:03 a Lambda instance and then run it
00:04:05 anywhere. And what excites me most is
00:04:07 that this is all zero shot. No
00:04:10 retraining, no task specific tuning.
00:04:13 Just one model that learns to walk
00:04:15 around walls, jump over obstacles, play
00:04:18 nice with others, and even respond to a
00:04:21 controller. Imagine game characters, VR
00:04:24 avatars, or robots that just move
00:04:26 naturally out of the box. And this is
00:04:29 only the beginning. Just imagine what we
00:04:32 will be able to do two more papers down
00:04:34 the line. My goodness. And I got to say,
00:04:37 I can't stop playing with OpenAI's Open
00:04:41 GPT model through Lambda GPU cloud. And
00:04:44 as you see, I am doing very useful
00:04:47 things with it for science. Yes, this is
00:04:50 actual speed. I can't believe that I can
00:04:52 have more than 100 billion parameters
00:04:55 running super super fast here. Many of
00:04:58 you fellow scholars are using it, and if
00:05:00 you don't, make sure to check it out. It
00:05:02 costs only a couple dollars per hour.
00:05:05 Insanity. You can rent an Nvidia GPU
00:05:08 through lambda.ai/papers AI/papers or