#vren - C++ Vulkan renderer
night meadow
Hello!
vren is a Vulkan renderer I've started developing to learn the Vulkan API and had been the subject of my Bachelor thesis in Computer Engineering. At the moment it's currently an abstraction over the Vulkan API that I'm using to test several rendering — and, in general, computer graphics — techniques
sharp notch
Hi, I just quickly visited the github page. It mentioned rendergraph. How do you manage resources related to render graph? Who owns textures for example?
night meadow
Hi, I just quickly visited the github page. It mentioned rendergraph. How do you...
render graph doesn't own anything, you only specify which handles are used by which node
in order to make it lightweight I don't assign resources directly to nodes, I create them on a class called vren::render_graph_allocator and I only save an index to point to them
but yeah, their lifetime isn't managed by the render graph itself
it's externally managed
sharp notch
✔️
sharp notch
oh that ✔️ is hardly visible at all at least on desktop Discord client
sharp notch
I started with (some) nodes owning the resources in erhe
And I am planning to change it so that connections own the resources, not nodes
night meadow
mh I couldn't even do something like this
because my render-graph is meant to be built every frame so it doesn't really make sense to make the render-graph own resources
sharp notch
👍
night meadow
https://youtu.be/9zZ0kolOtZU
ClusteredShading seeing it's final form! In this video I show ClusteredShading current state of implementation in vren, as you can see there are lots of debugging options and it's absolutely not finished yet. In particular I should consider lights intensity — and therefore cluster's normal — before assigning them to the cluster. By assigning the first 8 nearest lights it could happen (like in this situation) that lights beyond the surface are taken resulting in, for example, the floor not being lit (all the lights are under the floor!)
https://youtu.be/oDEE7LQrOqQ
And this is OcclusionCulling! Differently from ClusteredShading this technique is working pretty well (like everything, could be optimized, but works). In this video I show some of the useful debugging options I've used for mesh clusterization, bounding spheres derivation and depth buffer pyramid construction
and, because this technique relies on the previous frame's depth buffer, if the previous frame is very different from the current one (because of low frame rate or camera going too fast) it'll show some glitches, like I show in the end of the video
In these days I'm working on ClusteredShading: I'm including the normals in cluster keys for a better light assignment. This is what I've got so far yesterday: the sample's normals are discretized (2 bits for every component) and packed into cluster keys (different color different normal direction)
and yes this is Thanos' face
night meadow
Current issue: some clusters have lights being assigned for one frame and not assigned the frame after resulting in a flickering black area in the bottom part of the shape
night meadow
First issue solved! It was a missing pipeline barrier: I was not synchronizing the writes to an indirect dispatch params buffer with the indirect command launch
Here I'm assigning one light to every cluster to give a cool output, BVH light search is still glitched and not presentable 😅
This is what I mean by "not presentable". Surely there's something wrong with light affection check