"To get better at math?"
*actually uses it to implement her first 3D engine from scratch*
(honestly very proud of this!)
@goo that's really awesome!!
What was your general approach? I don't know much about 3d engines
@postulate My starting idea was to have a collection of points in 3D space (3 coordinates, xyz) and attempt to convert them to points on my 2D screen (xy).
If your point of view ("camera") is static at (0, 0, 0) and looking straight towards positive Z, then every point keeps its X/Y coordinates, they just get divided by their Z coordinate (to account for how far away they are).
The thing that threw me off is that you need to ignore points that are behind the camera (e.g. have negative Z coordinates in camera spacr), otherwise you get weird artifacts.
To render the scene, you then only have to convert each point's coordinates to coordinates relative to the camera's position and orientation, which is just a matter of substracting by the camera's position and multiplying by a few rotation matrices (one for each coordinate).
The math is from Wikipedia because I couldn't come up with it myself: https://en.wikipedia.org/wiki/3D_projection
@goo so are the objects triangles that you're doing some fancy math to see how they obscure each other? Or are you doing some point based stuff somehow?
Objects are "polygons", or rather lists of points that I fill in using standard 2D drawing functions.
And that's the thing I haven't made 100% industry standard yet: since every polygon is rendered in the order they appear in the list, some just render over the others, no matter their actual position. I believe the way to avoid this is to first compute every coordinate and then draw polygons in order of furthest to closest to the camera.
@goo yeah that sounds messy
Given two polygons at weird angles, knowing which one obscures the other depends on more than just which one has its closest-to-camera point closer to the camera.
(Think of looking almost edge on at a long wall. A polygon can be behind the wall or obscure a little bit of the end)
Actually wait no single strict ordering can work. Think of three polygons, each below and above another in a cool Escher like pattern, or like the top of a cardboard box folded up fancy
@postulate Yeah I was thinking that if the polygons never intersect it'd be OK, but actually no, your Escher example messes that up. It's gonna be complicated, cool.
@postulate Oh it seems that the standard way to prevent that is to render every pixel of a polygon to a "Z-buffer". If you only update the pixels that have smaller Z-values, rendering order is preserved.
The problem being that I'll have to write every single pixel of every polygon one at a time manually, and that's probably going to be slow on a CPU.
@goo ah and someone has the Escher example here
I do have to wonder if there's a mathematically perfect way of taking two triangles (for simplicity) and returning exactly the visible parts.
@postulate Either way, thanks a lot for this discussion! I feel like I learned a lot trying to explain my approach to someone else and the follow-up pondering was very interesting.
@goo Thank you too! This is fun.
I found some more links to alternatives on this Wikipedia page if it helps
Maybe some are faster?
Good luck with the rest of the engine, it looks great so far :)
*Due to increased bot signup, manual approval is temporarily required. Please write some applicable request text on signup.*
This Mastodon instance is for tech workers, academics, students, and others interested in tech who are LGBTQIA+ or Allies.
We have a code of conduct that we adhere to. We try to be proactive in handling moderation, and respond to reports.
We're not a free speech absolutist, and there are instances available for that. We're not interested in Nazis, TERFS, or hate speech of any sort, which we will define at our sole discretion as moderators.
This instance is meant to be a friendly, welcoming space to all who are willing to reciprocate in helping to create that environment.
This instance is funded in part by Patreon donations.