I'm working on adding something like https://graphtoy.com/ to my lisp-based 3D art tool https://bauble.studio/. It's really useful to visualize functions like this, especially when writing animation curves that vary over time.
It's easy to add it as a plain overlay over the screen if you're graphing a function, but I really want it to be able to plot arbitrary expressions with free variables where it just infers the axes, so you can just see values overload in the orthographic view (press alt-q to see that). That way you can just write something like (ss p.x 0 10 | graph) on any expression and visualize it as you go. I haven't quite figured out how to make it seamless though...
If this kinda thing piqued your interest and you want to play around with this idea, paste the following code into https://bauble.studio/:
(def octaves 4)
(def lacunarity 2.00)
(def persistence 0.50)
(def period 100)
(def height 40)
(plane y (fbm octaves :f lacunarity :gain persistence perlin p.xz period * height)
# try s/color/shade on the line below
| color (ss p.y -20 0 blue (ss p.y 0 20 green white))
| slow (20 / height)
| intersect (sphere 200))
(Using the terms from the article.) You can right-click and drag those numbers to see how the parameters affect the result in realtime. Also an easy way to compare perlin and simplex noise. Procedural terrain is fun!
Also while this uses 2D perlin noise -- you're just changing the height of a plane -- you can create some pretty detailed neat "rocky" terrain effects by using 3D perlin noise instead. Change "p.xz" to "p.xyz" to see what that looks like.
okay, that's helpful. the "undefined is not an object" bit is definitely a function of the "failed to create webgl2 context" error -- it tries to reference it unconditionally. no idea why it can't create the graphics context in the first place, though (and not much to do without one)
I ordered them from sculpteo — the only service I could find that would do it. Very happy with everything I’ve gotten from them. It is very very expensive if you want to make anything large, but for small jewelry-scale stuff it’s not too crazy. The balloon is seven custom parts so that was pricey ($250 total?), but the other two models were around $50 each.
It's complicated; Calvin Rose was the original creator of Fennel ("fnl"), but I understand it was just a little side project that he made over the course of a week or so in college. Phil Hagelberg found the project years later and thought it was cool, took over as its maintainer, and basically turned it into the Fennel you know today. So it's like, kind of, I dunno, both things are kinda true.
That's even more funny in the end, I thought GP was referring to Phil Hagelberg as creator of both, but they were referring to Calvin Rose as creator of both. Oops. Mystery solved.
Anyway - Fennel and Janet look very interesting, and a large thank you to everyone involved!
hi, i am the author of this book and i agree with you. it's not a good connotation. i chose it because: 1. it is kinda memorable (look there are so many programming books with exactly the same name) 2. the language is named after an immortal being who guides mortals through the afterlife in the fictional property the good place, so there's some kinda connection. but i agree the implication that janet is somehow "hard" to learn or that the author is somehow "on a higher plane" is bad. i waffled on this a lot but never came up with another title i could stand and ultimately just pulled the trigger. (but note that i left myself some wiggle room with a neutral domain name.) i hope the tone of the book itself helps to counteract the title, but ya know who knows
This isn't really a specific complaint about this book. Just triggered my thoughts on a general theme. Thanks for writing the book. I might look into it, as I'm generally interested in Lisp/Scheme-likes.
https://bauble.studio/ is a programmatic 3D art playground that I've been working on for a while now, and I'm pretty excited about it! It's based around signed distance functions, which are a way to represent 3D shapes as, well, functions, and you can do a lot of like weird mathematical distortions and operations that give you cool new shapes. Like average two shapes together, or take the modulo of space to infinitely repeat something... it's a really fun and powerful way to make certain kinds of shapes.
SDFs are very cool in general, and widely used in the generative art communities, but kinda hard to wrangle when you're writing shader code directly. They really are functions, but GLSL doesn't support first-class functions, so if you want to compose shapes you have to manually plumb a bunch of arguments around. So Bauble is essentially a high-level GLSL compiler that lets you model SDFs as first-class values, and as a result you can make a pretty cool 3D shape in just a few lines of code. And then 3D print them!
I need to do some actual work to promote and publicize it once I'm done with the documentation and implement a few more primitives, but it's very close!
Depending on the data, maybe? SDFs aren't great at rendering large numbers of enumerated objects -- something like a point cloud would be prohibitively expensive, so I wouldn't think to use them for like traditional graphing.
Basically taking the function (1 / (cos(x) + sin(y))) and adding it to itself 8 times, each time scaling and rotating the input a little more (:f).
I'm curious if it looks the same on all GPUs because it kinda relies on floating point precision errors to give it that film-grainy textured effect. And it definitely divides by zero sometimes.
So if you've ever loaded Bauble before you might have a stale and no-longer-working version of the tutorial cached in localStorage -- if you just clear out the script and refresh it will restore the default one. If that's still erroring, please let me know!
Oh yeah if you clear localStorage like from dev tools, Bauble will re-save the script before refresh, putting it right back where it was. But if you like cmd-a backspace to empty the contents of the script and then refresh it’ll load the default.
https://bauble.studio/ is a lisp-based procedural 3D art playground that I hacked together a while ago. It's fun to play with, but it's a very limiting tool: you can do a lot to compose signed distance functions, but there's no way to control the rendering or do anything "custom" that the tool doesn't explicitly allow.
So lately I've been working on a "v2" that exposes a full superset of GLSL, so you can write arbitrary shaders -- even foregoing SDFs altogether -- in a high-level lisp language. The core "default" raymarcher is still there, but you can choose to ignore it and implement, say, volumetric rendering, while still using the provided SDF combinators if you want.
The new implementation is much more general and flexible, and it now supports things like 2D extrusions, mesh export for 3D printing, user-defined procedural noise functions... anything you can do in Shadertoy, you can now do in Bauble. One upcoming feature that I'm very excited about is custom uniforms and embedding in other webpages -- so you can write a blog post with interactive 3D visualizations, for example.
Am I right that the output of the lisp code is ultimately a plain GLSL shader (like one might find on shadertoy.com)?
I built a SDF-based rendering system (2D) for my game, and one of the big hurdles was how to have them be data-driven, rather than needing a new shader for each scene or object.
Would be curious if/how you tackled that problem (:
Yep! It just outputs GLSL. It doesn't do anything smart -- it's a single giant shader that gets recompiled whenever you change anything, so it wouldn't really work for something like a game. I mean, it could handle like basic instancing of the form "union these N models, where N<256" but there's no way to change the scene graph dynamically.
I've done this for a project where the SDF functions are basically instructions, and you can build up instrictions on the CPU to send to the shader. and then the fragment shader runs them like a mini bytecode interpreter. You can tile up the screen to avoid having too many instructions per fragment. Kinda wild idea and performance may vary depend on what you're doing
The CPU builds an RPN expression (like "circle, square, union, triangle, subtract"), and the shader evaluates that in a loop.
I wasn't able to find examples of other people doing similar, but it seemed too useful to not be invented yet (:
Do you have any links to your work?
I'm writing some blog posts for my approach, but haven't finished them yet.
> You can tile up the screen to avoid having too many instructions per fragment.
I don't quite understand this part... If a given SDF needs N instructions to be evaluated, then how does tiling reduce N?
> performance may vary depend on what you're doing
Yeah, fill rate was not good enough with a straightforward approach, so I had to cache the evaluated distance values to a (float) texture atlas, then use those to render to screen. Luckily, standard bilinear filtering on distance values produces pretty decent results.
Yes sounds like the same thing! I also couldn't find anyone else doing it. Sounds super interesting what you're doing so I'd love to read your blog post when it's done if you want to drop me a message/email.
My project was using 2D SDFs for UI which meant you could use a bunch of primitive shapes and union/difference between them, and also add outlines, shadows, glows etc. This means that if you tile up the screen and use a union between two rectangles, only the tile with the overlap needs to calculate the union. It's a little more complicated in 3D with frustum culling.
I was doing it in webgl which doesn't have storage buffers and so I had to use uniforms to pass the data which is a huge limitation. Apparently webgpu could be better so I will try to figure that out one day. But it is early prototype so no links or anything yet.
Wait this is very interesting but I don't follow -- how do the template arguments let you identify the callsite? I thought this was basically just syntax sugar for memoize(doSomethingVeryExpensive, x)([""]), but there's something extra on that argument list that's stable across invocations?
It looks like the first argument passed to tagged templates is always the same across all invocations for the same callsite.
> This allows the tag to cache the result based on the identity of its first argument. To further ensure the array value's stability, the first argument and its raw property are both frozen, so you can't mutate them in any way.
This is how lit-html implements efficient re-renders of the same template at the same location in DOM. It uses the template strings identity to mark that some DOM was generated from a specific template, and if rendering there again it just skips all the static parts of the template and updates the bound values.
Tagged template literals are crazy powerful, and it would be really neat to add some of that magic to other language features. If functions could access the callsite, you could implement React hooks without the whole hooks environment. Each hook could just cache it's state off the callsite object.
However, there is only one instance of the template literal, not two as we might expect. This is really helpful for some cases, but it definitely is surprising given the rest-of-JS:
It's easy to add it as a plain overlay over the screen if you're graphing a function, but I really want it to be able to plot arbitrary expressions with free variables where it just infers the axes, so you can just see values overload in the orthographic view (press alt-q to see that). That way you can just write something like (ss p.x 0 10 | graph) on any expression and visualize it as you go. I haven't quite figured out how to make it seamless though...