Vkguide 2 thread

[kind ferry]

hinting i dont know, im just forcing rgba unorm now

[lapis isle]

the annoying thing about that is that it isn't platform safe

some cards seem to have BGRA8 and some seem to have RGBA8

and it'll fail giving you the swapchain if you demand the wrong one iirc

[kind ferry]

ye :/

i can add both formats into the desired formats on vkbootstrap

https://vkguide.dev/docs/new_vkguide/chapter_2/vulkan_imgui_setup/ new imgui chapter

its pretty great that dynamic rendering is so easy to use. but im really not convinced on how im explaining it here

i think this makes it for chapter 2, just another article of hooking random shaders into imgui

i was thinking of adding window resizing here, but seems it will blat it a bit. maybe for chapter 3, and i do it by first implementing a resolution slider

[meager flume]

Are you going to overengineer the window resizing to be buttery smooth? 🐸

[drifting maple]

please show how it's actually done

i.e: device.wait_idle();

thank you

no one handles resize good

[hallow berry]

nobody needs smoof resizing

[kind ferry]

yeh it wont be smooth, i dont care enough for that

im thinking that i will implement resizing to directly reallocate swap & render, and do render resolution through shrinking the viewport. that will likely work best and its what AAA games do

[hallow berry]

you use sdl, doesnt it come with begin/end resize callbacks even, then resize vk resources at resize end

[kind ferry]

it does have the resize events but i check those from mainloop right now, so i get the out-of-date errors

[hallow berry]

ah

like vbkootstrap's demo does

i think

[kind ferry]

yeh

need to think of what dynamic state to add to chapter 3

viewport is an obvious one

dynamic depth i think is a good idea too, specially coming from gltf. but should i

the gltf materials can have depth off i think

[hallow berry]

hmm jakerino and i had a similar conversation some time ago about what counts as dynamic state

viewport/scissor definitely

would depthtest on/off,blending on/off count as dynamic state too?

it feels liek it should be baked into a pipeline

ah there you go

VK_DYNAMIC_STATE_VIEWPORT
VK_DYNAMIC_STATE_SCISSOR
VK_DYNAMIC_STATE_LINE_WIDTH
VK_DYNAMIC_STATE_DEPTH_BIAS
VK_DYNAMIC_STATE_BLEND_CONSTANTS
VK_DYNAMIC_STATE_DEPTH_BOUNDS
VK_DYNAMIC_STATE_STENCIL_COMPARE_MASK
VK_DYNAMIC_STATE_STENCIL_WRITE_MASK
VK_DYNAMIC_STATE_STENCIL_REFERENCE

[kind ferry]

hm so thats the ones you recomend?

other than line width which im never going to use, it sounds like a reasonable set

[hallow berry]

i would only pick viewport/scissor and depthbias probably

[kind ferry]

i dont do stencil stuff in vkguide

[hallow berry]

yeah

[kind ferry]

and i was thinking not only depthbias but depthtest itself

[hallow berry]

so no need to have it in there... perhaps this can be mentioned though

there is even more stuff...

VK_DYNAMIC_STATE_VIEWPORT = 0,
VK_DYNAMIC_STATE_SCISSOR = 1,
VK_DYNAMIC_STATE_LINE_WIDTH = 2,
VK_DYNAMIC_STATE_DEPTH_BIAS = 3,
VK_DYNAMIC_STATE_BLEND_CONSTANTS = 4,
VK_DYNAMIC_STATE_DEPTH_BOUNDS = 5,
VK_DYNAMIC_STATE_STENCIL_COMPARE_MASK = 6,
VK_DYNAMIC_STATE_STENCIL_WRITE_MASK = 7,
VK_DYNAMIC_STATE_STENCIL_REFERENCE = 8,
VK_DYNAMIC_STATE_CULL_MODE = 1000267000,
VK_DYNAMIC_STATE_FRONT_FACE = 1000267001,
VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY = 1000267002,
VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT = 1000267003,
VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT = 1000267004,
VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE = 1000267005,
VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE = 1000267006,
VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE = 1000267007,
VK_DYNAMIC_STATE_DEPTH_COMPARE_OP = 1000267008,
VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE = 1000267009,
VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE = 1000267010,
VK_DYNAMIC_STATE_STENCIL_OP = 1000267011,

ah

there is your depth test too

and switching topology even

hmm, so viewport/scissor/depthtest/depthbias

depth write too perhaps

[kind ferry]

yeh

can even do blend stuff on dynamic pipeline 3

but probably overkill

you would want different shaders for translucent objects anyway

[hallow berry]

yeah

and that means a whole diffrent pipeline altogehter

[kind ferry]

push constants + having multiple compute shaders for background and choosing between them with imgui

https://vkguide.dev/docs/new_vkguide/chapter_2/vulkan_pushconstants/

this makes it for chapter 2

ill now review stuff from the start and check if stuff is mostly correct before i move to chapter 3

[kind ferry]

one design question, on the push constant stuff, im just copypasting a "data" struct that has vec4s as data1, data2, etc

should i show them with different names on each shader? to make more clear that name doesnt matter, only size/layout

[lapis isle]

yeah that would be good, and clear names are always better

[kind ferry]

for ref, im doing this atm

pushconstants is just data1/2/3/4

im thinking if i should change it to have actual names, and only have the data1/2/3/4 on the cpp side

[hallow berry]

im also for proper naming

[hallow berry]

90% of our time we be reading code

[kind ferry]

the reason is that i want to have the compute shader passes all with this same 16-float layout, which means i only need to deal with 1 layout

[hallow berry]

can you not send in a mat4 then?

and call it data or payload

[kind ferry]

i could, but im binding them to imgui as edit float4s

[hallow berry]

ah

[hallow berry]

if its just a generic compute shader for this one purpose then data1-4 is probably ok too

[kind ferry]

you can change the shader

[lapis isle]

call the unused ones unused maybe

unused[n]

[hallow berry]

but please add a sentence about proper naming shit is important for any other use case

[kind ferry]

thing is that im showing how to load multiple pipelines as an array of compute-effects, which, in a way, will mimic how it will do draws later

those are pipeline + data struct

(its on the draft article)

ill have some other shaders like a fractal and something else so that the tutorial dude can try more shaders in the folder, maybe tinker with them

[drifting maple]

let me give you something good

[kind ferry]

as long as the shader works with just a mat4 properties for config, its all good

[drifting maple]

// byte bag
namespace det {
    template <typename T, typename C>
    constexpr auto __make_byte_bag_impl(T& data, uint64& offset, const C& current) noexcept -> void {
        __builtin_memcpy(&data[offset], &current, sizeof(C));
    }

    template <typename T, typename C, typename... Ts>
    constexpr auto __make_byte_bag_impl(T& data, uint64& offset, const C& current, Ts&&... args) noexcept -> void {
        __builtin_memcpy(&data[offset], &current, sizeof(C));
        __make_byte_bag_impl(data, offset += sizeof(C), args...);
    }
}

template <typename... Ts>
    requires (std::is_trivial_v<std::remove_cvref_t<Ts>> && ...)
IR_NODISCARD constexpr auto make_byte_bag(Ts&&... args) noexcept -> std::array<uint8, size_bytes_of_pack<Ts...>> {
    auto offset = 0_u64;
    auto data = std::array<uint8, size_bytes_of_pack<Ts...>>();
    det::__make_byte_bag_impl(data, offset, args...);
    return data;
}```

[kind ferry]

hell no lmao

[drifting maple]

it's epic though

[kind ferry]

if i wanted a thicker abstraction i would make the compute effect into a virtual class

where it does the pushconstants "manually" as each effect would be a class with an Edit + Draw function

[drifting maple]

you can just vkCmdPushConstants(make_byte_bag(stuff, all, your, shit, in, there))

[kind ferry]

hm thinking about it, maybe i should turn the compute shader execution into a class

basic class with a draw() + edit() function + load() which compiles the pipeline

but probs more code than i need to draw a simple bunch of random fullscreen computes

[lapis isle]

lol that's pretty neat

struct {
  float x;
  int y;
} constants {
  .x = 3.f,
  .y = 2,
};```
is what I do when I'm lazy

[drifting maple]

byte bag is king

even lazier approach

[lapis isle]

gotta get that bag 💰

[kind ferry]

so im thinking i should put the compute shader execution into a function with a class, just not virtual

bit of a refactor

some sort of "default shader" pass where it holds pipeline (layout created separately) and just takes the shader module ...

or maybe i can just not care, current approach is not bad and will be carried through the rest of the tutorial

meh, ill go through this first 3 chapters to try to polish them a bit and decide

[kind ferry]

phylosophical question

do i leave the vk_initializers.h/cpp filled as starting point

instead of having the tutorial dude copypaste it every time its used

the entire tutorial im adding new stuff to initializers but that is stuff that never changes, and will just get copypasta-d. it even gets somewhat glossed over quite often

so i can leave it already written on the starting point and just show the implementation to people to explain it

instead of being constantly, over the whole tutorial "now add this into vk_initializers"

[lapis isle]

I think it's fine to gloss over init structs and just tell people to read the docs/code if they wanna see the fields, it definitely does improve the tutorial readability

maybe even give a ref link the first time you mention a struct like VkSubmitInfo

the one thing I do remember is that when I was in the stage of extending vkguide code into my own thing, relying on vk_initializers without looking at the spec made me miss the existence of some fields I needed

truly a skill issue but I think a good big picture goal is to help take the training wheels off on checking the spec

[kind ferry]

oh, i really like the idea of directly pointing to docs for the first mention of each of them

i think that solves it, prewritten vk-inits plus pointing to the spec on each new struct and function used

[lapis isle]

maybe even for the functions too

oh nvm you said that

[kind ferry]

functions are less useful i think

most of the time is like "ok this function takes a VkWhateverFunctionInfo"

so pointing to the function itself is less value

still its not like it takes space

[hallow berry]

we do that in learnd3d11 too iirc

[kind ferry]

chapters 012 are now tweaked a bit

i improved a few things and fixed typos/etc

[lilac oak]

@kind ferry this shader from Shadertoy is neat
https://github.com/Devsh-Graphics-Programming/GPU-With-C-Sharp-Angular-WASM/blob/master/data/shader.frag

uniform sampler2D iChannel0;             // input channel. XX = 2D/Cube
uniform samplerCube iChannel1;           // input channel. XX = 2D/Cube
uniform ivec2 iResolution;     // viewport resolution (in pixels)
uniform vec2 iMouse;                // mouse pixel coords. xy: current (if MLB down)
uniform float iTime;                 // shader playback time (in seconds)
uniform int iEnv;
uniform float iFramesRcp; // 1/(current frame number)

if you throw out iChannel0 then you just disable accumulation (although you could just make your compute texture readwrite)

and iChannel1 is a cubemap but you could just make the envmap procedural

https://www.shadertoy.com/view/4ddcRn

[kind ferry]

im really not happy with the current shaders build target

what do you think if i add a python script to build the shaders?

would it make sense to have that in the tutorial. just a very basic thing that recalcs all shaders when triggered

[hallow berry]

:S

[kind ferry]

thing is that current cmake based builder requires you to re-run the configurator when adding new shader files

[hallow berry]

if its invoked by cmake then its fine

[kind ferry]

yeh thats the idea

[hallow berry]

hmm

[kind ferry]

i could do it in a .bat

but then it wouldnt be multiplat

[hallow berry]

like glad generates its bindings via some python during configure

ye .bat and .sh

and .it 😄

then you get bat sh it 😄

[lapis isle]

I think a python script would be a big point of failure esp. for people on windows

[kind ferry]

what im thinking is to still have the shaders cmake target, but also run the compile script from the normal engine executable

and if you manually compile shaders target it does forced rebuild

else it checks timestamps

[lapis isle]

I think the GLOB_RECURSE is an antipattern in 'good' CMake usage though

you'd never do it for cpp sources for example

[kind ferry]

telling peeople to go add the shaders one by one into cmake is even worse

there is an alternative choice. i could compile the shaders from the engine.exe on launch

by directly calling into console command

or maybe just providing the code that links into glslang stuff

[lapis isle]

that's crusty and/or cumbersome

[kind ferry]

i do worry about the python on windows case

[lapis isle]

linking against the compiler is at least correct

[hallow berry]

i build shaders during build with custom command

[kind ferry]

i do expect essentially every single dude gonna have python

[lapis isle]

and you can ship it as a submodule

[kind ferry]

but still

[lapis isle]

or fetchcontent

[hallow berry]

and just invoke glslvalidator or whats it called on all *.vs.glsl and *.fs.glsl

[lapis isle]

you might have python but do you have it in your path by default

I think installing python on windows doesn't put it into the path by default

it's been forever since I checked

[hallow berry]

it needs to be checked, during install

[kind ferry]

glslang stuff is provided by the sdk

i can have it added with 0 friction

downside is that im adding extra code to the chapter-0 stuff for the shader recompile

but, in a way, that could be a good idea

then maybe i could show how to hotreload shaders

[lusty hound]

LETS GOOO

[lapis isle]

it's pretty self contained "don't worry about it" code, so I don't think it's a bad idea

call glslang -> get uint32_t array

[kind ferry]

no, it must write the shader files to disk

i really dont want to get people used to just grabbing the glsl in the engine at runtime

[lapis isle]

oh yeah true

if you wanna develop best practices, perhaps making people add their shaders as source files is the real winner?

[hallow berry]

i also hate shaders embedded as strings

also vb is right, python should NOT be a big problem

people who do GP should know how to install a thing like python

if they cant then GP is not for them tbh

[lapis isle]

yeah

[hallow berry]

[Install Python](linktopython) should be alright in the guide

[lapis isle]

the great filter

I don't even think you need to link python

this is like the gentlest filter

[kind ferry]

another nice detail is that if i have python i could show how to run scripts that process gltf files or other things of that sort

important to have a way to run meshoptimizer

[lapis isle]

don't people usually link meshopt in their programs

[kind ferry]

yes, but its much better to run its gltfpack or others offline

to precalc all that stuff

[hallow berry]

everyone cooks their own shit together : )

perhaps have a custom target for all that o ffline cooking

so that i can do all that from within my cmake tools

those can invoke scripts/this_and_that.sh

[lapis isle]

I think one of the first things I did was have the exe depend on the shader target in vkguide

was annoying to ninja shaders separately

[hallow berry]

ye

im also annoyed that shaders are end in .vert .frag and .whatnot

i like them to be .vs.glsl .fs.glsl and so forth

so that the fucking highlighters and linters and whatnot work properly

[lapis isle]

my nvim highlighter handles those, I had to modify it for glh though

also had to mess with the custom commands a bit to have glslang generate depfiles so I could properly track recompiles from editing shader headers

[hallow berry]

heh

for some reason in my vkguide journey, cmake only builds shaders when they were changed

almost 1:1 vkguide i think

find_program(GLSL_VALIDATOR glslangValidator PATHS $ENV{VULKAN_SDK}/bin REQUIRED)

file(GLOB_RECURSE GLSL_SOURCE_FILES
    "${PROJECT_SOURCE_DIR}/data/shaders/*vs.glsl"
    )

foreach(GLSL ${GLSL_SOURCE_FILES})
    message(STATUS "Building Shaders")
    get_filename_component(FILE_NAME ${GLSL} NAME)
    set(SPIRV "${PROJECT_SOURCE_DIR}/data/shaders/${FILE_NAME}.spv")
    message(STATUS ${GLSL})
    add_custom_command(
        OUTPUT ${SPIRV}
        COMMAND ${GLSL_VALIDATOR} -V -S vert ${GLSL} -o ${SPIRV}
        DEPENDS ${GLSL})
    list(APPEND SPIRV_BINARY_FILES ${SPIRV})
endforeach(GLSL)
``` and the same block again for fragment shaders

[hidden cove]

(Chiming in b/c I'm finally working through vkguide right now & stumbled on this thread)
I personally find the current CMake setup really nice & easy, despite needing to reload the shader target when adding new files. Especially since glslangvalidator is provided by the SDK anyway

It was also easy enough for me to copy/paste the cmake snippet to find & compile HLSL shaders too, since dxc is provided by the sdk too

[kind ferry]

yeh, but the issue is that if you want to reload shaders you must do it from vs

thats a bit of a wonky thing to do...

and reloading the cmake to add files is something ive always disliked a lot

[hidden cove]

Fair enough, I hadn't considered that some people only have cmake available via IDE

[hallow berry]

tbf, why would people add shaders to vkguide all the time

they are supposed to go through and learn and then do whatever they want later

you could make it an exercise and leave it to the reader

[kind ferry]

because during the tutorial i will add more shaders myself @hallow berry

[hallow berry]

that should still be fine

[kind ferry]

]

the new cpp20 initializers are handy sometimes

[kind ferry]

what do you think of pipeline builder 2

viewport and scissor are always dynamic

[drifting maple]

why does the pipeline take image formats wat

[kind ferry]

dynamic rendering my man

before you had to give it the renderpass

which would contain the attachment info

i like this one more than the older one with the vk-initializer spam

much less space taken and can split things

[drifting maple]

o

makes sense

[kind ferry]

now that i think maybe the set_depthtest function should set depth format too

[hallow berry]

turn this into a .set_xxx too then we are good

[kind ferry]

dang symmetry

i always dislike dumb setters XD

[meager flume]

why the set_multisampling_none(), etc?

Otherwise it's similar to mine ^^

[hallow berry]

none makes sense, you could also call it disable_multisampling, or disable_culling and be more semantic about it, but then it would be a mix of set_xxx and other things, which you probably ont like, im also not completely happy about it

[kind ferry]

needs to set sample to 1 and other similar defaults

im calling them all with the same type of name

idea is that laetr you would have set_multisampling(4) or similar

same thing with the cull

[hallow berry]

id have a separate builder method for that : )

enable_multisampling(4)

[kind ferry]

oh, but thats what i mean

[hallow berry]

its just me

[kind ferry]

you have set_multisampling_none() and set_multisampling(4)

hm, that makes sense

enable/disable semantics on those

[hallow berry]

im not convinced 100% myself, because fluent api would even be better, but requires more code infrastructure which is probably not what you want anyway

.enable_multisampling().with(4).samples()

leaving it as set_xxx should be enough for the guide

its quite a bikesheddy topic 🙂

[kind ferry]

its not even a real builder after all 😛

[hallow berry]

ye but it doesnt have to be an ugly fake one either 😛

[meager flume]

Sorry for late response after starting the bikeshedding

Just not a fan of two methods that do the same thing when you could just set_multisampling(1), set_depthtest(false), etc

People also keep getting surprised (myself included) that disabling depth test also disables depth write

[hallow berry]

the latter could be split into two things then

i also have Disable/Enable DepthTest/DepthWrite as separate things in my engine

my main grief with code like "set_multisampling(1)" is simply readability

we, coders, read source code 90% of time working on code

and only spend very little time actually writing code, thats why code should be as readable as possible and help the brain rather than have the brain guess what is what

idk, im also just saying, ive been reading source code for too long already, and im fed up with spaghetti 😄

[meager flume]

personally they both convey the same meaning and are just as readable for me, but ymmv

If anything in my lib you need to do setMultisampling(tp::MultisampleLevel::x1)

[hallow berry]

yeah

personal preference at the end

[meager flume]

I just realized I'm doing a dumb

In my code that first parameter is optional and defaulted to x1

[hallow berry]

: D

[meager flume]

So you could write setMultisampling() to disable it

Which is just... no

[hallow berry]

which feels wrong in that case hehe

gottem!

[kind ferry]

tfw vkinitializers loses like 200 lines worth of pipeline bs

good change honestly

tho i will go through the structures in the tutorial to explain their properties

im thinking how much should i have on chapter 3 and 4. i know 5 is the full gltf load, and 3 is pipelines. but just drawing the triangle wont take much. maybe slam the stuff with descriptor sets and uniform buffers there? gotta have to store vertex buffers after all

im also thinking if i should use BDA directly

for mesh data loads

[hallow berry]

the hello triangle will show how to do it without bda, then bda from there onwards

if people want to still use non bda, then they should know how

[kind ferry]

ofc. hello triangle actually starts from hardcoded triangle

and in regards to hardcoded triangle

what do you think of setting up a fullscreen-triangle function?

to use instead of a vkcmd blit

[hallow berry]

its widely used everywhere, should be a good thing to do here as well

[kind ferry]

i think it makes a fair bit of sense to set it up, after all can go later and add the tonemap there or similar

[hallow berry]

yeah

[kind ferry]

this should work no?

i was refacting some stuff but for some reason its not blending

while this thing should be doing a "pure additive" blend 🤔

[lapis isle]

shouldn't it be VK_BLEND_FACTOR_SRC_COLOR and VK_BLEND_FACTOR_DST_COLOR

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkBlendFactor.html

[lapis isle]

I think the result of that is "always write (2, 2, 2)"

[kind ferry]

according to renderdoc its ok

yes but im getting normal rendering

as if there is no blending

but wtf is going on because renderdoc is going "yeh this is fine"

[lapis isle]

maybe its not a valid combo

[kind ferry]

been trying a few random combinations and nothing seems to be doing anything which is incredibly strange

im weirded out because im seeing the blend stuff changing in renderdoc and yet.. the image is always the exact same

i wonder if im running into some sort of caching bug somewhere

[lapis isle]

and this doesn't even work right with src alpha and 1 - src alpha?

[kind ferry]

absolutely nothing matters

the strange thing that has me baffled is that the settings are there on renderdoc

hm seems i have some layer error on a compute pipeline that runs before this (only at pipeline creation), i wonder if its something getting megafuckd in the background

copying code backwards and forwads between the multiple chapters is kind of messy...

[kind ferry]

fixed the validation and it still doesnt work. real odd stuff here

[kind ferry]

bit of a design question

for the actual renderer, im currently storing a "bIsTransparent" on my material structure

but im thinking maybe thats not the correct way

what do you think of storing the transparent flag in the surface itself?

should transparency be a property of the material, stored with the pipeline, or should it be a part of the mesh itself

[lapis isle]

I remember discussing this on this server like a year ago, and I was given the recommendation that a "transparent" material is just a different type of material altogether

so in short yeah, it should be a property of the material

[kind ferry]

this is the reason whyt

im looking into the scene rendering to check what i can pick for the chapter 4 and chapter 3 so that stuff is built gradually

[lapis isle]

are surfaces what gltf calls primitives?

[kind ferry]

kinda

its my "draw" basically

one mesh has multiple of them

but its not 1 to 1 to primitives because stuff like shadows would also generate them

sorry. misread. yes, surfaces are gltf primitives

one possibility is to hold a bitfield per surface of what passes does it render to

so i would have one bit for mainpass and another for transparent

and then possible one for shadows and other for depth prepass

[lapis isle]

I can see why that'd make sense for shadows

but things aren't mutually transparent and opaque

that's a property of their material type

"PBR Opaque" and "PBR Transparent" are 2 materials to me, for example

[kind ferry]

yeh they are 2 materials

thing is about the pipelines per pass

like maybe a material should be a set of pipelines here

so for transparent objects their "main pass" pipeline slot would be null

[lapis isle]

it's kinda reassuring that you're having as much trouble architecting that as I did lol

what I came up with is having pipelines be grouped into an object called a "MaterialPass" which has a MaterialPassType which is either Opaque or Transparent

and they have various functions: indirect_cull, render_forward, render_depth_only, and render_shadow

they also own all the buffers related to objects of this given material

then in my main renderer, during my cull pass I invoke the indirect_cull of all registered material passes, then the same thing for all other passes as needed

[kind ferry]

thats what i do for indirect too

but this is before going to that level

[kind ferry]

the error i had above happened because the render info was badly put on the pipeline (i created the pipelines with 0 color attachments)

yet layers did not have a check for it, and the driver didnt care. so blending was broken but everything else was rendering no issues

[lapis isle]

0 color attachments is a valid pipeline

I don't know where the best point for validation to catch that would be, either

[meager flume]

It shouldn't be valid to use it while rendering with color attachments bound, though

Unless you have VK_EXT_dynamic_rendering_unused_attachments maybe

[lapis isle]

is renderpass-pipeline compatibility strictly equal?

or is a 0-attachment pipeline compatible with a nonzero-attachment subpass/dynamic rendering

[meager flume]

When it comes to attachment count, they are strictly equal afaik

[kind ferry]

its a 0-attachment pipeline but which has 1 pixel color output in the shader correctly

used from within a renderpass (dynamic) with 1 color attachment

[meager flume]

That's ok, but should produce a warning

[lapis isle]

then I'd suspect that's a layer bug since that should be easy to catch?

[kind ferry]

@meager flume how is that possibly ok?

having the shader output to attachment but the pipeline having no output attachment

[lapis isle]

yeah I see 2 cases here

either A) the layer warns you the pipeline attachments are incompatible with the renderpass, or B) the layer warns you your shader is incompatible with your pipeline

or both

[meager flume]

You effectively declare that the output is unused

It's quite useful to avoid having multiple shader variants that output different combination of things (normals, motion vectors, etc)

It at least used to produce a perf warning when you did that, but I can't see it anymore

[kind ferry]

i see

my issue is that then i was rendering with this pipeline

and it worked

i had 0 color formats but the renderpass was being written. but with no blending. blending was fuck-d

i even have the renderdoc capture lol

[meager flume]

Yeah, the renderpasses not being compatible should have been caught

Validation <101294395|UNASSIGNED-CoreValidation-Shader-OutputNotConsumed> : Validation Warning: [ UNASSIGNED-CoreValidation-Shader-OutputNotConsumed ] Object 0: handle = 0x2b17b0000005209, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x609a13b | fragment shader writes to output location 1 with no matching attachment
Here, I found it in old logs

[kind ferry]

but i had all warnings enabled 🤔

[meager flume]

Nevermind it hasn't

[kind ferry]

also is that with no attachment on renderpass or in the pipeline

[meager flume]

both

no attachment in the pipeline, but attachment in subpass should always scream

[kind ferry]

revisiting and preparing chapter 3 (triangle) im thinking i will do BDA for mesh buffers fairly early

dealing with the descriptor sets per-mesh and similar is kind of ass

another im thinking is removing the pipeline layout stuff. doing a good ol hash&cache

so that creating new materials is a bit easier as can be on a function where it takes the 2 shader modules and does the options

[crimson timber]

yes

do it

[crimson timber]

i dont like the idea of hash n cache for this

[drifting maple]

full bindless

is the only way through

[lapis isle]

hash n cache for pipeline layouts is good, but it only makes sense if you have shader reflection

so that's 2 unnecessary moving parts for tutorial code

at least to push up front

[kind ferry]

im considering putting the shaders into a hashmap, VkShaderModules

by name

so that my pipeline logic first loads a bunch of shaders and then i have a create-pipeline type thing that just takes 2 shaders by name

or maybe thats not a good idea as its different from how i build the compute shader..

[lapis isle]

I also don't think that reflects the direction vulkan wants to go

iirc one of the newest maintenance exts allows you to circumvent creating shader modules entirely, and add shader module create info directly into your pipeline create info

shader modules are kinda useless if you think about it, so I'd advise people to not treat them as first class vulkan crap

[kind ferry]

hm good point

i could just load them from file on demand, even multiple times

they are smol files after all

[crimson timber]

shadermodules are deprecated

[kind ferry]

i could update the tutorial removing them

[crimson timber]

yes

[kind ferry]

any link to that maintenance ext/whatever?

is it part of 1.3 core

[crimson timber]

yea i dont remember which one

[kind ferry]

i dont use any extension right now

[crimson timber]

i think its core

[lapis isle]

is it m5?

ah yep

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_maintenance5.html

I don't see if m5 is core in 1.3

[onyx bridge]

it isn't

it was released after 1.3

[kind ferry]

aw man

kind of a shame then

this was perfect for my needs

[lapis isle]

good to teach people how to enable extensions

plus it's just maintance

this is the future™️

[kind ferry]

because i can begin by loading every single .spv file from the shader folder into std vectors

and just send those to the pipeline

nah man i want to keep this core... @lapis isle

[lapis isle]

rip

still though you can build your API like that

and just hide shader module creation as a transient thing inside the pipeline creation

[kind ferry]

thats what im doing right now

the "Create pipeline"
function loads the shader file and creates shader module, then deletes it at the end

i currently have a good plan for chapter 3 but chapter 4 is a bit on the ?? right now

not fully sure on it

my idea is that it would build the render structures that the gltf will need later

[kind ferry]

https://vkguide.dev/docs/new_vkguide/chapter_3/building_pipeline/

draft pipeline chapter

what do you think? i might be doing stuff a bit out of order? maybe split the first part (explaining the whole pipeline create info) into another article?

first explain the pipeline create info and its settings as an overview, then create the pipeline builder with a few abstractions (its missing stuff that will be added later like depth-test), and then hook it all to draw the hardcoded triangle

my main worry with it is that maybe the abstractions of the builder and what the settings do is completely unclear, im really skipping a huge amount here

after thinking about it the rest of chapter 3 will explain more pipeline options, and setup mesh rendering

but without the fancy abstraction layers that will be built for mesh objects and the likes, just hardcoded

[lapis isle]

I think it's fine, it's an info dump but that's just how setting up the graphics pipeline is

I think vulkan-tutorial actually does a good job here with their little diagram

https://vulkan-tutorial.com/Drawing_a_triangle/Graphics_pipeline_basics/Introduction

also lol they split it into 5 parts

they also seem to go in programmable vs fixed order instead of pipeline order

[kind ferry]

i dont need to explain shader modules (was done before for compute), nor renderpasses

so really mine is just the fixed function part

i have a diagram in my odler version, ill definitely add it back

[kind ferry]

you know what, passing BDA pointer for vertex buffer into the models works.. great

it actually removes the descriptor set i had for meshes, makes things a fair bit easier, and scales later to do instancing and indirect

i think ill do a buffer first and then demonstrate BDA for meshes

after the main timeline then ill have the classic big-buffer-for-all-meshes and that will contain the bda pointer to mesh

[kind ferry]

after thinking for a while i wont be doing dynamic descriptors

vertex buffer passed by BDA, material buffer a bound SSBO where index (through pushconstant) will index material params

and index buffer as a really big preallocated buffer and then suballocated from with VMA magic

but index buffer trickery will be done later, when going with draw indirect

[kind ferry]

chapter 3 is done

and i also have an article on blending

[kind ferry]

ill begin chapter 4, which will be setting up depth buffer, and setting up the render architecture

c5 being dedicated purely to gltf

[kind ferry]

ended up adding the more advanced abstractions of the descriptor stuff to chapter 4

[kind ferry]

https://vkguide.dev/docs/new_vkguide/chapter_4/engine_arch/

explainng the basic render arch that the tutorial engine will use

[kind ferry]

rate my material system

im thinking its just going to be structs like this with the hardcoded logic per material type

fairly easy to also add shadow version by just adding another MaterialPipeline for a different pass type

[hallow berry]

i think this should be fine

the tabs are more irritating

[fringe berry]

wat

[meager flume]

I assume MaterialPass then selects opaque vs transparent and such?

What does MaterialData store?

[hallow berry]

MaterialData sounds like the gpu version of MaterialConstants/MaterialResources

[meager flume]

Yeah but then tying a descriptor set to a particular pipeline selection doesn't sound the best when you can usually reuse the same set for many different configurations

[kind ferry]

a MaterialData is basically the min data i need for a given material in the draw loop

so pointer to pipeline+layout, descriptor set for the material, and passType which will be useful for some other stuff, as it handles if the thing is transparent or opaque

[meager flume]

So you have a separate descriptor set for opaque and transparent

[kind ferry]

yes

opaque and transparent will have different textures and so on

just because that material has the 2 pipelines it doesnt mean a given mesh will draw with both

it will only use one of them

[meager flume]

Maybe, but when you add shadows, depth pre-pass, motion pass and whatever else

All of them will necessarily have a different desc. set

[kind ferry]

yes

its fine because this descriptor set is temporal only

by the time i add shadows, prepass, etc it will be bindless and i wont need that descriptor set anymore

[meager flume]

ah alright

[kind ferry]

for the base chapters (up to chapter 5, loading gltf) it will be 2 descriptor sets

a global one for camera data and the likes, and a per-material one with the textures

[fringe berry]

So in this case GLTFMetallic_Roughness is the material as a whole, and MaterialData is the "instance" of a material that actually gets applied to an object?

[kind ferry]

and a shadow pass would have a different descriptor set, for example it only needs the color texture (for alpha testing) , but not the roughness/emmisive/etc others

yes @fringe berry

thats the idea

when a GLTF is loaded, a MaterialData is saved per-object

well, per gltf material, really

this is how the GLTF mat is loaded

sorry for the incredibly cursed mixed tabs/spaces, my vs config is a total mess right now

[hallow berry]

i also dont mind that

that "striving for reuse" is just a possible optimization

[kind ferry]

there isnt that much reuse, the descriptor for a main view isnt the same as a shadow view

[hallow berry]

yeah

[hallow berry]

illallowit.gif

[meager flume]

I mean there is very little downside in including all the other textures as well and it saves you managing multiple descriptor sets

[kind ferry]

reasonable

[meager flume]

Allows you to reuse the same pipeline layout as well

[kind ferry]

if i didnt switch to bindless so quickly i probably would try that

[kind ferry]

MaterialData as name is honestly completely awful, ill change it to MaterialInstance

chapter 4 is almost done now, but im not completely happy with the flow. too much code, too little things happening. but its kind of.. the point of the chapter

ill finish the chapter and then see if i can rearrange things a bit, maybe moving stuff between chapter 3 and 4

[kind ferry]

i think ill move depth buffer setup and a 3d camera matrix into chapter 3 as 4 is feeling bloated a bit

that way 4 is mostly about textures and material system and scaling up

[hallow berry]

i prefix my constructs which live on the gpu with Gpu : ) ie GpuMaterial

[lapis isle]

for me that'd probably just be the struct that defines the memory layout on the GPU and not necessarily the handle or CPU-side data for it

so a MaterialInstance might be transfered to the GPU as a GPUMaterial which is actually laid out like the GPU would read it

[hallow berry]

naming is hard

[kind ferry]

a MaterialInstance is not really that pure of a gpu structure

i prefer the GPU prefix on data that will be put on a uniform

rate my mesh loading format

[kind ferry]

there we go, mesh loading with 3 primitives. Cube, Sphere, and Suzzane (monkey)

alternatively, i could do badly-loaded GLTF isntead (where i just load first mesh and first primitive in mesh)

what do you think?

[hallow berry]

i appreciate the vertex type

so that Cube_vtx isnt just float[]

[kind ferry]

im thinking that while this is cool, maybe i should begin loading a mesh-gltf

[hallow berry]

yeah

[kind ferry]

that way it can then continue making another loader later that does the "full" thing

[hallow berry]

i dont think thre is a point of having a hard coded cube

[kind ferry]

mesh-only gltf is simpler to load than even obj

just grab meshes[0] primitive[0] and loop accessors

[hallow berry]

obj is not worth it anyway

[kind ferry]

yeh

im going to consider changing chapter 3 to do the gltf load at the end, when vertex buffers get shown

and see how would that look

[hallow berry]

oki

i should replay vkguide2 here next weekend

so if what you made makes sense hehe

[kind ferry]

replay?

[hallow berry]

work it through myself

[kind ferry]

ah ok

for next weekend ill have chapter 4 probably done and some tweaks to chapter 3 too, so should be somewhat followable

[hallow berry]

im only at memory transfer descriptor sets in vkg1, right febore textures

[kind ferry]

current vkguide2 is a bit ahead of that

[hallow berry]

i hope i dont have to travel next weekend already, i really dont want to

thats fine

[kind ferry]

at the moment its actually somewhat equivalent to full vkguide 1

[hallow berry]

noice

[kind ferry]

with chapter 4 full it will be parity

[hallow berry]

sounds good

[kind ferry]

yeh ill change to load from gltf as simple mesh. it will work better and act as a improved progression towards the full load

[hallow berry]

henlo tringle should be enough to see how you can manually load a vb with vertex data

[drifting maple]

All these guides are making me want to write my own guide except it's Vulkan strictly using the most bleeding edge of features

Like zero descriptor sets, mesh shaders & stuff

[kind ferry]

thats what vkguide 2 is doing (almost)

like, i dont even show vertex buffers

but btw a full bindless guide/tutorial would be useful

the bindless chapter in vkguide 1 is the most popular page

[drifting maple]

ye but it's still using the crusty old VTG pipeline

maybe I'll make a pull request for a ultra epic, fully bindless, fully gpu driven engine

[kind ferry]

on chapter 6 i will be going bindless textures and some indirect shanenigans

but it will be a while until there as the 5 chapters polished is more important

ive also thought of converting the vkguide website into a bit more of a blog type thing

and allow guest articles

[drifting maple]

what would one use to make such guide websites automagically

I don't want to write CSS and HTML myself ideally

[kind ferry]

it uses github sites

its all just markdown

https://raw.githubusercontent.com/vblanco20-1/vulkan-guide/master/docs/chapter-3/push_constants.md

its about as trivial as it gets

[drifting maple]

damn

that's great

[lapis isle]

so what do you use to actually make it into a website

as in what compiles your md to HTML/CSS

[kind ferry]

thats jekyll, a ruby abomination

supported more or less default by github

[lapis isle]

oh

[kind ferry]

and it all just ends up as raw html with maybe a lil bit of js

thats why vkguide loads so incredibly quickly on so little space

most github sites are like this. jekyll just generates ultra thin pages by default

there is no server, its just completely static html hosting, so you cant go insane with the js scripts

[drifting maple]

that's great, a guide doesn't need that stuff really

[lapis isle]

my github site is raw html because I didn't know a better way lol

[drifting maple]

ok so the plan is as follows

1st chapter. initializing vulkan and basic infrastructure
2nd chapter. mesh shader triangle
3rd chapter. loading bistro & bindless
4th chapter. DLSS/FSR2 & cluster culling
5th chapter. VSM
6th chapter. RTGI

[kind ferry]

who is the target for it?

[drifting maple]

the target up until the 3rd chapter is people who have completed vkguide and know their way around vulkan, wanting to go even further

then from 4th chapter onward is just me dumping features in the guide for those who like them

[crimson timber]

vsm

mmmm

[drifting maple]

you think RT shadows maybe fit better?

I will mostly be showcasing what I've learnt from daxa, vkguide and stuff

so credits will be given to you frogs

~~basically an ad for potrick and vkguide ~~

[kind ferry]

ok so a "bindless guide" for people who already know vulkan

seems about right, can be useful as a reference

[drifting maple]

ye

[meager flume]

Has anyone done full RT pipelines at scale yet? With managing the pipeline libraries and shader binding groups and such

[onyx bridge]

ue5 vulkan 🐸

[lapis isle]

I think potrick is underway with doing that in daxa

[meager flume]

Cool if so

[crimson timber]

I might be on the path of rays

[kind ferry]

pipeline libraries are ez just go bindless and have 2 materials tops

[meager flume]

I don't think non-bindless is even an alternative with rt

from what I understand you bind desc. sets for the entire pipeline, not per material

[kind ferry]

lol

tho kinda related to that, reflections are kinda the most boring RT effect to add :/

i think stuff like shadows and GI with restir type stuff is more interesting

first ray effects i implemented were ray sun shadows and ray AO

[lapis isle]

shadows are about as simple as reflections though

idk about how you'd do ray AO or restir GI but they seem considerably more involved and their own tutorial set

[kind ferry]

ray ao is kinda just "randomly throw rays every pixel up to a radius, then denoise it with a blur"

[onyx bridge]

shadows are much simpler

[kind ferry]

ray ao is basically same difficulty as normal SSAO

because normal SSAO is also noisy and you do temporal accumulation/blur to fix it

[lapis isle]

yeah I guess launching an anyhit towards a light is way simpler than actually dealing with the result of a reflection

[kind ferry]

the hard part with shadows is implementing stuff like not launching rays for stuff that is fully on shadow

just throwing 1 ray into the sun per pixel is the easy mode but you can get 2-4x faster than that by being smarter

[lapis isle]

what do you do for that? do you render a low res shadowmap or something

[kind ferry]

one of the ways is to divide the scene on 4x4 pixel tiles, if all 4 are fully in sun or fully in shadow, you only trace 1 ray per block. On penumbra areas you throw more rays

you reproject these things every frame as the camera moves, and on the dissocluded zones you throw full rays

thats the TLDR version

then there is the omegagigabrain RESTIR version from nvidia which i dont understand, but lets you do that sort of thing with a ultra huge light count

[lapis isle]

oh so basically you have a texture with history data and decide occlusion from that

[kind ferry]

pretty much

on history that is stable you throw less rays

[drifting maple]

is the history just the shadow mask

[kind ferry]

depends on the technique

i dont know it in detail only read the basic thing from the articles and the ray tracing gems book

[lapis isle]

I think I should read that book, I've just been screwing around with BVHs instead of actually using raytracing for anything lol

[drifting maple]

For my guide I'll just do HWRT lol

but maybe a persistent thread based, compute only RT pipeline could be fun

[kind ferry]

one technique i like a lot with hw rt is DDGI

its just such level of hax for a nice GI implementation

and seems to be super easy

you just have a grid of probes. the probes use rays to get probe info. Thats it

only re-trace the probes as you move around or the ones around dynamic objects as you want

if you are feeling really fancy you can also do like lumen, and spawn probes from the camera point of view into objects on the z-buffer

[lapis isle]

that does sound really cool, idk how to even begin implementing that though

[kind ferry]

and project them around

[drifting maple]

https://ye-yuan.com/DSGPURayTracing/

check this out

[lapis isle]

this had me at GTX 680

[drifting maple]

we are now witnessing the formation of a brainworm live gentlemen

[meager flume]

It sounds fun but will it really see much use with hwrt getting more and more widespread?

[kind ferry]

maybe on amd cards

[lapis isle]

my gtx 760 won't grow hardware rt no matter how much time passes

so it'll at least be worthwhile for me

[meager flume]

at least with compute raster you get to win against hw

fair fair

[drifting maple]

just inject RT cores

[lusty hound]

Consider using SterRToids

[kind ferry]

new chapter 3 with gltf mesh loads even if crappy + pushconstants object matrix + depthbuffer is a definite improvement

[civic mantle]

Totally didn't pin stuff before realizing the link to the rendered version is available on the main site....

[kind ferry]

negative viewport for flip or matrix on the gltfs?

[lapis isle]

negate the y on the projection matrix, is that an option

[kind ferry]

yes, thats what i do

chapter 3 is now a bit different but i consider it an upgrade

now time to finish 4

[hallow berry]

i liked negative viewport more

[tawdry sable]

You guys fix your coordinate systems?

[hallow berry]

too ambiguous, can you rephrase

[tawdry sable]

uhhh

[hallow berry]

sigh

do you mean

a) what the outcome of the former discussion was

[tawdry sable]

yep

[hallow berry]

b) if individuals here fix their coord systems, using method 1 or 2

[tawdry sable]

as in

[hallow berry]

i suppose its projection[1][1] *= -1 since its what vb wrote

[tawdry sable]

every third party uses some different coord system

and you could standardize it within your engine

[hallow berry]

its not an engine though

just something showing how to get into vk

[tawdry sable]

engine, game, app, whatever

im making the joke that I don't lol and I just convert wherever i need to

[hallow berry]

since there are multitude ways of doing things you can use whatever i suppose

its all ugly : )

because api designers wanted to be special or were mathematicians and not computer people

[tawdry sable]

yep

[kind ferry]

chapter 4 is now basically done

lots of changes on 3-4

gonna do a bit of a review pass as its likely code has desynced heavily

[kind ferry]

https://vkguide.dev/docs/new_vkguide/chapter_5/gltf_nodes/

chapter 5 is now done

at least, the main part

which means the tutorial is now "done" for the basic track

[hallow berry]

🎉

[kind ferry]

ill still add a couple more articles to chapter 5 to optimize a few things. Specifically, improving barriers for the draw logic, adding the transparent draws to the gltf, and not calling VkBindPipeline every single draw (check that its a different one)

[kind ferry]

made a bunch of tweaks to chapters 3-4-5 so its now a fair bit improved

likely followable right now

[kind ferry]

now i need you to try reading/following it and let me know of the issues/wonkyness/etc. i have issues reviewing it myself due to bias

[kind ferry]

gonna give it some frustrum culling and transparency depth sort

looking at it the lack of frustrum culling is just.. so crappy

with the current architecture i cant really have the fast culling due to it being a node-walk, but i can do a basic IsVisible check on the mesh nodes to decide wether to add the draw or not

that can kinda show the concept of how culling can be done, and it can do the much faster flat frustrum cull when i do the caching thing

[kind ferry]

ok all hyperlinks between articles should now work

ended up adding it into the mark down generator

doing every link manually is super annoying

[low minnow]

I want to clean up a few things around the glTF chapters, can I just send all of my stuff as PRs to the normal repository?

and the source for the markdown text is just on master under vkguide_new_source?

[kind ferry]

did you see the coments by that guy who did a lot of small fixes?

im already going through that list

[low minnow]

I didn't read through all of that tbh, just thought it was spam

[kind ferry]

there is likely overlap

[low minnow]

yes most likely

ill read through the comments

[kind ferry]

the markdown is a bit more complicated. it uses a generator

but i can run it myself after merging the pr

[low minnow]

eh I'm sure I can figure out how to generate it too

[kind ferry]

the code of the generator is not published

tho chapter 5 in particular doesnt use the generator properly yet as im fixing it

generally you will see in the markdowns stuff like ^code init_logic chapter-2/vk_engine.cpp

thats basically "go open chapter-2/engine.cpp, find the init_logic tag, and copypaste it"

[low minnow]

ah, interesting

[kind ferry]

chapter 5 i was still modifying the code a bit so most of its code snippets are just code snippets, without the copypasting codegen

but every other chapter has almost all code snippets done that way

so yeh.. dont touch chapter 5 yet, im working on it right now

wait a few days

[low minnow]

Never used this library so a lot of this stuff was new to me. I also was wondering if there was a way to query indices and vertices size from fastgltf so you can resize the vectors accordingly.
It would be a good idea to const the accessors.

this was the only thing MasterDrake said specifically to fastgltf, right?

[low minnow]

hmm ok

[kind ferry]

example

@low minnow i had the resizing done before

i changed it to be push back precisely because i wanted to initialize the vertices properly vs the 0init of the std vector resize

[low minnow]

well, I mainly thought of using reserve

[kind ferry]

ill add the reserve myself, i had it done before

(see those //> and //< tags

[low minnow]

yup, very interesting way to do this

but formatting is way off sometimes, which was one of my main points I wanted to fix

also the gltfOptions should probably be on multiple lines

[kind ferry]

ah that i can fix no issue

[low minnow]

well just mention me when you got the PR up and I'll review that & open another PR with specific fixes for fastgltf

for now, i might work on a Vulkan example in fastgltf

[kind ferry]

what are the specific fixes you want to do?

better if i just do them myself as part of the tweaking when i fix a few things on c5

[low minnow]

• there was some things mentioned about gltf and fastgltf which were simply wrong
• LoadExternalImages is an option which would simplify the texture loading chapter

2 main points, nothing drastic

[kind ferry]

but i dont want to do the external images thing, i have the code on load image that loads from a path

[low minnow]

external images options is just like external buffers

you'll remove one branch of the std::visit call

then youll only have to care about sources::Vector and sources::BufferView

[kind ferry]

yes but things like Bistro are a couple gbs of images

with load external images the program now uses +2-3 gbs of ram to run

[low minnow]

hmm ok sure

[kind ferry]

by loading them myself i avoid that because its directly calling stb to open file, load it, and unload memory

what are the things that are wrong? thats important things to fix

[low minnow]

only thing I remember right now is this line "The third one is is loading from a BufferView, when the image file is embedded into the binary GLB file."

that's just wrong, because a BufferView could reference any buffer, not just the GLB buffer

[kind ferry]

do i change those glb mentions to "the binary part of the gltf"?

[low minnow]

no

[kind ferry]

that buffer view is also used for base64 on the text part?

[low minnow]

buffers could be external files too, like a asset.bin file

[kind ferry]

i see

that i didnt know, never saw it in practice

[low minnow]

this is very common practice about buffer views

images that use buffer views are rare though, yes

[kind ferry]

some of all that is because im focusing on what unreal and blender exports

but ill reword that part, commenting that a gltf can refer to outside binary files too

[low minnow]

wheres the new code again

[kind ferry]

https://github.com/vblanco20-1/vulkan-guide/tree/all-chapters-1.3-wip

i have some uncommited stuff on c5 for frustrum culling and calculating mesh bounding boxes

[low minnow]

chapter-5 doesn't seem to be properly updated at all though

the mesh loading is completely missing

[kind ferry]

mesh loading is on chapter 4

[low minnow]

no it isn't

[kind ferry]

https://vkguide.dev/docs/new_vkguide/chapter_3/loading_meshes/ sorry C3

[low minnow]

so you moved that forwards?

[kind ferry]

ye

[low minnow]

ah ok

[kind ferry]

its a "wrong" partial loader

but then it gets superseeded by the one in c5

on this one it doesnt load nodes or anything, just the mesh list

[low minnow]

its not in here either https://github.com/vblanco20-1/vulkan-guide/blob/all-chapters-1.3-wip/chapter-3/vk_engine.cpp

[kind ferry]

the loaders are on vk_loader.cpp in shared

[low minnow]

ooooooh

ok yeah that explains it

[kind ferry]

tho i will refactor it, its a mess

the loader is deeply tied with the engine

the shared folder is for stuff that DOESNT depend on engine

so currently its dodgy, i will duplicate the loader and put it on the chapter folders

this is just a complete mess

i was doing that to avoid duplicating code but seems there is no other choice

at the moment im going through a big todo.txt which is mostly the stuff that other guy reported in the comments

but ill add this to that

[low minnow]

• overloaded is also available as fastgltf::visitor. You already make use of the visitor sometimes, so remove this and switch everything over.
• here and here you should be using fastgltf::getErrorMessage.
• why are you using auto&& here?
• your usage of fastgltf::iterateAccessor could mostly be replaced with fastgltf::iterateAccessorWithIndex, which would save you from resetting vidx all the time and just using initial_vtx + idx in the loops.
• not sure why you're doing this. The scene already specifies what the top node is, so just go from there? And then you'll also skip irrelevant nodes if they exist. Not sure if the program has the concept of multiple scenes, but then multiple scenes could be loaded from a glTF but then share their resources (meshes, buffers, ...).
• the indices are optional. While I know you only concentrate on what Blender and Unreal export, I think you should at least specify Options::GenerateMeshIndices to guarantee availability of indices.
• side note, but not really relevant: integers not prefixed with std are technically UB because they're not defined to exist in the C++ specification and only exist because they also exist in C.

some more things to think about, but i'd be happy to fix those too

[kind ferry]

some of the issues there are from having the code on older fastgltf. will fix

wait the scene specifies the top node? where is that

and multiple gltfs are allowed and its the intended use

yes, they will share resources which will be duplicated

but i dont consider it much of a problem toi have a bit of duplicates there with the massively simplified architecture regarding asset/data lifetimes

[low minnow]

fastgltf::Scene has a vector of nodes, which are all essentially top nodes

[low minnow]

yeah I see a lot of comments and code I wrote for gl_viewer, and I've changed a lot in there over time

[kind ferry]

@low minnow https://github.com/vblanco20-1/vulkan-guide/blob/all-chapters-1.3-wip/chapter-3/vk_loader.cpp

moved the loader of chapter 3 into its folder and improved it a lil bit

[low minnow]

good, you adressed some of the issues

with the formatting fixes it already looks a lot better

[kind ferry]

where is the Overloaded thing declared? @low minnow

[low minnow]

util.hpp

as fastgltf::visitor

you were already using the replacement in some places

[kind ferry]

hm need to upgrade version

all good now

[low minnow]

yeah probably best to target 0.6.1, thats the version thats also available on package managers if any users wanna use those

[kind ferry]

i just nabbed master off github

[low minnow]

also fine, just know I don’t care really about breaking backwards compatibility just now because its still a 0.x version and I still want to change some things

[kind ferry]

went through almost the entire tutorial by now in fixes

only chapter 5 stuff left

chapter 4 had a few fairly critical issues on it

on chapter 5 ive fixed a few things but there are a couple things i want to still add to it, with the frustrum cull

and probably a chapter on a "cleanup" of all the debug/intermediate garbage made in the chapters before

no need to still carry around the hello-triangle by that point

[kind ferry]

https://bruop.github.io/frustum_culling/

turns out its wrong (does mention it on comments and later)..

couse its testing if any of the OOBB vertices are inside frustrum. but on big objects its possible that no corner is in view...

going back to simple projection of the 8 corners into the clip space, which works fine

it has the downside that its a fairly innacurate cull.. but should be fine enough for the explanation and maps well to projecting it on a compute shader for hiz cull

https://github.com/vblanco20-1/vulkan-guide/blob/all-chapters-1.3-wip/chapter-5/vk_engine.cpp#L425 this is the code

at least i dont need to explain frustums or anything, its super easy logic and mirrors the vertex transforms of the vertex shader

ill add this into the text as its very important to significantly speed up things

[kind ferry]

https://vkguide.dev/docs/new_vkguide/chapter_5/faster_draw/#frustum-culling

[low minnow]

are you still working on the code around the loader or can I add the changes I noticed?

[kind ferry]

yeh ive improved things so its now more ready for that

[low minnow]

also whats your opinion on setting the GenerateMeshIndices option, because technically indices are optional but I see youre always relying on it

[kind ferry]

didnt know it got added

[low minnow]

yeah ill add that in my little fixer pr

[kind ferry]

are you going to change the code or the articles

[low minnow]

but I'd have to change everything in vk_loader.cpp from chapter 3, 4, and 5, yes?

[low minnow]

for now code, but if I find anything in the articles I would want to change that too?

would I only have to edit the md files?

[kind ferry]

no, a lot of the articles are actually using the copypaste codegen

tho chapter 5 ones still have inline code on that but that will be changed

[low minnow]

for the code yes

but I mean the actual text in the articles

I understand that the code gets copied into the files essentially

[kind ferry]

yes, the system just grabs the tags from source code and plops them into the .md

its very very basic

[low minnow]

yeah I'm not touching any of that

[kind ferry]

should window resizing and the likes be part of the main tutorial?

or should i have it on a dedicated article outside of the timeline

given that its something that gets constantly asked everywhere with vulkan

specially given that one of the things im thinking is to have the draw buffers be made at maximum window size from startup, and then only resize the swapchain itself

which would give smooth dynamic res by rendering into a smaller viewport of the draw images

[hallow berry]

i have no objections if you leave it out, but i would also like to have it in

too many people keep asking about resizing windows, you might as well cover it too

[kind ferry]

thing is that i dont do it either on vkguide 1

so an article about it would help both

[hallow berry]

personally, i would add it in the main article, and not leave it in some appendix

i also personally dont give a fuck if a neat guide has 15 pages or 13 pages of showing how to swim through a swamp

[kind ferry]

hmm

[hallow berry]

think of it as a deterrent too

something you can send kids to, who need resize in their engines

[kind ferry]

chapter 5 is being a bit strange given that i have some random "engine needs this" extra stuff on it

but i think its important given how many things are skipped

im writing the mipmap generation chapter for example

[hallow berry]

that means you are already thinking about to make it a main thing of the guide 😉

https://tenor.com/view/make-it-so-jean-luc-picard-star-trek-the-next-generation-make-it-happen-gif-23455354

it only adds more value

[civic mantle]

only annoying part is that without swapchain/surface maintenance resizing "safely" is by the spec impossible without leaking old swapchains and semaphores.
You can just 'wait a second and hope for the best' but it don't look purdy. What I mean is that vkDeviceWaitIdle (by the spec) has no effect on the present engine, even if in practice is used to sync things just fine.

[kind ferry]

im mostly going for the pragmatic option :/

wait idle + remake swapachain and rendering

[hallow berry]

what thomas just said could be a paragraph in a warning/info box

[civic mantle]

Thats exactly what I would do. Smooth resizing is the trap, wait idle is fine

[lapis isle]

oh so even deferring deletion via your frames-in-flight deletion queue also isn't safe, you need the callback from the EXT to know when to delete them?

[civic mantle]

And I really do mean 'technically its not possible' in the "aschtually" sense - not relevant for users but pedants gonna pedant

[civic mantle]

yes, the base spec makes no guarantees about when things are safe to delete, since there isn't a way to check when a swapchain/present-semaphore is no longer in use.

[hallow berry]

you could prompt the user to reboot, as soon as they start resizing, that will clear things up

[lapis isle]

makes sense

[hallow berry]

and auto start the app with the new size : )

[civic mantle]

The other pain point is the whole "window size must match swapchain size" which is a race condition because by the time the app recreates the swapchain with the 'new' size, the window has changed size again leading to pointless validation error.

[kind ferry]

im thinking of just not rendering while resizing

[hallow berry]

you use sdl neh?

[kind ferry]

and another thing is that i wont be recreating the draw images

because thats a bunch of stuff + fragmentation + other fucekry

swapchain only

ye

[hallow berry]

iirc sdl has events for resize begin and end

[kind ferry]

exactly

i tried to do it recreating everything but it was a pain

gotta recreate some of the descriptor sets, draw + depth, etc

[hallow berry]

at end should be fine

[kind ferry]

and honestly i do not need it. the draw image can be fixed at startup, and then draw in a viewport

[hallow berry]

call Destroy/CreateResolutionDependentResources()

[kind ferry]

if the swpachain is bigger than the image just scale up when doing the blit

[hallow berry]

yeah

[kind ferry]

as a bonus it maps directly into dynamic resolution slider

which is something i think is really useful

because it can be used to answer the question of "is stuff pixel bottlenecked or not"

[kind ferry]

anyway only thing left is mipmaps (already coded, need to write it), the resizing, and a chapter on setting up some info/bench ui on imgui

[kind ferry]

at the end of the day the resizing code ended up incredibly trivial

barely a couple paragraphs to add to chapter 5. By that time the engine actually is rendering on backbuffers so it doesnt give a fuck about the swapchain. The rebuilding function is just wait idle + re-create the swapchain itself

but ill change a couple thingies in chapters before that to pave the path

[kind ferry]

Added the code for mips into vkguide text. now working on the resizing part

[kind ferry]

resizing got added

https://vkguide.dev/docs/new_vkguide/chapter_3/resizing_window/ kinda shows how hx dynamic rendering is

just call destroy->create swapchain and keep on

im now going to go and review the entire tutorial trying to follow it from chapter 0 to finalize it

[low minnow]

the resizing chapter is called blending

forgot to change the name ig

[kind ferry]

ye just fixed

mipmaps and resizing changed some early chapters so im reviewing stuff to re-sync it properly

likely missed something

without the code generation copypasta tool vkguide 2 would have been impossible.

[kind ferry]

chapters 0-1-2 are now fully doublechecked and improved a ibt

[low minnow]

when youre done with that I can do a bit of checks on the gltf part

had a lot of school n shit

[kind ferry]

on this holidays i can finish the thing

[kind ferry]

chapter 3 is now polished

its the one that includes first usage of fastgltf

[hallow berry]

ill also go through now 🙂

about to explode from all the food

[kind ferry]

quite a lot of minor nits have been fixed/tweaked

[hallow berry]

is there a reason why chapter 0 is the last one?

Initial Setup: Building the project should be

Start by syncing Git project at https://github.com/vblanco20-1/vulkan-guide/tree/starting-point-2 and perhaps turned into some markdown link Start by cloning from git [here](link-here) you can preselect the branch in the link, or you write itout as "clone url && checkout starting-point-2"

main.cpp should annotate both params in main with [[maybe_unused]]

[kind ferry]

chapter 4 been twaked too

tho im stopping for today cuz xmas

[hallow berry]

merry christmas vb

[hallow berry]

the heck

.request_validation_layers() why does this have a param for enabling it

you either request or you dont

request_validation_layers(false) looks funny.

i suppose its to not have to write if (enableSomeDebugStuff) builder = builder.request_validation_layers();

anyway, here some naming thing which could be addressed: VulkanEngine::init_vulkan ... features, should be called features13 to be consistent with feature12

the whole device/physical device naming-ism is super irritating

...
    //create the final vulkan device
    vkb::DeviceBuilder deviceBuilder{ physicalDevice };

    vkb::Device vkbDevice = deviceBuilder.build().value();

    // Get the VkDevice handle used in the rest of a vulkan application
    _device = vkbDevice.device;
    _chosenGPU = physicalDevice.physical_device;
...

and no VKCHECK in there either

vkb::PhysicalDeviceSelector physicalDeviceSelector{ vkbInstance };
auto physicalDeviceSelectionResult = physicalDeviceSelector
    .set_minimum_version(1, 3)
    .set_required_features_12(features12)
    .set_required_features_13(features13)
    .set_surface(_surface)
    .select();
if (!physicalDeviceSelectionResult)
{
    std::cerr << "Vulkan: Failed to select physical device.\nDetails: " << physicalDeviceSelectionResult.error().message();
    return false;
}

vkb::PhysicalDevice vkbPhysicalDevice = physicalDeviceSelectionResult.value();

vkb::DeviceBuilder deviceBuilder{ vkbPhysicalDevice };
auto deviceBuilderResult = deviceBuilder.build();
if (!deviceBuilderResult)
{
    std::cerr << "Vulkan: Unable to build logical device.\nDetails: " << deviceBuilderResult.error().message();
    return false;
}

auto vkbDevice = deviceBuilderResult.value();
_physicalDevice = vkbPhysicalDevice.physical_device;
_device = vkbDevice.device;

idk, i find this more readable

even when "it can be assumed" that "x will never ever happen" like device selection failing in between

same stuff in creating swapchain, no error handling

building schwippchain can fail when surface is null for instance

[hallow berry]

    for (int i = 0; i < _swapchainImageViews.size(); i++)
    {
        vkDestroyImageView(_device, _swapchainImageViews[i], nullptr);
    }
``` for things like this, "shouldnt" you be using ranged loops, and avoid these

    for (auto& swapchainImageView : _swapchainImageViews)
    {
        vkDestroyImageView(_device, swapchainImageView, nullptr);
    }

[ancient portal]

Vkbootstrap's .value() uses C standard assert (which will not be triggered in release mode) so we need some error handing code
https://github.com/charles-lunarg/vk-bootstrap/blob/main/src/VkBootstrap.h#L130-L133

[hallow berry]

uh

thats a weird pattern, but ok

[ancient portal]

Yeah. It deviate from the semantics of std::optional and std::expected, but some people may not want exceptions. Or maybe using a custom assertion (that always triggers) is a better option @civic mantle

[hallow berry]

i suppose most people using any lib dont even bother with any error handling

and let it just crash to the os

[ancient portal]

Crashing is a form of error handling (much better than undefined behavior)

[hallow berry]

ye, but that has other implications

or can have

you might want to gracefully shutdown some other shit first

[low minnow]

not like any of us make any commercial products...

[hallow berry]

that shouldnt matter

[low minnow]

just tried building this on my mac and it fails

I get /Users/sean/Applications/CLion.app/Contents/bin/cmake/mac/aarch64/bin/cmake -E copy /Users/sean/Documents/git/spnda/vulkan-guide/bin in the clion build output for a command

$<TARGET_RUNTIME_DLLS:chapter_0> is an empty list

ah found a fix

[civic mantle]

Are you complaining about the usage of vk bootstrap or the library itself

[hallow berry]

the part you are referring to right now is on vb

i was complaining about the value() and error() builder pattern in vbkootstrap having an assert in there, and kind of defeating the purpose of an optional/result/builder pattern

what lesley was pointing out

[low minnow]

btw, swapchain.destroy_image_views(swapchainImageViews); is a thing with vkb

[hallow berry]

ah, but that's a different thing

[low minnow]

hence the 'btw'

[kind ferry]

i thought of storing the vkb swapchain but at the end its kinda not needed to keep all that state

and i prefer to have bootstrap be completely private to vk_engine.cpp

[hallow berry]

i feel the same way

[lapis isle]

yeah same

[civic mantle]

Yeah I wonder if I should use std optional that I use c++17

A rewrite is in order tbh

[low minnow]

std::optional does the same though

[civic mantle]

Assert if you access the object when it’s not there? I thought it threw an exception

[low minnow]

throws std::bad_optional_access

https://en.cppreference.com/w/cpp/utility/optional/bad_optional_access

oh im retarded nvm

[hallow berry]

but take your time @civic mantle until end of year you settled into your new place

[kind ferry]

chapter 5 now is mostly fixed

[civic mantle]

Yeah I am still staying at my moms until I can unpack more (its close by)

[kind ferry]

only the faster-draw and mipmap stuff left

gonna change that article a bit as i want to give it a timer to showcase how sorting is faster

[low minnow]

btw its not gltf nor GLTF but glTF in all the markdown documents

really triggers my ocd

[kind ferry]

easy fix that one

[kind ferry]

final chapter is done so... its done

lmao the sorting makes things slower once validation layers are implemented

i dont have that many meshes/textures/etc so the cost of sorting gets changed from the cost of binding/encoding the commands

now the annoying part. fixing grammar/typos/gltf across the whole thing and updating the website

[kind ferry]

ok so i have to update the website

the thing is.. how to arrange it

currently i have the whole chapter 1-N on the right bar

thats automatically made and i cant really change it without nuking the permanent links i think

and seems like nesting like the vkguide 2 wip thing doesnt work unless i become webdev for a bit

im thinking having the sidebar be Vkguide New : N and then Vkguide Old : N

and on the Extra articles change them with a note on wether they are more valid on old or new

[hallow berry]

can you not just move all the old stuff into an "Old" folder and keep the structure otehrwise, and in the header have a 2nd tab