#DARE (Danny's Awesome Rendering Engine)
1 messages ยท Page 2 of 1
Ehhh not entirely,,,
I believe srcPipelineStage tells vulkan that src needs to be finished executing first before dst can continue?
yes
To be more formal src is the "first sync scope" and dst is the "second sync scope"
#2 cannot continue if #1 hasn't finished
And I assume every command is "scoped" underneath a certain sync
so transfer commands like copy and scoped under transfer
10/10 resource
yes
go read that if you haven't already yes
slipped my mind 
i will 
i am starting to regret making my entire asset system use hashmaps
descriptor indexing 
do you want samplers only or combined image samplers
image + samplers
you make a VkWriteDesc... with a lot of ImageInfos that contain imageViews and samplers
roger, what is the issue capt
.bind_sampled_image_array(2, 1, images.as_slice(), sampler.as_ref())
As we can observe
phobos only lets you send 1 sampler
kekw ok
fellas
should i submit my material information i.e. albedo texture index in the descriptor
with my object descriptor storage buffer which is sent to my shader
or should i make it seperate from my object struct?
/// Describes the object's bda buffers and materials
struct ObjectDescription {
// 0 - None
uint64_t vertex_buffer;
uint64_t index_buffer;
uint64_t normal_buffer;
uint64_t tex_buffer;
uint64_t material;
};
Material refers to another buffer's index which the material information is stored in
or I could do:
/// Describes the object's bda buffers and materials
struct ObjectDescription {
// 0 - None
uint64_t vertex_buffer;
uint64_t index_buffer;
uint64_t normal_buffer;
uint64_t tex_buffer;
MaterialDescription material;
};

whichever is easier
im gonna pick the indexing cuz overengineer to save a grand total of 32 extra bytes 
praying that this works
my cpu the moment i open up the project: ๐ฃ๏ธ ๐ฃ๏ธ
I'm not tripping this is correct yeah?
layout(set = 1, binding = 3) uniform sampler2D texture_samplers[];
yeah it is
layout(set = 1, binding = 1, scalar) buffer ObjectDescription_ {
ObjectDescription i[];
} ObjectDescriptionArray;
layout (set = 1, binding = 2) buffer MaterialDescripton_ {
MaterialDescription m[];
} MaterialDescriptionArray;
layout(set = 1, binding = 3) uniform sampler2D texture_samplers[];
I'm still waiting for textures
its coming slowly
okok
it broke
no worky
ERROR phobos::core::debug > [VALIDATION]: VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 (-1791811812): Validation Error: [ VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 ] Object 0: handle = 0x1f7bc6e4960, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x95331f1c | vkCreateDescriptorSetLayout(): pBindings[2] can't have VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT for VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER since descriptorBindingPartiallyBound is not enabled. The Vulkan spec states: If VkPhysicalDeviceDescriptorIndexingFeatures::descriptorBindingPartiallyBound is not enabled, all elements of pBindingFlags must not include VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013)
wtf
ah shader crash
ERROR phobos::core::debug > [VALIDATION]: VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 (-1791811812): Validation Error: [ VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 ] Object 0: handle = 0x1f591e864b0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x95331f1c | vkCreateDescriptorSetLayout(): pBindings[0] can't have VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT for VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER since descriptorBindingPartiallyBound is not enabled. The Vulkan spec states: If VkPhysicalDeviceDescriptorIndexingFeatures::descriptorBindingPartiallyBound is not enabled, all elements of pBindingFlags must not include VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013)
what
@tropic vigil Is this a phobos issue?
Seems like it is complaining about a descriptor flag not being on?
oh kekw
ill fix that real quick
we need testing
yeah ill spend some time on it
ill see if i can add some more examples for phobos for testing
toy renderer like how vuk has iirc
pushed on latest
ERROR phobos::core::debug > [VALIDATION]: VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 (-1791811812): Validation Error: [ VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 ] Object 0: handle = 0x1fa9a4f6ca0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x95331f1c | vkCreateDescriptorSetLayout(): pBindings[1] can't have VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT for VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER since descriptorBindingPartiallyBound is not enabled. The Vulkan spec states: If VkPhysicalDeviceDescriptorIndexingFeatures::descriptorBindingPartiallyBound is not enabled, all elements of pBindingFlags must not include VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT (https://vulkan.lunarg.com/doc/view/1.3.25
@tropic vigil I think I found more bugs im not 100% sure however

wat
i thought i enabled the feature
are you on the latest commit
- is that the only message
yes i am
phobos = { git = "https://github.com/NotAPenguin0/phobos-rs", rev = "99e0b9a" }
there is some more
oh fuck i used the parent 
nah the same error appears still
phobos = { git = "https://github.com/NotAPenguin0/phobos-rs", rev = "f698449" }
I think this is me then
ERROR phobos::core::debug > [VALIDATION]: VUID-VkShaderModuleCreateInfo-pCode-08740 (115483881): Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] Object 0: handle = 0x227fb67f850, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6e224e9 | vkCreateShaderModule(): The SPIR-V Capability (RuntimeDescriptorArray) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08740)
ERROR phobos::core::debug > [VALIDATION]: VUID-VkShaderModuleCreateInfo-pCode-08740 (115483881): Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] Object 0: handle = 0x227fb67f850, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6e224e9 | vkCreateShaderModule(): The SPIR-V Capability (SampledImageArrayNonUniformIndexing) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08740)
ERROR phobos::core::debug > [VALIDATION]: VUID-vkResetFences-pFences-01123 (1755645774): Validation Error: [ VUID-vkResetFences-pFences-01123 ] Object 0: handle = 0xd5b26f0000000010, type = VK_OBJECT_TYPE_FENCE; | MessageID = 0x68a5074e | VkFence 0xd5b26f0000000010[] is in use. The Vulkan spec states: Each element of pFences must not be currently associated with any queue command that has not yet completed execution on that queue (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-vkResetFences-pFences-01123)
Nah, most definitely Penguin's fault
definitely my fault but probably an easy fix
Ight this is you though 
its just missing feature flags
hmm ill check on my end then
ah runtime descriptor array
oh 
praige
cope
it didn't
ERROR phobos::core::debug > [VALIDATION]: VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 (-1791811812): Validation Error: [ VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013 ] Object 0: handle = 0x17b6ea3b0e0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x95331f1c | vkCreateDescriptorSetLayout(): pBindings[0] can't have VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT for VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER since descriptorBindingPartiallyBound is not enabled. The Vulkan spec states: If VkPhysicalDeviceDescriptorIndexingFeatures::descriptorBindingPartiallyBound is not enabled, all elements of pBindingFlags must not include VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkDescriptorSetLayoutBindingFlagsCreateInfo-descriptorBindingPartiallyBound-03013)
ERROR phobos::core::debug > [VALIDATION]: VUID-VkShaderModuleCreateInfo-pCode-08740 (115483881): Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] Object 0: handle = 0x17b6ea3b0e0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6e224e9 | vkCreateShaderModule(): The SPIR-V Capability (RuntimeDescriptorArray) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08740)
phobos = { git = "https://github.com/NotAPenguin0/phobos-rs", rev = "3ec955e" }
Penguin forgor features for bindless ๐
tf then
ERROR phobos::core::debug > [VALIDATION]: VUID-VkShaderModuleCreateInfo-pCode-08740 (115483881): Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] Object 0: handle = 0x1e76e8312e0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6e224e9 | vkCreateShaderModule(): The SPIR-V Capability (SampledImageArrayNonUniformIndexing) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08740)
ERROR phobos::core::debug > [VALIDATION]: VUID-vkResetFences-pFences-01123 (1755645774): Validation Error: [ VUID-vkResetFences-pFences-01123 ] Object 0: handle = 0xd5b26f0000000010, type = VK_OBJECT_TYPE_FENCE; | MessageID = 0x68a5074e | VkFence 0xd5b26f0000000010[] is in use. The Vulkan spec states: Each element of pFences must not be currently associated with any queue command that has not yet completed execution on that queue (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-vkResetFences-pFences-01123)
could be me however and vulkan is doing vulkan things again
ping me if there is a fix / update
ok
this time
@dawn wave
i think i really fixed it
i was putting the feature flags in the extension struct instead of in the vk 1.2 features struct
phobos = { git = "https://github.com/NotAPenguin0/phobos-rs", rev = "87049b7" }
it's fixed
ERROR phobos::core::debug > [VALIDATION]: VUID-vkResetFences-pFences-01123 (1755645774): Validation Error: [ VUID-vkResetFences-pFences-01123 ] Object 0: handle = 0xd5b26f0000000010, type = VK_OBJECT_TYPE_FENCE; | MessageID = 0x68a5074e | VkFence 0xd5b26f0000000010[] is in use. The Vulkan spec states: Each element of pFences must not be currently associated with any queue command that has not yet completed execution on that queue (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-vkResetFences-pFences-01123)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: The logical device has been lost. See <https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#devsandqueues-lost-device>
but mine borked 
shader crash
but phobos fixed i think
thats definitely on your end yeah 
I LOVE DEBUGGING SHADERS
(they do not give me a crash log whatsoever)
is there a way to get shaders to like output crashes?
Hmm am I doing wrong...
probably accessing out of bounds
payload.hit_value = texture(texture_samplers[nonuniformEXT(0)], tex_coord).rgb;

it's odd as it's reporting that i have at least one image being sent in
uhh how do you use nsight aftermath
like download?
I dunno if there is a rust ver
oh.
It's C++
OHH
c++ once again wins
I'm a bit too braindead rn to get it set up 
I have a question
when submitting images yeah
if I only submit one to be bindlessly binded
I assume it's index is zero yeah?
yes
then something is going wrong
i figured it out
i forgot to add tex coordinates
stroke of genius if you will
ah i solved it
yeah tex buffer
how you would you uh generate them...?
tf why doesn't it exist ๐
texcoords work
ok
IT
FUCK8ING
WORKS
LES
LETS
FUCKING GOOOOOOOOOOOOOOO
RAHHHHHHHHHHHHHHHHHHHHHHHHHHH
now render sponza
material binding works
lets blindly scale it to sponza i totally will not regret this decision
wait deccer
deccer borked
I failed to understand you meant "deccer cubes" for 2 minutes straight
I thought: "he's finally lost it"
ill make one up then
With linear filtering, linear mip transitions and repeat
I assure you that's all you're going to need for 99.9% of models out there
ohh nooo
ERROR phobos::core::debug > [VALIDATION]: VUID-VkWriteDescriptorSet-descriptorCount-arraylength (286023833): Validation Error: [ VUID-VkWriteDescriptorSet-descriptorCount-arraylength ] Object 0: handle = 0x22c5b593260, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x110c6099 | vkUpdateDescriptorSets: parameter pDescriptorWrites[2].descriptorCount must be greater than 0. The Vulkan spec states: descriptorCount must be greater than 0 (https://vulkan.lunarg.com/doc/view/1.3.250.1/windows/1.3-extensions/vkspec.html#VUID-VkWriteDescriptorSet-descriptorCount-arraylength)
Fuck this isn't good
It means I'll have to always have some dummy texture
Is there a way to avoid this?
But wouldn't that cause the shader to complain then if there is no binding
No
wa
That's what PARTIALLY_BOUND is for
holy shit
thank you
literal savior fr
it's black
this bleak brother
what it's all black because my tlas broke
deccer's cubes once again
Cubicles are too powerful
ah is it because they're instanced?
yes
that is why

only one cube
:(
what
it is processing it as only one mesh
ah : >
It's about uh
input: 19 mesh primitives (22413312 triangles, 44297721 vertices); 19 draw calls (19 instances, 22413312 triangles)
Yeah 22 million triangles
no big deal
you should report this to #926896734284689428 ๐ (the failed purple cube)
i havent optimized my asset importing
its slow as hell
i need to optimize that
ok lets think
your mom is slow as hell

jk ๐ but i couldnt resist
this is some wizardry i'm so unaware about
Found 1 meshes on layer 1
Found 1 meshes on layer 2
Found 1 meshes on layer 2
Found 1 meshes on layer 2
Found 1 meshes on layer 2
[gltf]: Scene has 1 meshes
gltf is saying it has somehow compressed my 5 meshes into 1
this is magical
: )
To handle instancing correctly you should do something like this
HashMap<gltf_primitive, mesh_data> primitives;
for (mesh in gltf.meshes) {
for primitive in mesh.primitives {
primitives[mesh] = load(mesh);
}
}
for (node in gltf.nodes) {
mesh = node.mesh;
for (primitive in mesh.primitives) {
data = primitives[primitive];
transform = node.transform;
// put this thing into your scene or something
}
}```
i wish i could hash meshes
rn I'm just recursively iterating through the scene
collecting all meshes used
oh
now i understand why you do it like that

One node can reference multiple meshes
yes i realized
how would you propogate those transformations however?
as a node could parent another one
and you still need to account for that transformation
I just use cgltf_node_transform_world which does it for me though 
C++ once again wins
huh i may need to rewrite it again
damn that is annoying
as it's gonna be 2000% more efficient to just make a scene tree with handles to the meshes
rather than cloning the same mesh
nah fuck it
im gonna clone it
this doesn't look right

geometry looks right it seems
oh
wait no way
why is it all using the same
material

oh my 
i solved it
why the fuck was i indexing my material array using my the index of my mesh
i am still geitng randomized textures
does it flicker?
no it literally for some reason
is randomly selecting textures
this is an issue with my asset loader
what if i made this a feature
probablistic renderer. there is a 0.00001% chance your render will be correct :D
๐
this is actually dialobical
if not magical
how???
it is randomly selecting my textures
most likely stupitidy
it is most likely 
I was able to get it order it so now I can get consistent erorrs ๐
i-
no way
one step closer
fixed a casting issue
one step closer
int -> i32
vec3 -> [f32; 3]
i think that is correct
the purple bar work
purple bar :)
go purple bar go ๐
joever who?
we aren't coming back from this bug
ligma balls
/// Describes the material properties of the object
struct MaterialDescription {
// -1 - None
int albedo_texture;
vec3 albedo;
};
/// Describes the object's bda buffers and materials
struct ObjectDescription {
// 0 - None
uint64_t vertex_buffer;
uint64_t index_buffer;
uint64_t normal_buffer;
uint64_t tex_buffer;
int material;
};
#[repr(C)]
#[derive(Clone, Copy)]
pub struct CMesh {
pub vertex_buffer: u64,
pub index_buffer: u64,
pub normal_buffer: u64,
pub tex_buffer: u64,
pub material: i32,
}
/// Version of material but for C
#[repr(C)]
#[derive(Copy, Clone)]
pub struct CMaterial {
pub albedo_texture: i32,
pub albedo_color: [f32; 3],
}
what am i doing wrong
is it the albedo_color?
is that it
is that the root cause?
is that why?
Just a small warning
padding
Although I am not confident in that
Actually, it could never be that
no idea 
im gonna smash my face into a wall bro
Do you use scalar layout on everything
bruv
layout(location = 0) rayPayloadInEXT Payload payload;
layout(buffer_reference, scalar) buffer Vertices { vec3 v[]; }; // Vertices
layout(buffer_reference, scalar) buffer Normals { vec3 v[]; }; // Normals
layout(buffer_reference, scalar) buffer TexCoords { vec2 v[]; }; // TexCoords
layout(buffer_reference, scalar) buffer Indices {ivec3 i[]; }; // Triangle indices
layout(set = 1, binding = 1, scalar) buffer ObjectDescription_ {
ObjectDescription i[];
} ObjectDescriptionArray;
layout (set = 1, binding = 2, scalar) buffer MaterialDthatescripton_ {
MaterialDescription m[];
} MaterialDescriptionArray;
layout(set = 1, binding = 3) uniform sampler2D texture_samplers[];
do samplers need scalar as well?
no you can't do scalar on that
Just try hardcoding 0 in your material data
see if it werks
Well
there's your problem
check GPU side buffers with Nsight
Imma go schlepp now
good luck soldier
๐ซก
seems like
0 works
1-4 borks
and it is always the same two meshes
the ones i shown in that pictures
while i woild love to chekc my buffers i have zero clue how to
as they're buffer views so i can't even attach a name
renderdoc time
i wish renderdoc doesn't work with rt extensions
oh
it works
i uh

i forgot to reflect my struct changes


okay now to figure out issue
So
vec3 yeah
[f32; 3]
Why can't I just send that to glsl as a vec3?
oh i can
what broke then???
if i pretend the issue doesn't exist
then it doesn't ๐
no excuses
yes way
???
It doesn't matter how unoptimized it is
I think it's physically impossible to not be able to load sponza
even if you iterated over every single triangle jn sponza 10 times over
it takes a good 10 seconds for me to load in the helmet
what
yea

sure
its a mess too
wait wrong branch @devout mesa
fn convert_data_type(
here it is
I am impressed
yeah me too
i wrote this i think during an all nighter
im just trying to get textures to work
before it refactor the living shit out of this
Well
I'll now take you a bit off road
You have textures for deccer cubes loaded yes?
What happens when you get far away
aliasing
something else happens, related to textures
uhhh idfk mipmap issues?
yes, you see moirรฉ patterns all over the place right?
yeah
How do you fix this
you don- mipmaps
You already do mipmaps don't you?
yeah i just havent enabled them
i will but it's buggy rn and i need to get textures 101 working
rip
well not buggy, just untested
then we'll do this tomorrow
all the jibberjabber, where is the screenshot!
ah it werks
it fixed itself
is that lustri's version?
lustri is distributing his in #926896734284689428
the special sponza?
i found bugs
sponza is soon(tm)
alright you have 18hrs
!remind me 18 hr to bug danny and sponza
!remind 18 hr to bug danny and sponza
Alright deccer, I'll remind you about to bug danny and sponza in 18 hours. ID: 59145700
noooo
end times are upon us
hehe, gn8
๐ซก
danny after he made sponza work
rip my cpu
it will spend the next 10,000 years
stuck in eternal computation
i figured out why
turns out printing each vertex is not a good idea of perforamnce 
this is concerngin
```thread 'main' panicked at 'Unable to allocate scratch buffer: Vulkan allocation error: `Out of memory````
is there an upper limit for scratch memory?
if so i'm moving it all into bdas 
i know nothing but pain suffering
let mut object_description_sratch_buffer = ifc
.allocate_scratch_buffer(
(self.acceleration_structure.addresses.len()
* std::mem::size_of::<asset::CMesh>())
as vk::DeviceSize,
)
.expect("Unable to allocate mesh scratch buffer"); // lmao
what about this
lacks memory
wtfff
thread 'main' panicked at 'Unable to allocate mesh scratch buffer: Vulkan allocation error: `Out of memory`
I geniunely do not know why
is there an upper limit to this amount of memory? For me iirc it was saying I was only using 600 bytes amount of memory
@tropic vigil pinging as you probably know
panic
if i can't solve this
i will be beaten brutally by deccer
we're so fucking not
i actually do not know how to deal with this error. I'm gonna assume for some odd reason scratch memory is really small

i gvie up
i surrender
i cannot figure this scratch error for the love of my life
how the hell is 600 bytes causing an out of memory error
Hmmm is the reason for the out of memory error is because I'm only supposed to create only one scratch?
let mut object_description_sratch_buffer = ifc
.allocate_scratch_buffer(
(self.acceleration_structure.addresses.len()
* std::mem::size_of::<asset::CMesh>())
as vk::DeviceSize,
)
.expect("Unable to allocate mesh scratch buffer"); // lmao
let mut material_descriptor_scratch_buffer = ifc
.allocate_scratch_buffer(
(scene_read.materials.len() * std::mem::size_of::<asset::CMaterial>())
as vk::DeviceSize,
)
.expect("Unable to allocate material scratch buffer");
Lemme see
Yes, itโs given on context creation
The default is 1 byte (effectively zero) so you probably need to set it
OHHHH
it;s that 1024 * xx * xx thing
Oml
I think Iโll use bdas instead.
Oh wait I can just make ssbos nvm
You can create many scratch buffers though, as long as you have memory
Scratch mem is good for this, you can still use BDA to bind it
But since you update it every frame using scratch mem will handle the double buffering for you
Oh I assumed the 1024 * xx * xx is pre-allocated space, no?
Well, that is allocated for each scratch allocator
But those are created and cached on demand
So โbestโ case you only have two alive
Its not much memory for a lot of convenience
Dont see it as a waste see it as preallocated memory to speed up short lived allocations
Hmm yesh ig so I just donโt like that I have to pre-set a fixed amount
Hmm maybe dynamically growing scratch allocators is the way to go
Maybe? How would I do that?
Can you open an issue for that
Alr will do
Ill wrestle with Phobos internals and add it 
Should be doable though
Made it ๐
Hmm whay should I do in the mean time then
Should I try to move them to buffers and attach them as storage buffers?
Just set the scratch size to a few mb
Scuffed fixed
but good enough tbfh
No need to attach to the graph if youโre not writing to them on the gpu
Hmm yeah but how would I indicate to the grsph
That I intend on binding them as storage and the shader is meant to read from them:
.bind_storage(set, binding, buffer)
You donโt need to add it to the graph at all
Just allocate and bind
Adding things to the graph is just for sync
But youโre never writing on the gpu so no sync needed
Hmm okok
So i could literally take the ctx, get the graphics domain, bind the buffer, then submit that for execution snd it show up still?
I assumed it always unbinded or smth
Yep
No the graph doesnโt bind anything it just handles sync
Hmm i need a bit of a tutorial for Phobos maybe
Yeah they are just somewhat tedious to write 
Iโll see if I can contribute some
Or modify the existing ones to use new features we added
So we can get some test coverage
ok crashes are gone
me when i had to simply increase scratch memory 
it is time
sponza
this sponza looks fucked up

why the wall
wtffff
hm what test textures exists
looks like youare randomly picking textures again
i see normal maps and albedo at the same time

i just discovered the gltf crate has utility functions to help me cast types
i literally implemented that all myself oml
hmm i need to find a smaller scene where this bug repo
Oh also another mistake I made when loading sponza
I used a vec2<u8> for textures coordinates; don't do that (if you do)
I forgor that tex-coords can be greater than 1.0
Yep
let me look into my buffer
Nothing stops a modeler to make UVs out of texture bounds (to cause repetition for example)
im omw to check my uvs
did i forcefully normalize then 
no i only did that to my textures
hmmm
is the sampler fucked possibly?
ah fuck how would I even do a per-image per-sampler binding?
is that even possible with how phobos had set it up?
bindless images can only take one sampler
you know what
quest time
i need to rework my entire asset system
as it's a total mess rn
Use mine ๐ค 
ok plan
we can either have non-loaded assets then a load method to effectively load them
pros:
- ease of use
cons: - i pray for my monolithic buffer
or we load the entire scene which is gonna be easier for me to code
What I do in my system is I have an Asset trait that can be implemented for anything, and then a World where I can add in resources, including an AssetLoader
Though that more engine related than rendering engine related
If you're going to stick with solely a rendering engine I'd say make it load a whole scene at once tbh
Load buffers -> Load accessors -> Load meshes -> Process meshes -> Generate needed buffers -> Update meshes -> Store buffers on device
issue is how do I do this without killing my cpu memory

like auto-generating normals etc.
'Tis how I do it
i need to get into the habit of using traits 
hm should i load them manually
or rely on the gltf crate
gltf makes it 10x easier
lmao why are you loading it manually then 
I'm using the gltf crate
The "manual" part is creating my gfx / rendering / entities objects
oh i was talking about if i should use gltf's crate built-in deserializer
instead of reading the buffers myself
eh yeah
more manual control ig
Do you generate normals?
ahh okay
so idk if this is proper terminology but I'll create a bunch of virtual assets
The first deserialization stage will create virtual assets of the scene, the second stage is supposed to recognize if certain materials, textures, or buffers (normals) need to be pre-generated
I don't understand
why you are doing this garbage
literally load the things like a normal person
it's too spaghetti :(
Nein
I load them in from the glTF
I do generate tangents though
hmm ok
just load what you need to load!
(trait system does help a lot tbh)
i should probably make the trait system kekw i haven't been using them at all in my project
vector<VertexData> vertices;
HashMap<GltfPrimitive, vector<VertexData>> primitives;
for each mesh {
for each primitive in mesh.primitives {
// declare pointers to attributes
vec3* position = null;
vec3* normal = null;
for each attribute in primitive.attributes {
switch (attribute.type) {
case position: position = attribute.buffer_view....
}
}
// actually put vertices here
// register primitive in "primitives"
}
}
for each node {
for each mesh in node.meshes {
for each primitive in mesh.primitives {
if primitive.contains(primitive) {
// put the vertex data in your scene or something
scene.insert(object);
}
}
}
}
return scene;```
It doesn't get easier than this
i am overthinking this 
ah i know why its so hacky
been creating an entirely new buffer for each accessor
also i don't have some like temporary gltf struct its all free standing functions meaning i have to constantly convert back and forth between my asset & something gltf can understand
why do you even have to convert back and forth
cuz i immediately throw my stuff on loading into asset storage
Look
your asset loader has to do ONE THING
and ONE THING only
convert the data in your GLTF file, to data in vectors you can use later
That's all it has to do
it doesn't matter what kind of shenanigans you want to do, that's all you will have it do
okok
And I am telling you to do it like this
It's easy, functional and will work for 99.99999% of models out there
https://github.com/LVSTRI/IrisVk/blob/master/src/renderer/core/model.cpp#L81-L163 This takes the vertex and index data
https://github.com/LVSTRI/IrisVk/blob/master/src/renderer/core/model.cpp#L299-L318 This iterates over all the nodes and uses the vertex data previously calculated
then returns the vectors
It's not hard unless you want to complicate your life for no reason whatsoever
The things in the middle are meshlet specific and you don't need to look at those
Yea this rule is really great for anything programming related
Do one thing and do it well
If not then it's not its job
huh yeah but also wouldn't that be duplicating shared data?
What would?
since you're iterating over every accessor in each prim, and not the entire gltf file, wouldn't that potentially lead to you having to duplicating the same data?
unless I'm not understanding how you're storing all the vertices
I assume a sane glTF file
oh kekw
I don't think any exporter duplicates primitives like that
and even if it did, I use my own tools to deduplicate the meshes (gltfpack)
oh then that makes life a lot easier
maybe i'm overthinking this because im constantly testing odd edge cases
btw I just checked
in any of the models I use
whether they have been exported from blender, Unreal Engine, transformed from FBX/OBJ to glTF, downloaded from random chinese sites
In every single one of them
Each primitive is unique
Two different primitives never have the same accessors with the same data
gltf samples really made me go down a rabbit hole then huh
And even if they were not unique
I have this
if (meshlet_cache.contains(&primitive)) {
continue;
}```
And also gltfpack deduplicates anything for me
accessors, textures, meshes, nodes, etc
tf im jealous
ill see if they have rust wrapping
Granted I do have my own fork of gltfpack which does things how I like them done
so perhaps you might wanna fork it and see if there's anything you are unhappy with
you are overestimating how smart i am 
For example quantization by default is all or nothing
You can't say "I want to quantize positions but not normals"
In my fork I get to decide
Oh yeah
how do you guys handle converting over your accessors to certain types and dimensions?
Wdym?
I just read the value slice as it was given to me
Oh so what happens if you get a file that contains accessors with other types?
does it kinda just go "lmao"
you know maybe lvstri was onto something when he said only consider sane gltf files 
I only stick with the "default" types if that's what you mean
Aka only (floats, ints, uints, and vecs of those)
Common data types basically since those are all I need (and support) anyways
by gltf spec
position will always be vec3
normal will always be vec3
tangents will always be vec4
texcoords will always be vec2
yeah but the types
always float
unless you use quantization
in that case it may or may not be float, but you decide what it will be
ahh im gonna kms
wrote useless code ;kek
@feral trellis Sorry for ponging but why not use gltf's document wrapper for json?
oh so it's just semantics?
// Decompose the JSON document
let gltf::json::Root {
accessors,
buffers,
buffer_views,
scene,
images,
materials,
meshes,
nodes,
samplers,
scenes,
textures,
..
} = json;
Yeap
mkmk
I get gltf.document and then get root from that
ikik i was just confused why you were doing ,into_json
yeah the first ever gambling renderer
you heard it here first
this will go big in Vegas baby
Is it possible to get a primitive's transform without having to recursively iterate through the node tree?
no
oh ok then
that transform will be 100% wrong
It's literally written in the spec as well
It's only the relative transform to the parent
So you need to iterate through all nodes to get its global transform
Also don't do it recursively
i- was doing it that way 
Bruh
bruh how are you supposed to do it non-recursively?
wat
ptr = node;
transform = mat4(1.0);
while (ptr->parent) {
transform = transform * node.matrix;
ptr = ptr->parent;
}```?
oh my god
yeah that makes sense
oh no
big oh no
seems like gltf crate doesn't provide you with the parent?
oh wait you're supposed to implement that yourself?
?
no
a node should have a parent ptr
Any sane gltf loader will provide you either with a parent ptr, or an index to the parent
average rust lib
I'm gonna assume they didn't add it cuz rust memory safety
Maybe getting the transform of a node already gives you the fully transformed node?
if that were the case
all my prior screenshots
would've been wacked beyond comprehension
sorry, how are you transforming it right now
I am literally recursively going through the entire scene tree, multiplying the transforms then applying them
remember your DSA classes? Any recursive function can be transformed into an iterative function

oh my
i forgor stack
i can literally make a stack of nodes that need to be processed
I still can't get over the fact you can't get the parent of a node
I checked documentation as well
hey uh @feral trellis how is this reasonable? on any level?
eh who cares just do a stack loop
yeah but most gltf loaders will include a parent pointer for QoL
Yelp this one doesn't ig
It's not that big of a deal tbh I managed to do without it
I just start with the root node and go down from there
Yea
probably is
I mean you can also use unsafe unions but you shouldn't use unsafe for that
oh yeah i can do match and all that stuff
Enums are the way to go
im gonna trust lvstri and iterate just over my primitives
if he lied then it's joever (i will waste 0.0004 mbs of vram)
I mean it's kinda like the only way of doing this sanely
blud thinks im still sane after 2 weeks of non-stop graphics programming
you cannot lose what you don't have
Ok that's true lol
men we shall go on a mission to save that 0.0004 mb of memory ๐ซก each byte counts
oh now i understand why you did .into_json it preserves the json ordering
if I did the document wrapper it's uh questionable
when you see patterns emerge in the soup that is coleured micro tringles for debug isms
Holy fuck that looks beautiful
it's not good to stare at tiny triangles for too long 
like these 3d images which were popular in the mid 90s
oh my god
this is insufferable
why the hell does gltf's document wrapper not iterate in order 
LVSTRI, do you handle sparse accessors at all?
or you throw that to gltfpack to take care of
I don't think I have seen any glTF model that uses sparse accessors
at all
so no I don't handle them 
๐ค uhm ackshually
besides from the examples yeah
i really need to stop basing my gltf capabilities on those sample models 
its making me overengineer for stuff that i will never come across
Oh fuck
Well thanks for letting me know now I found a bug in my code lel
(yet it somehow worked out this whole time)
nono if you're doing json
you're good
that is what you're doing @feral trellis
It keeps json ordering
also turns out
it was a bug on my end 
yeah seems like gltf iterators are fine
@feral trellis How did you handle getting unique primitives? I can't seem to figure that out rn
Wdym by "unique" primitives?
ah wait nvm we're approaching it from different ways
looks like you're iterating over the gltf documents
I am getting my prims via iterating through the scene graph
I mean I do that too
I iterate over the nodes, and fetch the surface that I parse from the document's meshes / buffers
// For now, we only handle mesh entities and empty entities
let entity = if let Some(mesh_index) = node.mesh {
let mesh = &meshes[mesh_index.value()];
let meshes = &mapped_meshes[mesh_index.value()];
meshes is the gltf given value
mapped_meshes contains meshes of my own rendering API
but that however just covers the mesh, no? and not the primitive
Geometry to be rendered with the given material.
unless I'm high
That selects the mesh then I iterate for each primitive
// Sub-Surfaces that we must render
let mut subsurfaces = Vec::<SubSurface<PbrMaterial>>::new();
// Create the sub-surfaces of the entity (mesh)
for (submesh_index, primitive) in mesh.primitives.iter().enumerate() {
let mesh = &meshes[submesh_index];
let material = primitive
.material
.as_ref()
.map(|i| mapped_materials[i.value()].clone())
.unwrap_or(default.clone());
subsurfaces.push(SubSurface {
mesh: mesh.clone(),
material: material.clone(),
});
}
Literally the next line
wait am I fucking stupid
primitive index doesn't refer to the actual primitive index
but the mesh?
oh my god
brain dead activity aka me
noon i understand what they meant
primitive_index refers to the index the prim itself is in within the mesh

Yep
Node -> Mesh -> Multiple Prims
How should I do normal generation
without having to deal with duplicate normals/computation
mainly worried more about having to recompute the same thing over and over
You should avoid it
really? Well the issue is a lot my test gltf file kinda don't have normals
yeah but when i open some it will just say no normals??
but if you say so
i won't generate them
No you should generate them when they are missing
it's just strange
Anyways you should put each vertex normal at 0
and then iterate over all triangles, cross product their edges and normalize
You add the result to each vertex, smoothizing the normals
yeah mhm
im just unsure how to do it in a way where i won't be duplicating my computations
should I make a hashmap of the vertex accessor index as that is more or less the input for normals?
for v in vertices {
v.n = vec3(0, 0, 0);
}
for t in triangles {
n = normalize(cross(t.b - t.a, t.c - t.a));
// add the normal to each vertex such that smooth normals are generated
t.a.n += n;
t.b.n += n;
t.c.n += n;
}
for v in vertices {
v.n = normalize(v.n);
}
That does not matter
You want to duplicate your computations in fact
You will be adding the normal for every vertex you encounter
ohh i do the process at the end
More than one triangle could share the same vertices at their edges
why even work on accessors?
Just load the data
and then work on the loaded thing
eh fine ill change it so i just iterate over every mesh
Dont forger to renormalize btw
its works for you so i mean
yes do not worry
I do far more complicated computations during loading
such a spatial sorting triangles and building RB trees over all them, then greedily aggregating triangles, etc...
Although it's meshopt that does this 
heh
It could use meshlets
yeah there is a recent paper that goes into using it
Unfortunately I do not have an Intel GPU so I can't test this, but the gist is real time LODing and swapping of clusters for RT
With streaming, so memory is effectively not a concern anymore
And I will try to integrate it into RADV
RADV?
(opensource) Vulkan driver for AMD GPUs on linux
ahh i see
lustri? are you distracting danny with nanitebrainwormisms?
wasn't my intention 
thihihi
i alos forgor to say but ew vertex struct
fuck i realized your solution
won't work with mines 
unless i do a decently large rework
ah wiat yeah
nvm it is
ill just need to throw everything into one monolithic buffer
then suballocate the hell out of it
magic
You have your vertex data, in a vector
yes or no
if yes => good, do what is written above
else => bad, put your vertex data in a vector and see branch yes
mate
no
ok good
now we're talkin
Just for this mesh primitive
one vector of vertex data, you put all your stuff in that once per primitive, you process the data and then put it back into a bigger vector or something
so
unique meshes -> primitive -> acessors -> yeet the vertex data into the massive vector
i should make this a hashmap so it can expand to support other accessors like normals etc

vector<Vertex> vertices;
load_primitive_into(vertices);
process(vertices);
bigger_vector.insert(vertices);```
do you understand
OH