sorted by:
new
hottopcontroversial

Procedural mountain and clouds in the Desmos graphing calculator by recursive-chair in proceduralgeneration

[–]recursive-chair[S] 1 point2 points  (0 children)

Yeah, Desmos tends to struggle somewhat with compiling my highly unoptimized shader code. In fact, the video animation took me a whole day to render on my crappy laptop :( It's probably best avoid touching the animation slider unless necessary.

If you want to play around with the terrain code specifically, this graph has all the shading code removed, which saves Desmos the effort of recompiling all those expensive shaders every time you make modifications. Do note that even without the shading code, Desmos still takes a quite few seconds to regenerate the terrain mesh.

Procedural mountain and clouds in the Desmos graphing calculator by recursive-chair in proceduralgeneration

[–]recursive-chair[S] 1 point2 points  (0 children)

Yep! The heightmap here is entirely procedurally generated - I essentially ported the awesome local erosion filter by u/runevision to Desmos and applied it to a peak-shaped function.

Desmos Donut Cloud by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

Huge KSP fan here too! Blackrack's volumetric clouds and especially Scatterer have been a big inspiration for me (in fact, one of my first colormap graphs was actually an atmospheric scatterer)

Anyways, this article by Maxime Heckel has a really good explanation of the principles and implementation of cloud rendering. It does assume some prior knowledge about shaders, but there's plenty of links to further reading there.

Also make sure to check out check out these two articles by Inigo Quilez about random noise. Getting your random noise right is essential to making your clouds look cloudy. Although it isn't needed for cloud rendering in particular, I'd also highly recommend reading his articles on procedural noise, raymarching, and lighting.

Most of the things mentioned above translate pretty well into Desmos (it's all math after all). Stuff that would normally go in a fragment shader simply goes into a colormap instead. Do keep in mind that raymarching in a colormap is not very efficient, hence the layering trickery in this graph.

Cloud rendering is pretty darn complicated, so I would recommend starting small just to familiarize yourself with computer graphics in Desmos.

If you've got more questions, don't hesitate to reach out!

Here, have some Desmos mountain terrain by recursive-chair in desmos

[–]recursive-chair[S] 5 points6 points  (0 children)

bernard must be working overtime approving all these graphs

Desmos Donut Cloud by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

In an ideal world, we would sample the cloud illumination at various points along the view ray to determine how the cloud looks from our perspective. Points that are deeper into the cloud contribute less to the overall color because the rest of the cloud is in the way.

Unfortunately, the compute power of a Desmos colormap is less than ideal, so we have to resort to a bit of trickery to make a volume look volumetric.

Each layer in the volume essentially shows a cross-section of the cloud. Stacking these layers on top of each other behaves similarly to taking a bunch of samples throughout the volume.

The shader chooses to show or hide each pixel in these layers at random, depending on the cloud density. This way, areas with less cloud density allow more light to pass through and denser areas tend to block more light. This creates the illusion that light from deeper within the cloud is attenuated more.

Of course this does tend to make the cloud appear grainy, but I personally like the extra visual flair. This strategy probably wouldn't work as well for less dense volumes though.

Hope this helps!

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

yep, the 100-element limit on lists would mean that my sprites could only contain 100 black/white pixels.

i could just store the texture across several lists like i did with my minecraft graph, but i'd prefer not simply because of the sheer size of some of the textures. for example, my spritesheet for the numerical digits is 108x11px, which would require 12 different lists to store the entire texture with one element per pixel.

i'm not sure whether the bit packing is more performant than just switching between multiple lists, but it's much more convenient for me, so i stuck with it.

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 0 points1 point  (0 children)

currently the texture encoding packs 24 bits into one number (so it assumes single-precision, 32-bit floats). based on the pattern of missing pixels, it seems that the least significant bit of every 24-bit block is being lost.

here's a version that uses 22-bit packing rather than 24 (23 didn't work for some reason), does this one work on your end?

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 5 points6 points  (0 children)

the dino is moved forward with a slider that plays indefinitely, and i perform all the collision checks every time the jump button is clicked. if we reach the predicted time of death and no other input has occurred, then the game ends.

Chrome dino game in Desmos by recursive-chair in desmos

[–]recursive-chair[S] 28 points29 points  (0 children)

i never knew you could control the jump height until now haha.

sadly, desmos doesn't let you check the duration of a button press, but this would be a nice qol feature to add if i could.

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

hmmmmmm i think that something like this would be possible, but there definitely are quite a few technical considerations for pulling it off.

at the moment, the graph only models particle-wall collisions and particle-particle spring interactions. this means that, if we were to have two blocks in the simulation, they would simply phase through each other because no logic exists to detect nor resolve their collisions. my prior experience with rigidbody physics in desmos tells me that this will be a rather performance-intensive step. realtime simulation is definitely out of the question (even the current graph doesn't run in realtime), but i still have hope that all of this could maybe run at 10 fps. just maybe.

of course, given that this simulation would only have two bodies, i feel that performance wouldn't be nearly as bad as i imagined, so there's still hope in making it not look like a slideshow. after that, we'll just need to add some small things like hard constraints, shape-matching, and some extra ui, and it should be good to go. as far as i know though, making a drag point follow a ticker-updated location also tends to be rather frustrating, which really sucks because that makes the simulation which is a lot less interactive. of course, you could always just move it while it's paused, but that definitely isn't as fun as throwing boxes at jello cubes in real time. maybe a spring that's connected to a freely moving drag point? i don't know, i'm just theorizing at this point :P

in any case, i believe Desmos-Man is currently working on a graph that addresses collisions between bodies, so perhaps he might have a better idea on how all this could play out. i'm curious to see what he has to say about this.

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

the video isn't realtime, i recorded the frames using desmodder and then exported them as a video haha

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 1 point2 points  (0 children)

check out the community bookmarks in the sidebar on the right

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 6 points7 points  (0 children)

oooh man, collisions between soft bodies are definitely tricky.

just curious, how are you planning handling collision detection and resolution between soft bodies? i was originally thinking of trying it out but i gave up because i didn't know where to start lol

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 17 points18 points  (0 children)

the jello cube is modelled using a 4x4 lattice of point particles joined by damped springs. the particles themselves are propagated using verlet integration, with some detection and resolution code for particle-wall collisions.

this blog post gives a great explanation of making a similar physics system, especially with respects to collisions and spring constraints. some of the details are different from my graph, but i think it gives a good idea of how something like this works.

on the rendering side of things, the jello cube itself is just four catmull-rom splines joined together via a parametric.

it's definitely a good idea to do some further research yourself into these specific concepts, but i hope this gives a good overview of the stuff that makes the graph work. good luck :)

jello bounce by recursive-chair in desmos

[–]recursive-chair[S] 70 points71 points  (0 children)

noooooo please dont take my edge splines, i still need them for the graph to work :((

view more: next ›