this post was submitted on 11 Sep 2023
811 points (98.2% liked)
Games
32666 readers
669 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I have no game dev experience but I have a math and software background. I'm just curious about what "it gets weird at the poles" means. If I wanted to (abstractly) generate tiny square chunks of a large sphere, I would generate them as (proper) squares and then pass them through an explicit diffeomorphism to the associated region of the sphere, relying on the relative smallness to guarantee that the diffeomorphism doesn't change things too much. From a game dev perspective, what approach do you take that causes issues at the poles?
Imagine trying to find the intersections of a line or region as it crosses multiple cells of a non-euclidian "grid" near the poles where an entire axis can flip from one cell to the next.
Are you suggesting using a stereographic projection? That seems like a bad idea. You wouldn't want your projection to depend on the coordinate system. Am I missing a reason why you wouldn't use proper, nonsingular spherical coordinates?
Games, support libraries, and engines don't really support spherical coordinate systems. If you don't want to write everything from scratch, you gotta go Cartesian.
You can still use local Cartesian coordinates.
Sure, I guess, but constantly mapping between them gets complicated and adds overhead. Plus, now you are dealing with curves instead of lines when checking for intersections, and that gets far more expensive to compute when you are trying to do thousands if not millions of checks per frame when trying to run at 60 or 120 frames per second.
I'm not saying it isn't possible, just that games haven't traditionally been written that way, so you can't build on what they have already figured out. That makes it harder to find people who have game dev experience in that kind of math.