Scratch

Why has 3D been so hard for people with Scratch, but not with other programming languages? It's because Scratch doesn't have a z-coordinate. Obviously other languages do, but then; how exactly does the program interpret them and transfer them to your 2D screen? There must be a simple formula, and we are going to figure it out.

WARNING: I don't know exactly either. But I'm going to organize all my thoughts here, to "bring new insight" for our potential breakthroughs.
**************************************************************
Part 1: The Sprites

Obviously we can't use normal sprites as polygons, because they would need a new costume for every possible orientation (imagine a cube. If you are looking directly at one face, it's a square. But rotate the cube a little to the side, and it's a rectangle. From that, turn it a little downwards, and you have some awkward paralellogram). There is an infinite number of costumes we would need. So we can't use that.

What are polygons made of? Line segments. But those would change length and orientation. So we fail there.

What are line segments made of? Points. And I quote from geometry:

"Two points define a line."
             -Postulate 1-1

That first axiom, the basis of all geometry, will give us the answers.

So consquently we will express all polyhedrons with connected points. Got it?
**************************************************************
Part 2: Connecting the Points

So now we know that we have a jumble of random, meaningless points. We simply connect them with another sprite that is constantly going from visible point to visible point, using pen down. THE ONLY PROBLEM IS THAT every time the view changes and the points move, the game will be forced to clear and re-render, so using pen down might not be the best option. Give your feedback!
**************************************************************
Part 3: Where's z?

Okay. Randomly grab a cube-shaped object. Put right in front of your face. Then slowly move it away. It gets smaller as it gets farther away. Recall the cube in front of your face. The corners of what you see may be (100,100,0); (100,-100,0); (-100,100,0); and (-100,-100,0). Now as you move the cube away, the z-coordinate increases, but the object appears smaller. What is the ratio of distance away to length on screen?

I'm thinking of three ways to approach this, and one way not to:

#1 Use variables to define x, y, and z. Make a guess as to how far away the user is from their screen (I'm serious!). Calculate where a line from a point to the users eyes would intercept the screen. DISADVANTAGES: this involves planar geometry, which is rather complex for Scratch to handle, and we don't exactly know where the user is relative to the screen.

#2 Imagine a point (x,y,z). Use trigonometry to calculate a) the angle between the z-axis and the imaginary line from the origin to (x,0) and b) the angle between the z-axis and the imaginary line from the origin to (0,y). Call them angles A and B respectively. But if x is negative, make A negative, and if y is negative, make B negative. Now imagine, if someone were to focus straight ahead, how many degrees that person's peripheral vision would encompass from left to right. Divide by two to have just one side of the origin. Call that C (it's probably a little less than 90). Now imagine their peripheral vision up and down. Call that D (maybe 40 or 45?). Now divide C by A and D by B to get "what fraction of one side of a person's vision span that would take up". Multiply C divided by A by 240 to get the point's x-coordinate, and multiply D divided by B by 180 to get the y-coordinate. DISADVANTAGES: this is very complicated, not completely foolproof, and we don't know exactly what a person's vision span is.

#3 Just use trig and determine where it would appear to be. As the object gets farther away, the angle at your eyes between its points and straight ahead decreases, and I suspect that this is why things shrink.

#-1 HOW NOT TO - Do not use the "size" block so that size decreases as z increases. Sure, it looks a little realistic, but there's no way it's the exact ratio of size to z-coordinate. And besides, we're using points, not polygons, and size doesn't change on a point.

Feedback very appreciated!
**************************************************************
Part 4: Touch-ups

We'll have to color in these polygons too, unless you just want your next first-person shooter to be in a world of see-through, empty wireframes. First, one would need to use lines and planes to determine which points would be hidden by planes in front of them. Then then pen would connect all the visible as pre-programmed (obviously we can't just have a line for every two points, we only need certain points connected). Then we could use some sort of auto-filling function and add color. I remember seeing a project that did that, but it took a while. I don't know if everything I have just said is the best way, and I doubt that it is, because this would need to happen every time the screen was rendered, and that could happen many times per second. So I'm open for insight on that.
**************************************************************
Part 5: End

Goodbye. Please post ALL your ideas even if you think they're stupid. They might be the basis for something or shed light on another. Let's not race each other to discover 3D, let's work together here and now. If it's been done before, it can be done again.