Inspired by @EpicRaisin's recent post, I decided to make a 3D renderer. Right now it just draws a box, but it can draw anything if you configure it.
The things that make it good
- It has Z coordinates
- You can render whatever you want with it
- It has filling
- Move mouse to move the box
- Click to cycle filling options
Hope you enjoy!
EDIT: Some of you might be confused why I'm posting this after I've made a huge 3D game. The answer is that the game (Askew) uses THREE.js, a 3D renderer where all the "behind the scenes" work is done for you. This project is building my own 3D renderer in 2D — doing it from scratch.
ANNOUNCEMENT: I've been accused of copying this from a coding train video. Does this video exist? If so I'd like to see it.
This is amazing!
One suggestion I have is that when you use colors, to make the edges visible with a different color.
This is amazing!
Did I say this was amazing?
@firefish You are looking at it the opposite way. (That's an optical illusion when there's only lines, most people see it the other way but you are one of the few who sees it this way.) The smaller square is actually farther away than the larger square — in the picture, the cube is "pointing" to the upper-left. So when you move the cube, it should always be "pointing" towards the center of the screen.
Hope that helps!
Just to clarify: This is a 3D renderer build in regular 2D js! It's built from the ground up; I'm not using a library like THREE.js.
ha you did not need to prove you can make stuff in 3d, i think 90% of us are aware of the fact that you can lol
I really like it. I think it would be even better if you added different shades of colors to the different sides of the cube so that there would be a shadow or a cool lighting effect, and maybe you can create something where the person can interact with multiple shapes. Idk, it's just an idea...
The ones that get filled with a colour need some black/same colour slightly but darker shade strokes on the edges, it does look 3d but it just needs a little bit more depth. Other than that, it looks amazing and you did a great job!
@CraftrDoinBettr No, that would require building other things into it since you don't want to be able to see the lines behind faces. (I.e., you don't want to stroke the lines in the back of the cube since you couldn't see that.)
(I understand how the
stroke() function works, if I didn't I wouldn't be able to make something complex like this :D)
by the way just run the repl if the 3d is not showing up
I should call my web browser Cephalopod
Oh, quick question about lang dev
Interpreted Bytecode Interpreted compile and run - fast compile and run - slow
Is that true?
So compiling and running an interpreted lang would be faster than compiling and running a bytecode lang.
But... for bytecode interpreted langs, once you've already compiled them, then it's super fast to run them?
That's because traversing an AST is really inefficient — in a tree-walk interpreted language, you're doing it all the time while you're running the code, while in a bytecode language you do it only once (when you generate the bytecode).
@fuzzyastrocat Randomly happened across this comment by chance, I was thinking about creating a language, parser, lexer, and a bytecode interpreter.
I would then later advance to creating a JiT language of my own.
Where do you recommend that I start?
Other than craftinginterpreters, since I'll check there anyways.
@Baconman321 I'm actually not drawing a line from the center at all. I "draw" (this is just math though so it's not actually on the screen) a line from the camera's focal point to each of the vertices of the cube. Then I find the intersect of that line with the camera's view plane to find the point of each vertex on screen. I connect the vertices as required to form the cube (or fill the polygons, depending on what mode is selected).
The cube's vertices are offset by the mouse's position, which causes the movement.