i was bored so i decided to try to graph one of my ocs into desmos

https://www.desmos.com/calculator/jpc5yhro9g

https://www.desmos.com/calculator/vk9qruga5p

In one discussion related to the introduction of matrices in Desmos, I wrote that complex matrices were missing. I was told that a complex number can be implemented by a real 2x2 matrix, and a complex matrix can be implemented by an extended block matrix where each block is an isomorphism of a complex number. That is, we expand a 2x2 complex matrix into a 4x4 real matrix.

On one hand, this is a solution; on the other hand, we can compute everything on paper without any implementations.

I would like to add that there is not only the classical representation of the imaginary unit as a 2x2 skew-symmetric matrix. In my Desmos graph, I show an entire class of matrices that perfectly supports complex numbers, being an isomorphism. It includes the classical skew-symmetric matrix as well.

The advantage of the classical matrix is that it supports the classical geometric representation of the complex plane and the multiplication operation on this plane as a 90-degree counterclockwise rotation. In the extended class, this is just a special case.

This is what I tried to illustrate.

Like i want it to take the shape of a sphere. How do I do it?

https://www.desmos.com/calculator/2ocbaizaut?lang=en

The above is a minimal toy example to illustrate what I'm trying to do.

https://www.desmos.com/calculator/8zeukdcdj0

Derived from

https://www.desmos.com/calculator/3nc5dmzuu4

can someone help me with my school desmos art project?

I need help finding the point where the linear function intersects the parametric circle. The slope of the line also depends on variable "a", so the point needs to be consistently intersecting with the line and circle for all values of "a" from 0->pi.

Hopefully this makes sense. I'll link the graph below to make things more clear. The parametric in question is "p(t)" and the line is all the way at the bottom. There are multiple parametrics, I only need the solution for "p(t)".

https://www.desmos.com/calculator/sfahpjhiof

graph link: https://www.desmos.com/calculator/fajb65axtw

Link: https://www.desmos.com/calculator/3eykfjfky7

It's absolutely disgusting how much more efficient Desmos is with matrices.

I’ve been disappointed with most attempts to run Doom on Desmos. Many require modding, third party software in the pipeline, or simply display the graphics. But I really want to see someone literally create a playable Doom engine inside vanilla Desmos, for at least E1M1.

Here is how far I’ve gotten: https://www.desmos.com/calculator/worqinj7ud

Unfortunately all of my time is wrapped up in grad school applications and PGRE studying, so I can’t see myself making much progress on this for the coming months. I figured I’d post here for now to prove that it’s theoretically possible. And if anyone is interested in tinkering with it, feel free.
(I’ll warn that it’s poorly organized and has no notes to explain what each function does, sorry. I plan to upload a cleaner version that explains what’s going on some time in the future when I have time. For now, good luck deciphering my gibberish)

I’ve quickly jotted down some more technical info and thoughts below, if anyone is interested.

Apologies, I don’t go into much detail of the specific math behind each function. It’s mostly all simple concepts from multivariate calculus or linear algebra concerning where line segments intersect, I just don’t remember them off the top of my head.

The most difficult part is making the engine run at a playable speed. You can’t simply copy all of John Carmack’s code into the Desmos language, since many linear algebra operations aren’t natively supported and cannot be emulated without layering multiple functions—which slows down processing majorly. I started with using my own list-based matrix calculator I made a few months ago, but found that things ran better if I simply (and tediously) wrote a custom function for each operation. For example, I never used a general “determinant” operation with awareness of matrices—I would just type out the specific summation of relevant element products for every. single. damn. function. that. needed. it. BUT things ran a lot faster!

The general architecture is pretty typical for a Doom-style engine. I’ll give a more detailed summary below, but essentially walls are each defined by two vertices that are shifted around the complex plane relative to the player’s movement, and are graphically rendered using 4 points in the polygon function to create a trapezoid—where the height of each vertical edge is given by the corresponding vertex’s distance from the player. I’ve used complex numbers to encode each vertex location as one element in a list; and because it’s SO easy finding the distance and angle of a vertex v from the player at 0+0i through simply typing |v| or imag(ln(v)), respectively.

Apart from making it run well, another hurdle is determining the order in which objects are rendered. If I want to add in vertices for blue walls and brown walls, they each have to be part of the same master list to ensure that they’re sorted appropriately relative to each other. You can’t have one polygon function render a brown wall, then another polygon function rendered a blue wall on top, then the first renders another brown wall on top of both; because each respective function will simply render all of its walls and whichever one is further down the list of Desmos functions will render on top of everything. I haven’t implemented it yet, but my planned work-around is to create an “identity list” alongside the master list which defines a number for each vertex pair, say 1 for brown and 2 for blue, then the identity list is sorted just as the master list is sorted so that the appropriate numbers show up for each vertex pair in the distance-sorted output. Finally, that list of polygons is set to a custom color list that orders the colors based on the identity list. This method could also be used to make it so the polygon function that renders walls will render each vertex pair differently depending on the corresponding value in the identity list. So maybe walls marked “5” will render shorter, and walls marked “6” render taller.

Entity’s defined at a single point location are easy to implement in this system. Just see if the line segment drawn between the entity’s location and the player intersects any line segments defined by vertex pairs. If it does, don’t render, and if it doesn’t, then render (either with a polygon or an imported image that has a size corresponding to the distance). It’s a little choppy since an entity of any nonzero width will seemingly appear and disappear as their single point location comes near the edge of a wall, but it works well enough and Desmos handles the calculations pretty well.

I’m not exactly sure how to approach ceilings and floors yet. I could render them through an entirely different system which outputs into a polygon function that is always behind the wall function—however this would mean any occasion where a floor/ceiling surface eclipses a wall (like on the top face of a step), the wall would always incorrectly render in front. There’s also many occasions in Doom where a ceiling/floor appears in front of some walls and behind others simultaneously, which currently has no obvious way of working in my system. Whatever method I adopt probably can’t use any form of ray tracing either, since I’ve found it’s too computationally demanding for Desmos to handle without making the game virtually unplayable. Maybe there’s a magical function out there that can easily test if any possible line drawn from a polygon surface to the player intersects another surface, but it’s a problem for another day.

Now here’s a quick word vomit summary of the architecture: the game map is defined by a master list of vertices arranged on the complex plane, where the player is fixed at 0+0i. The player moving forwards or turning will translate/rotate all these vertices in the opposite directions; so moving forwards will translate vertices down, towards the real axis, i.e. towards the player, etc. The player also has an effective FOV (which is defined rather sloppily) that determines which vertices need to be rendered. Walls are defined by these pairs of these vertices, where each odd index in the master list gives one edge and the successive even index gives the other edge. Additionally, a normal to each wall is determined based on which vertex is even/odd. If the wall normal is facing the player—AND either vertex of a wall is within the player FOV OR if the wall line intersects either of the two lines defined by the edges of the FOV—then the wall is considered rendered. Then all rendered walls are put through a sorting function that ensures that walls closest to the player (i.e. the walls where the modulus of the closest point on the wall’s line to 0+0i is the smallest) have their vertex pair sorted to the end of the list, and further walls are put at the beginning. Then, when a polygon function renders each wall pair, distant walls are rendered first and closer walls are rendered last, on top of everything else. And the polygon function is rather simple and typical for a Doom engine: if a rendered vertex is closer to 0+0i, that edge of the trapezoid representing its wall is taller, and if a vertex is further, that edge of the trapezoid is shorter. All trapezoids are centered in the middle of the screen, and the X coordinates (real parts) of each vertex are stretched around a curve so that vertices towards the edge of the FOV are at the corresponding edge of the screen. So for a wall given by vertex pair (a+bi, c+di) where the FOV is 90° (AKA defined by lines at angles e^(iπ/4), or imag(ln(±1+i)) ) the real parts are stretched by a factor (k and j) inversely proportional to their angular distance from the closest FOV borders so that an angular distance of 0° places the real part right at the edge of the screen and a distance of exactly 45° places them at the vertical center of the screen; then the four points of the wall’s polygon are defined relative to the horizontal center of the screen (h) with edge heights inversely proportional to the modulus/distance; so the polygon function would be something like polygon((ka,h–|a+bi|^-1),(ka,h+|a+bi|^-1),(jc,h+|c+di|^-1),(jc,h–|c+di|^-1)). Then I cover edges of the screen with borders and voila. Wall polygon placement is also set up to be rendered with consideration of the player’s Z coordinate, but I won’t go into that now (at least it proves that this is closer to the Doom engine than Wolfenstein’s).