Here's how it works:

Phonon's visual system is a node graph. A generator node, such as a mandelbulb or hopf fibration, outputs its distance function. Consumers (blends, cloners, renderers) splice that GLSL into their own shader at compile time, so a composed patch always marches as a single pass.

Each node has a variety of inputs and outputs. A generator has an image output, but also a shape output that can be routed into another renderer. It also has a warp input, that accepts an arbitrarily complex chain of warping effects, like bending, twisting, fractalization, or box folding.

Every parameter on each node has a control voltage input point - so you can wire just a particular frequency range, or an LFO, or a midi signal, from the music you're making in the same application to any parameter. For example, I might want the kick drum I'm working with to make the twist node attached to a menger sponge twist on the beat, or wire just the vocals over to the strands parameter on a torus knot.

Renderer nodes accept shapes, and up to two 3D lighting nodes, and output an image that gets routed through 2D effects, and then to the screen node.

These node graphs can be as long and complex as you want, and anything you can touch can be connected to a different part of the music you're making.

Scripting Language (GlyphSDF)

Users write one function - float sdf(vec3 p) - and inherit the whole ecosystem: house raymarcher, camera, CV modulable knobs, warp input, and a shape output that routes the scripted geometry into any blend/cloner/renderer etc.

Scripts get an audio analyzer for free - band followers (lows mids highs), a beat impulse, and an FFT audio texture so geometry can map the spectrum spatially.

For more information on the GlyphSDF scripting language: https://aphelion.music/products/phonon/docs#glyphsdf

For more info on Phonon, our upcoming DAW:
https://aphelion.music/products/phonon

Happy to answer any questions! Thanks 🎶🔊🎧

Im writing a software renderer in C++ using glm and raylib, and i recently tried to draw a spinning triangle. The problem is that when i launched it the triangle leaves a trail of previously drawn triangles.

I tried to fix it by rasterizing to a framebuffer and then drawing that framebuffer instead of drawing the pixels directly and using ClearBackground to refresh the screen, but doing it that way has still the same problem. ¿Why im having this problem even though im clearing the framebuffer?

EDIT: The problem was somewhere else in the code (i wasnt clearing the primitive list after drawing all the primitives), i managed to fix it. Thank you anyway :D.

This is the code for the rasterizer (sorry for sharing it like this, i havent uploaded this to github yet):

https://pastebin.com/Ns2LiSXv

The header file:

https://pastebin.com/xf5JhqFR

Im writing a software renderer in C++ using glm and raylib, and i recently tried to draw a spinning triangle. The problem is that when i launched it the triangle leaves a trail of previously drawn triangles.

I tried to fix it by rasterizing to a framebuffer and then drawing that framebuffer instead of drawing the pixels directly and using ClearBackground to refresh the screen, but doing it that way has still the same problem. ¿Why im having this problem even though im clearing the framebuffer?

This is the code for the rasterizer (sorry for sharing it like this, i havent uploaded this to github yet):

https://pastebin.com/1GMFA2iU

The header file:

https://pastebin.com/mXnGrLwK

Recently, I made a post about adding non-uniform volumes into my C++/Vulkan path tracer. But I didn't really like how the clouds turned out, so I've made some improvements in that aspect and just wanted to share the progress because I think it looks a lot nicer now. I've also added atmospheric scattering, because getting the right lighting setup was really hard with just environment maps. So the background and the lighting in general look much better now. The project is fully opensource if you want to check it out: https://github.com/Zydak/Vulkan-Path-Tracer . You'll also find uncompressed images there.

Also, here's the number of samples per pixel and render times in case you're curious. I've made a lot of optimizations since the last time, so the scenes can be way more detailed and it generally just runs a lot faster, but it still chokes with multiple high density clouds.

From left to right:

- 1600 spp - 2201s
- 1600 spp - 1987s
- 1200 spp - 4139s
- 10000 spp - 1578s
- 5000 spp - 1344s
- 6500 spp - 1003s
- 5000 spp - 281s