4 ms·
Once I understood non-linear vector spaces and coordinate transformations… wait what am I saying? One day, I realized you can do cool stuff if you have geometr
by b33j0r 3y ago
Once I understood non-linear vector spaces and coordinate transformations… wait what am I saying?
One day, I realized you can do cool stuff if you have geometry data as x, y, z:
t = x + y;
xt = sin(t);
yt = cos(t);
zt = sqrt(xt**2 + yt**2);
You’d only do it that way explicitly in a vertex shader—but congratulations, that’s a coordinate transformation!
Now do it with more xyzwqp’s, then, profit!
In my example, I compressed x+y down to one parameter. You’ll be combining 4 spacial dimensions into combinations of xyz for use with a rendering pipeline.
Or, alternatively projecting straight to xy. Not sure which is preferable.
- immibis 3y agoIn hyperbolic geometry it's hard to even have x,y coordinates at all. Once upon a time I looked at the source code of a hyperbolic 2D game; can't remember if it was HyperRogue or something else. It recorded your position as something like a binary representation of a path down a tree from the origin point.
- zenorogue 3y agoMore precisely -- you can have x,y coordinates, or (easier to work with) x,y,z coordinates, but you would quickly run into numerical precision issues, and that binary representation prevents that. (Probably it was HyperRogue, other hyperbolic games are wrapped or small enough to work without it. David Madore's hyperbolic maze has a wrapped world so it uses a totally different system. I think Sokyokuban also has tree-based representation of the map, even if the world is small. It could also be Hypermine by Ralith, it is also open world and open source.)
- b33j0r 3y agoWoah, you have a hyperbolic screen? Haha. But you do have to project to x and y screenspace eventually, if you want to see your work. My take was pretty slanted towards vertex shader techniques rather than xyz representing cartesian spaces (or even euclidean). One could imagine some scaling factor or something ending up in the shader variable for VERTEX.z that isn’t really z in an xyz mesh. My afterthought scenario of projecting to XY (screenspace) is probably the more relevant one.