Noone has experienced 'zero gravity'

Gravity on a Space Station is roughly 90% of what it is on the Earth's surface, a far cry from 0! You and the Space Station are continuously falling together. Your sideways velocity is so high that you fall just as fast as the Earth curves with gravity always pulling sideways relative to your velocity. So in actuality astronauts have experienced perpetual falling without hitting the ground, not zero g.

You can't feel gravity directly, though you can feel it indirectly. such as your feet pushing against the Earth's surface as gravity tries to accelerate your body.

Calibrate faucet valves

Usually max fluid flow is achieve by say just a quarter or a half turn of the knob, opening the rest of the way does nothing. Typically with hot and cold valves opened to max. slowly closing cold to warm it up does nothing until you reach a certain threshold.

Properly calibrated would mean:
1/4 turn of the knob = 1/4 max fluid flow
1/2 turn of the knob = 1/2 max fluid flow
full turn of the knob = full max fluid flow

This will also give you more fine tuned control over the flow.

Musings on discernible display resolution (color and geometry) (part 2)

Something that I think is often overlooked: Some think that it's a total waste if you sit so far from a 4K 2160p display that 4 pixels effectively blend into 1 pixel, as far as the eye is concerned. So in essence it becomes a 2K 1080p display.

That's not the whole story.

Those 4 pixels color average, and that color averaging effectively quadruples the color depth. So instead of a 2160p 24bit color display, you now have a 1080p 30bit color display, and that's not too shabby from where I'm sitting (pun intended! ) Same idea with 8K: Imagine a 4320p 24bit color display, sit too far from that and it effectively becomes a 2160p 30bit color display. Sit even farther and it become a 1080p 36bit color display.

As you can see quadrupling the pixel resolution will quadruple the color resolution for those whom sit far away from the display. Correct me if I'm wrong, but 24->30 and 30->36 are both quadrupling, adding 2 bits to each of the 3 primary colors. It's still better to sit close and see all of the pixels, I'm just suggesting that it isn't a total loss sitting far from the display.

You could have 1 bit per primary color per pixel and that would suffice if you had an enormous number of pixels giving you full res and full color depth that the eye can discern. Not practical of course, but just for illustrative purposes.

Musings on discernible display resolution (color and geometry)

Abbreviations
Smallest Discernible Solid Angle (SDSA): 0.01x0.01deg FOV. This is approximately the smallest area a human eye can discern.

Quadruple color resolution
Ideally 1 pixel would take up 1 SDSA, however, if a square of 4 pixels takes up 1 SDSA it is not entirely wasteful. Those pixels would color average together, effectively quadrupling the color resolution. For example, instead of just color steps of 4, you now have color steps of 1.

Increased pixel density requires more color depth
Generally the closer spots are on a surface the less color difference there is. Now with 8.3 megapixel displays this is very important. To be able to express this color difference, high color resolution is required (30bit or 36bit instead of just 24bit.) Otherwise those pixels would look the same and blend into apparent larger pixels. Also contrast (difference between lowest to highest brightness) is important, it must be high enough so that humans can detect the difference.

Thoughts on pass through augmented reality

Pass-through augmented reality (AR) without actually being able to see the world directly could cause problems, such as the AR showing an open field (due to a software glitch or showing the wrong app or a malicious hack) in front of you while in reality there's a real life cliff in front of you, just as an example. It's a cool idea, just make sure you're in a safe environment while using it. Maybe briefly remove the goggles now and then to verify.

Pass-through AR could show everything with an infinite depth of view allowing you to rest your eye focus muscles and still see things near and far equally as well, 'in focus'. Alternately have an artificial depth of view you can control and you can also rest your eye focus muscles. One can already rest one's eye rotate muscles simply by moving their heads. Many birds can't rotate their eyes relative to their skulls which explains why they constantly turn their heads (for fovea clarity and perhaps also for triangulation.)

Another cool idea with Pass-through AR is to see yourself in a virtual mirror. Not your real self however, but as some Avatar! So at least to yourself you're walking around the real world as someone completely different.

Yet another cool idea is the Geordi LaForge effect, see wavelengths you normally can't see with your real eyes, it translates ultraviolet down to say regular violet allowing you to see these frequencies. Perhaps some UV rays are reflected into the house through a window. Same with infrared to regular red, see if the stove-top is hot without sacrificing your finger!

C64 Mercenary geometry decoded

Thanks to http://icu64.blogspot.com/ visual editing tools I've figured out the geometry data structure for pickup items in the C64 game of Mercenary. Perhaps this also applies to outdoor structures as well, I haven't check yet. Due to the fact that line segments only use 4 bits to reference verticie indicies, there can only be 16 verticies referenced (0-15.)

pickup object data structure:
1 byte: index of last verticie on the list (max of 0F)
Each verticie is 3 bytes, size of verticie section = (last vert index+1)*3

depth byte, height byte, width byte all from origin (check signed byte number system)

1 byte: index of last line segment on the list (I suppose max of FF)
Each line segment is 1 byte, size of line segment section = last seg index+1.

high nibble is index of 1st verticie, low nibble is index of 2nd verticie

signed byte number system:
FF,00,01, and 80, are all 00 (don't ask me why so many)

FE is -1, 81 is -126  (magnitude = FF - number)
02 is +1, 7F is +126 (magnitude = number - 01)

Example: table in Mercenary Second City that you can fly

Pickup item verticie magnitudes are a very small fraction of the 126 maximum. It reads this data structure every frame, so data compression isn't an option as compression requires compute time which is a very scarce resource on the 1Mhz CPU.

overview: 3e61-3e8e item 06 (Table) 45 bytes

3e61 0b num of last verticie

3e62 f9 vert 00 depth of right-rear leg bottom
3e63 00 vert 00 height of right-rear leg bottom
3e64 f3 vert 00 width of right-rear leg bottom

3e65 07 vert 01 depth of right-front leg bottom
3e66 00 vert 01 height of right-front leg bottom
3e67 f3 vert 01 width of right-front leg bottom

3e68 07 vert 02 depth of left-front leg bottom
3e69 00 vert 02 height of left-front leg bottom
3e6a 0d vert 02 width of left-front leg bottom

3e6b f9 vert 03 depth of left-rear leg bottom
3e6c 00 vert 03 height of left-rear leg bottom
3e6d 0d vert 03 width of left-rear leg bottom

3e6e f9 vert 04 depth of right-rear leg top
3e6f 06 vert 04 height of right-rear leg top
3d70 f3 vert 04 width of right-rear leg top

3e71 07 vert 05 depth of right-front leg top
3e72 06 vert 05 height of right-front leg top
3e73 f3 vert 05 width of right-front leg top

3e74 07 vert 06 depth of left-front leg top
3e75 06 vert 06 height of left-front leg top
3e76 0d vert 06 width of left-front leg top

3e77 f9 vert 07 depth of left-rear leg top
3e78 06 vert 07 height of left-rear leg top
3e79 0d vert 07 width of left-rear leg top

3e7a f6 vert 08 depth of right rear corner
3e7b 06 vert 08 height of right rear corner
3e7c f0 vert 08 width of right rear corner

3e7d 0a vert 09 depth of right front corner
3e7e 06 vert 09 height of right front corner
3e7f f0 vert 09 width of right front corner

3e80 0a vert 0a depth of left front corner
3e81 06 vert 0a height of left front corner
3e82 10 vert 0a width of left front corner

3e83 f6 vert 0b depth of left rear corner
3e84 06 vert 0b height of left rear corner
3d85 10 vert 0b width of left rear corner

3e86 07 num of last line segment

3e87 04 seg 00 right rear leg (right-rear leg bottom to right-rear leg top)
3e88 15 seg 01 right front leg (right-front leg bottom to right-front leg top)
3e89 26 seg 02 left front leg (left-front leg bottom to left-front leg top)
3e8a 37 seg 03 left rear leg (left-rear leg bottom to left-rear leg top)
3e8b 89 seg 04 right side (right-rear to right-front)
3e8c 9a seg 05 front side (right-front to left front)
3e8d ab seg 06 left side (left-front to left-rear)
3e3e b8 seg 07rear side (left-rear to right rear)

Variable Frame Rate videos (request)

I tip my hat at YouTube for finally supporting 60fps! The next best move I believe would be supporting variable frame rate videos. Have fast frame rates for action scenes, and slower frame rates for slow moving scenes that don't need it (to conserve memory) James Cameron is rumored to be considering this for future Avatar movies.

I was thinking about those fast motion / slow motion fight scenes in the movie 300 (2006). Lets say the user wanted to see how fast the action is in real time, after enjoying the artistic slow down / speed up sequences. Perhaps have an optional actual time per frame, while retaining the displayed time for the frame.

Each group of frames declares
-how many REAL_TIME (8 1/3 ms periods) each frame for (this group of frames) represents
-how many (8 1/3 ms periods) to ACTUALLY_DISPLAY each frame for (this group of frames) <- optional, if omitted it's identical to REAL_TIME

8 1/3 ms is not arbitrary, it exactly multiplies to these 5 values: 120hz,60hz,40hz,30hz,24hz
These are very common values, and this should provide sufficient timing refinement.

However more refined values could also be chosen, to include support for hi-speed cameras:
4 1/6  ms exactly multiplies to these 10 values: 240hz,120hz,80hz,60hz,48hz,40hz,~34hz,30hz,~27hz,24hz

2 1/12 ms exactly multiplies to these 20 values: 480hz,240hz,160hz,120hz,96hz,80hz,~69hz,60hz,~53hz,48hz,~44hz,40hz,~37hz,~34hz,32hz,30hz,~28hz,~27hz,~25hz,24hz

If Gsync becomes mainstream, perhaps do multiples of 1 1/24 milli-seconds.
Gsync is basically variable framerate at the hardware interlink between the video card and display.

Audio frames should coincide with video frames.

The common audio sample rates evenly sub-divide into the common video rates

0400 (048khz samples) = 8 1/3 ms
0800 (096khz samples) = 8 1/3 ms
1600 (192khz samples) = 8 1/3 ms

0200 (048khz samples) = 4 1/6 ms
0400 (096khz samples) = 4 1/6 ms
0800 (192khz samples) = 4 1/6 ms

and so on...

(also posted on YouTube product forum)