Branching off a new thread from an @Edward de Jong / Beads Project post: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1593274446009800?thread_ts=1593225852.497700&channel=C5T9GPWFL&message_ts=1593274446.009800

A classic "Bret Victor'esqe" style breakdown of basic math behind the modeling of light (i.e. 3D rendering). I know Bret Victor has since said these kind of limited interactive articles miss the point of his philosophical message, but I still think there is a lot of value in them. Especially the well polished examples like this. https://ciechanow.ski/lights-and-shadows/

A comprehensive look at what’s new in Metal from WWDC2020. TBDR is coming to Macs with Apple Silicon, harmonizing CPU and GPU architectures across all Apple devices. This comes after they’ve been designing their own CPUs for a decade and their own GPUs for six years. The GPU compute capabilities seem very mature. Have a look at the function pointer feature and the ray tracing APIs. Seems like Apple is ramping up to position this as a serious alternative to the energy-hungry overdraw-heavy classic world of desktop graphics. Will be interesting to see how the industry reacts to a different approach of slicing the market: previously you’d build for either PC/console or mobile, mobile often being second thought ported separately if at all. Soon you can access part of mobile + part of notebook/desktop (+ perhaps a more capable Apple TV which would qualify as a gaming console?) with the same architecture, but of course limited to Apple devices. It was easy to ignore Macs for gaming in the past, but now it basically comes “for free” if you consider shipping for mobile/iOS. http://metalkit.org/2020/07/03/wwdc20-whats-new-in-metal.html

https://twitter.com/quelsolaar/status/1280275143261138945?s=21 this guy has been doing really interesting stuff since at least 2008. will be interesting to see where it goes

this looks promising from both a graphics/simulation perspective and a language design perspective. the language splits behavior and data, the compiler optimizes data access, and (synthetic benchmark) 10x shorter code, 2-4.5x faster rendering

not sure if I’m behind the curve on finding this, but this webgl state viewer from the babylon.js folks is fantastic: https://github.com/BabylonJS/Spector.js

Does anyone have any suggestions for what tools to use to build a music visualizer? Preferably something with great performance (e.g. not HTML5 Canvas) and I'm open to learning a new language but ideally I don't have to invent a new system.

@Nuno Leiria and I have started Dali, a new 2D/3D graphics API, based on signed distance fields, implemented with WebGPU. The goal is to enable the future of user interfaces and visual programming languages by providing a much richer set of graphics primitives for rendering UIs than what is supported by traditional postscript/SVG/HTML/CSS 2D vector graphics APIs. The graphics model is inspired by my Curv project, but more general and much higher performance. At this point, we have overall project goals, a list of prior art, and a design sketch for the Demo 1 release, which will demonstrate text rendering. * overall project goals: https://github.com/dali3d/dali * text rendering goals: https://github.com/dali3d/dali/wiki/Text-Rendering-(Demo-1) * prior art for text rendering: https://github.com/dali3d/dali/wiki/Prior-Art We are looking for help, especially with the architecture. * Suggestions and recommendations on the GPU data structures and algorithms to use. * Pointers to existing projects that are not in my Prior Art list, that show a better way to do things than what I've considered thus far. * Collaborators.

https://twitter.com/awwbees/status/1294283629233950720?s=21 love the use of visible waveforms traveling over the wires in this project!

I just ran across makepad, which looks like a very promising live coding environment for rust https://makepad.nl/

Hi people, i made makepad. i can answer questions

Makepad is a new UI stack written in Rust with 0-dep backends for win32/dx11 linux/opengl mac/metal and web/webgl

https://twitter.com/sebaaltonen/status/1300063944846069761?s=21 thread/quote tweet rabbit hole of how the game engine for Dreams works with SDF’s and a lot of clever optimization

For those interested in Bret Victor style animation (ie. stop drawing dead fish). Check out this new siggraph asia paper:

I'm looking for 256-color clipart, the kind that came on macintosh CDs. Like a ready-to-eat png archive (or online emulation) of such. Any archaeologists out there know where to look? Too lazy to spin up an emulator and download 50 disk images. Old websites might have this too

Great intro video on SDFs

This is lovely visualisation of motion and geometry, with a drawing tool: http://www.engare.design/

Here’s a pair of (formal) papers on rewriting string diagrams, which could help solve problems in graphical programming languages like “how do you nicely display an arbitrary set of merged functions?” (ie level of detail, though “nicely” isn’t defined in these papers, it could be…) https://arxiv.org/abs/2012.01847 https://arxiv.org/abs/2104.14686

A friend of mine created this Graphical UI to procedurally generate graphics: https://www.instagram.com/p/COioBISnAh1/

Has anybody worked with Nvidia Kaolin? Scaffolding for working with 3D graphics in ML systems, based on Pixar USD

I wonder if someone has experience in building user interface navigable without mouse (ex: on TV, game consoles, etc). I remember obsessing over the nav system because pretty much every UI system I worked with required wiring the direction keys manually, and making sure there were no "focus traps", etc. Anyway, this nice simulation of delaunay triangulation gave me the idea of a possible way to wire direction keys automatically. I think some heuristic like this could work: • Make sure every edge between to widgets connected through the euclidean minimum spanning tree is assigned to one of the cardinal directions. • For each widget, fill the rest of the cardinal directions using the relative neighborhood graph, and remembering which widget we "came from" in the opposite direction. As usual, the devil is in the details .... for instance: • I imagine each widget would have to be modeled with a bounding area instead of a single point ... • Care would need to be put if bounding areas overlap ◦ Some widgets may still require tracking its own focus before delegating to the pre-calculated target (for ex., I imagine a scrolling gallery in the middle of the screen surrounded with buttons... 😭) • Etc, etc, etc .... There's a reason most UI frameworks just ask the programmer to do wire navigation by hand 😄

Anyone here used Babylon.js? Would you recommend it?

just a reminder to everyone about the game noctis, maybe the original procedurally generated game from literally the year 2000 with amazing vibes (the music isn’t from the game): https://en.wikipedia.org/wiki/Noctis_(video_game)

any folks here use touchdesigner? i’ve been incredibly impressed by it’s notebook-like functionality embedded in a visual-programming paradigm. Of all of the node-based tools i’ve seen, imo it has done the best job at bridging the gap between text based and node based programming, while also (most impressively) embedding a fairly rigorous notion of time into the whole environment

a small frp-ish dsl I made for live coding ray marchers: https://charlieroberts.github.io/screamer/playground/

Hello! I'm curious if anyone here has a good idea about interleaving works between a compute shader and a fragment shader. Some relevant details: • My app is built with Rust and wgpu, and I'm running on an M1 Macbook Pro. • I have a single encoder with a compute pipeline and a render pipeline. • The compute shader writes to a storage buffer defined like this:

@group(0) @binding(2) var<storage, read_write> output: array<vec4<f32>>;

• The fragment shader reads from the same buffer. Basically, each fragment is just one element of the

vec4<f32>

. The fragment shader is very simple, and doesn't touch anything else in the storage buffer. I've added timestamp queries to the pipeline, and what I'm seeing is this:

Duration #1: 47.800208ms
Duration #2: 47.809876ms
Frame time: 51.2545ms

Duration #1

is computed from the compute shader timestamps (the duration between the beginning and end of the compute pass) and

Duration #2

is the time for the render pass, computed the same way.

Frame time

is measured on the CPU. I expected the duration of the compute shader and fragment shader to add up to the frame time (approximately). But it doesn't and I'm confused about why! Could it be due to interleaving of the compute pass and render pass? If so, I'm curious how the synchronization works. How does the GPU figure out the dependencies between the write (a compute shader invocation) and the reader (fragment shader invocation)? I don't have any explicit synchronization, but I'm also not seeing any tearing or anything that would indicate that there is a data race between the shaders.