#DARE (Danny's Awesome Rendering Engine)

1 messages ยท Page 2 of 1

devout mesa
#

Right

#

Do you know what srcPipelineStage and dstPipelineStage do (in any barrier)

dawn wave
#

Ehhh not entirely,,,

#

I believe srcPipelineStage tells vulkan that src needs to be finished executing first before dst can continue?

devout mesa
#

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

dawn wave
#

And I assume every command is "scoped" underneath a certain sync

dawn wave
#

so transfer commands like copy and scoped under transfer

tropic vigil
#

10/10 resource

devout mesa
#

go read that if you haven't already yes

#

slipped my mind bleakekw

dawn wave
#

i will KEKW

dawn wave
#

i am starting to regret making my entire asset system use hashmaps

#

descriptor indexing bleakekw

dawn wave
#

so uh

#

how would you bind multiple samplers in a shader?

devout mesa
#

do you want samplers only or combined image samplers

dawn wave
#

image + samplers

devout mesa
#

you make a VkWriteDesc... with a lot of ImageInfos that contain imageViews and samplers

dawn wave
#

huston we got a problem then

devout mesa
#

roger, what is the issue capt

dawn wave
#
.bind_sampled_image_array(2, 1, images.as_slice(), sampler.as_ref())

As we can observe

#

phobos only lets you send 1 sampler

devout mesa
#

epic

#

Well it's good enough for now

#

Just bind the "default sampler"

dawn wave
#

kekw ok

dawn wave
#

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;
};
devout mesa
#

whichever is easier

dawn wave
#

im gonna pick the indexing cuz overengineer to save a grand total of 32 extra bytes KEKW

dawn wave
#

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[];
devout mesa
#

is it the last binding in the set

#

if so, yes

dawn wave
#

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[];
devout mesa
#

I'm still waiting for textures

dawn wave
#

KEKW its coming slowly

devout mesa
#

I can't wait faster

#

but you can make it quiccer

#

get a move on soldier

dawn wave
#

okok

dawn wave
#

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?

tropic vigil
#

oh

#

looks like we missing a feature flag

dawn wave
#

oh kekw

tropic vigil
#

ill fix that real quick

dawn wave
#

KEKW we need testing

tropic vigil
#

yeah ill spend some time on it

dawn wave
#

ill see if i can add some more examples for phobos for testing

#

toy renderer like how vuk has iirc

tropic vigil
#

pushed on latest

dawn wave
#
 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

tropic vigil
#

wat

#

i thought i enabled the feature

#

are you on the latest commit

#
  • is that the only message
dawn wave
#

yes i am

phobos = { git = "https://github.com/NotAPenguin0/phobos-rs", rev = "99e0b9a" }
#

there is some more

tropic vigil
#

thats not latest

#

i pushed a fix for that error

dawn wave
#

oh fuck i used the parent bleakekw

#

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)
devout mesa
#

Nah, most definitely Penguin's fault

tropic vigil
#

definitely my fault but probably an easy fix

devout mesa
#

Ight this is you though KEKW

tropic vigil
#

its just missing feature flags

dawn wave
#

hmm ill check on my end then

tropic vigil
#

ah runtime descriptor array

dawn wave
#

oh KEKW

tropic vigil
#

no that last one is caused by the first errors

#

pushed

dawn wave
#

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" }
devout mesa
#

Penguin forgor features for bindless ๐Ÿ’€

tropic vigil
#

wat

#

i enabled partially bound

dawn wave
#

tf then

tropic vigil
#

guess ill read the spec

#

hold on

dawn wave
#
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

tropic vigil
#

no

#

its just missing feature flags

dawn wave
#

ping me if there is a fix / update

tropic vigil
#

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

dawn wave
#
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 KEKW

#

shader crash

#

but phobos fixed i think

tropic vigil
#

thats definitely on your end yeah bleakekw

dawn wave
#

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...

tropic vigil
#

probably accessing out of bounds

devout mesa
#

Aftermath

#

But ye

#

OOB 99%

dawn wave
#
payload.hit_value = texture(texture_samplers[nonuniformEXT(0)], tex_coord).rgb;

bleakekw

#

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?

devout mesa
#

I dunno if there is a rust ver

dawn wave
#

oh.

devout mesa
#

It's C++

dawn wave
#

OHH

devout mesa
#

c++ once again wins

dawn wave
#

that makes sense now

#

Segfaulting ๐Ÿ—ฃ๏ธ

tropic vigil
#

aftermath works fine with rust

#

its gpu only

dawn wave
#

I'm a bit too braindead rn to get it set up KEKW

#

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?

devout mesa
#

yes

dawn wave
#

KEKW 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...?

devout mesa
#

you don't

#

uv mapping is done by the artist

dawn wave
#

tf why doesn't it exist ๐Ÿ’€

#

texcoords work

#

ok

#

IT

#

FUCK8ING

#

WORKS

#

LES

#

LETS

#

FUCKING GOOOOOOOOOOOOOOO

#

RAHHHHHHHHHHHHHHHHHHHHHHHHHHH

devout mesa
#

now render sponza

dawn wave
#

I CAN FEEL IT ๐Ÿ—ฃ๏ธ THE TEXTURES ๐Ÿฆ…

#

oh

#

will try

devout mesa
#

no

#

wrong

#

you will succeed.

#

For my entertainment

dawn wave
#

material binding works

#

lets blindly scale it to sponza i totally will not regret this decision

#

wait deccer

#

deccer borked

devout mesa
#

I failed to understand you meant "deccer cubes" for 2 minutes straight

#

I thought: "he's finally lost it"

dawn wave
#

tf is the gltf default samplers bleakekw

devout mesa
#

mate

#

again

#

Just use a single sampler

dawn wave
#

ill make one up then

devout mesa
#

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

dawn wave
#

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?

devout mesa
#

Yes

#

Do not write if you have no textures

dawn wave
#

But wouldn't that cause the shader to complain then if there is no binding

devout mesa
#

No

dawn wave
#

wa

devout mesa
#

That's what PARTIALLY_BOUND is for

dawn wave
#

holy shit

#

thank you

#

literal savior fr

#

bleakekw it's black

#

this bleak brother

#

what it's all black because my tlas broke

#

deccer's cubes once again

devout mesa
#

Cubicles are too powerful

dawn wave
#

ah is it because they're instanced?

#

yes

#

that is why

#

only one cube

#

:(

#

what

#

it is processing it as only one mesh

devout mesa
#

btw I made deccer cubes more powerful

#

would you like to try

dawn wave
#

oh no

#

ok

eager chasm
#

ah : >

devout mesa
#

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

eager chasm
#

you should report this to #926896734284689428 ๐Ÿ˜› (the failed purple cube)

dawn wave
#

bleakekw i havent optimized my asset importing

#

its slow as hell

#

i need to optimize that

#

ok lets think

eager chasm
#

your mom is slow as hell

dawn wave
eager chasm
#

jk ๐Ÿ™‚ but i couldnt resist

dawn wave
#

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

eager chasm
#

: )

devout mesa
#

To handle instancing correctly you should do something like this

dawn wave
#

oh wait .append

#

oh my god

#

it makes sense now

devout mesa
#
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
    }
}```
dawn wave
#

i wish i could hash meshes KEKW rn I'm just recursively iterating through the scene

#

collecting all meshes used

#

oh

#

now i understand why you do it like that

devout mesa
#

One node can reference multiple meshes

dawn wave
#

yes i realized

devout mesa
#

And multiple meshes can reference the same primitives

#

Or different even

dawn wave
#

how would you propogate those transformations however?

#

as a node could parent another one

#

and you still need to account for that transformation

devout mesa
#

You traverse the node path up to the root

#

and mul transforms

dawn wave
#

ohh

#

you can access the parent

#

okok

#

i think that makes sense

devout mesa
#

I just use cgltf_node_transform_world which does it for me though bleakekw

dawn wave
#

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

eager chasm
#

geometry looks right it seems

dawn wave
#

yeah textures are wacked

#

it seems to be randomly selecting the textures

eager chasm
#

hehe

#

deccer-cubes-randomly-texturized.gltf

dawn wave
#

oh

#

wait no way

#

why is it all using the same

#

material

#

oh my bleakekw

#

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

eager chasm
#

does it flicker?

dawn wave
#

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

eager chasm
#

๐Ÿ˜„

dawn wave
#

this is actually dialobical

#

if not magical

#

how???

#

it is randomly selecting my textures

eager chasm
#

most likely stupitidy

dawn wave
#

it is most likely KEKW

eager chasm
#

and absolute pebkacism

#

i am victim of the 2 on a frequent basis

dawn wave
#

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 :)

eager chasm
#

go purple bar go ๐Ÿ˜„

dawn wave
#

huh funny seems like my lookup table is f'd

#

this is actually joever

#

that wasn't it

eager chasm
#

joever who?

dawn wave
#

we aren't coming back from this bug

feral trellis
dawn wave
#
/// 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?

devout mesa
#

Just a small warning

#

padding

#

Although I am not confident in that

#

Actually, it could never be that

#

no idea bleakekw

dawn wave
#

im gonna smash my face into a wall bro

devout mesa
#

Do you use scalar layout on everything

dawn wave
#

OH MY FUCKING GOD

#

that didn't fix it

devout mesa
#

bruv

dawn wave
#
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?

devout mesa
#

no you can't do scalar on that

#

Just try hardcoding 0 in your material data

#

see if it werks

dawn wave
#

that works

#

i can do 0-4

#

aka # of textures

devout mesa
#

I gotta clarify

#

not in your shaders

#

in your rust code

dawn wave
#

ah sure

#

heh

#

hard set it at 4

#

this is whati got

devout mesa
#

Well

#

there's your problem

#

check GPU side buffers with Nsight

#

Imma go schlepp now

#

good luck soldier

dawn wave
#

๐Ÿซก

#

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 KEKW as they're buffer views so i can't even attach a name

eager chasm
#

renderdoc time

dawn wave
#

i wish renderdoc doesn't work with rt extensions

#

oh

#

it works

#

i uh

#

i forgot to reflect my struct changes

eager chasm
dawn wave
#

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 ๐Ÿ˜Ž

devout mesa
#

do sponza

#

before I enter uncontrolled schlepp

dawn wave
#

bro my assset loader

#

is the most unoptimized steaming pile of crap

eager chasm
#

no excuses

dawn wave
#

it will take hours

devout mesa
#

it's 103 nodes

#

there is no way

dawn wave
#

yes way

devout mesa
#

???

dawn wave
#

you don't understand how unoptimized it is

devout mesa
#

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

dawn wave
#

it takes a good 10 seconds for me to load in the helmet

devout mesa
#

what

dawn wave
#

yea

devout mesa
#

sorry can you show me this code

#

I have to see for myself

dawn wave
#

sure

#

its a mess too

#

wait wrong branch @devout mesa

#

fn convert_data_type(

#

here it is

devout mesa
#

I am impressed

dawn wave
#

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

devout mesa
#

Well

#

I'll now take you a bit off road

#

You have textures for deccer cubes loaded yes?

dawn wave
#

yes

#

the loading textures ain't the issue it's the attributes

devout mesa
#

What happens when you get far away

dawn wave
#

aliasing

devout mesa
#

something else happens, related to textures

dawn wave
#

uhhh idfk mipmap issues?

devout mesa
#

yes, you see moirรฉ patterns all over the place right?

dawn wave
#

yeah

devout mesa
#

How do you fix this

dawn wave
#

you don- mipmaps

devout mesa
#

You already do mipmaps don't you?

dawn wave
#

yeah i just havent enabled them

devout mesa
#

try enabling them

#

see if the issue goes away

dawn wave
#

i will but it's buggy rn and i need to get textures 101 working

devout mesa
#

rip

dawn wave
#

well not buggy, just untested

devout mesa
#

then we'll do this tomorrow

eager chasm
#

all the jibberjabber, where is the screenshot!

dawn wave
eager chasm
#

ah it werks

dawn wave
#

it fixed itself

eager chasm
#

is that lustri's version?

dawn wave
#

hmm i just pulled it straight from the repo

#

dont tell me its wrong bleakekw

eager chasm
#

lustri is distributing his in #926896734284689428

devout mesa
#

it's not

#

I made a special version though ๐Ÿ™‚

eager chasm
#

erm you made me forget abuot, that L asked for sponza ๐Ÿ˜„

#

where is sponza ๐Ÿ˜„

devout mesa
#

the special sponza?

dawn wave
#

i found bugs KEKW sponza is soon(tm)

eager chasm
#

alright you have 18hrs

dawn wave
#

keep bugging

eager chasm
#

!remind me 18 hr to bug danny and sponza

dawn wave
#

please dont remind

#

LETS GOOOO

eager chasm
#

!remind 18 hr to bug danny and sponza

hollow barnBOT
#

Alright deccer, I'll remind you about to bug danny and sponza in 18 hours. ID: 59145700

dawn wave
#

noooo

dawn wave
#

end times are upon us

eager chasm
#

hehe, gn8

dawn wave
#

๐Ÿซก

devout mesa
#

who needed special sponza again?

#

ah danny

eager chasm
#

danny after he made sponza work

devout mesa
#

yes try also special sponza

#

it's good for your gpu

#

trust

dawn wave
#

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 KEKW

#

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 bleakekw

dawn wave
#

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

dawn wave
#

fuck it

#

we're making a buffer

dawn wave
#

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

dawn wave
#

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

dawn wave
#

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");
tropic vigil
#

Lemme see

tropic vigil
#

The default is 1 byte (effectively zero) so you probably need to set it

dawn wave
#

OHHHH

#

it;s that 1024 * xx * xx thing

#

Oml

#

I think Iโ€™ll use bdas instead.

#

Oh wait I can just make ssbos nvm

tropic vigil
#

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

dawn wave
#

Hmmm true

#

My only issue is that

#

Wasted space

tropic vigil
#

Why wasted

#

It reuses a lot of memory behind the scenes

dawn wave
#

Oh I assumed the 1024 * xx * xx is pre-allocated space, no?

tropic vigil
#

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

dawn wave
#

Hmm yesh ig so I just donโ€™t like that I have to pre-set a fixed amount

tropic vigil
#

Hmm maybe dynamically growing scratch allocators is the way to go

dawn wave
#

Maybe? How would I do that?

tropic vigil
#

Can you open an issue for that

dawn wave
#

Alr will do

tropic vigil
#

Should be doable though

dawn wave
#

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?

tropic vigil
#

Just set the scratch size to a few mb

dawn wave
#

Scuffed fixed KEKW but good enough tbfh

tropic vigil
#

No need to attach to the graph if youโ€™re not writing to them on the gpu

dawn wave
#

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)

tropic vigil
#

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

dawn wave
#

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?

#

bleakekw I assumed it always unbinded or smth

tropic vigil
#

Yep

#

No the graph doesnโ€™t bind anything it just handles sync

#

Hmm i need a bit of a tutorial for Phobos maybe

dawn wave
#

Yes-ish

#

More examples tbfh

tropic vigil
#

Yeah they are just somewhat tedious to write bleakekw

dawn wave
#

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

dawn wave
#

ok crashes are gone

#

me when i had to simply increase scratch memory bleakekw

#

it is time

#

sponza

#

this sponza looks fucked up

#

why the wall

#

wtffff

#

hm what test textures exists

eager chasm
#

looks like youare randomly picking textures again

#

i see normal maps and albedo at the same time

dawn wave
#

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

feral trellis
#

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

dawn wave
#

wait the fuck

#

they can?

feral trellis
#

Which caused this for me

feral trellis
dawn wave
#

let me look into my buffer

feral trellis
#

Nothing stops a modeler to make UVs out of texture bounds (to cause repetition for example)

dawn wave
#

im omw to check my uvs

#

did i forcefully normalize then bleakekw

#

no i only did that to my textures

feral trellis
#

Aight

#

As long as you don't clamp uvs when loading in models you're good

dawn wave
#

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

feral trellis
#

Use mine ๐Ÿค“ KEKW

dawn wave
#

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

feral trellis
#

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

dawn wave
#

yeah

#

idk i want a way so i can do this

feral trellis
#

If you're going to stick with solely a rendering engine I'd say make it load a whole scene at once tbh

dawn wave
#

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.

feral trellis
#

'Tis how I do it

dawn wave
#

i need to get into the habit of using traits KEKW

#

hm should i load them manually

#

or rely on the gltf crate

feral trellis
#

gltf makes it 10x easier

dawn wave
#

lmao why are you loading it manually then KEKW

feral trellis
#

I'm using the gltf crate

#

The "manual" part is creating my gfx / rendering / entities objects

dawn wave
#

oh i was talking about if i should use gltf's crate built-in deserializer

#

instead of reading the buffers myself

feral trellis
#

Oh uhhh for that idk

#

I do that manually and tbh I've had no problems so far

dawn wave
#

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

devout mesa
#

I don't understand

#

why you are doing this garbage

#

literally load the things like a normal person

dawn wave
#

it's too spaghetti :(

devout mesa
#

Yeah, you're supposed to make it less spaghetti

#

not more

feral trellis
#

I load them in from the glTF

#

I do generate tangents though

dawn wave
#

hmm ok

feral trellis
#

(trait system does help a lot tbh)

dawn wave
#

i should probably make the trait system kekw i haven't been using them at all in my project

devout mesa
#
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

dawn wave
#

i am overthinking this bleakekw

devout mesa
#

yes

#

faaar too much

#

you are about to overflow the amount of overthinking

feral trellis
#

I mean tbh I can't blame you my whole engine is overthought KEKW

#

Not a good thing tho

dawn wave
#

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

devout mesa
#

why do you even have to convert back and forth

dawn wave
#

cuz i immediately throw my stuff on loading into asset storage

devout mesa
#

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

dawn wave
#

okok

devout mesa
#

It's easy, functional and will work for 99.99999% of models out there

#

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

feral trellis
#

Do one thing and do it well

#

If not then it's not its job

dawn wave
#

huh yeah but also wouldn't that be duplicating shared data?

feral trellis
#

What would?

dawn wave
#

the code he sent

#

eh ig it's neglible and in 99.999% of cases it doesn't really matter

devout mesa
#

I don't duplicate anything

#

What would I be duplicating?

dawn wave
#

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

devout mesa
#

I assume a sane glTF file

dawn wave
#

oh kekw

devout mesa
#

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)

dawn wave
#

oh then that makes life a lot easier

#

maybe i'm overthinking this because im constantly testing odd edge cases

devout mesa
#

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

dawn wave
#

gltf samples really made me go down a rabbit hole then huh

devout mesa
#

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

dawn wave
#

tf im jealous

devout mesa
#

gltfpack is free

dawn wave
#

ill see if they have rust wrapping

devout mesa
#

No need

#

it's not a tool you use in code

#

Or well, you shouldn't

dawn wave
#

OHH CLI

#

i see now

devout mesa
#

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

dawn wave
#

you are overestimating how smart i am KEKW

devout mesa
#

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

dawn wave
#

Oh yeah

#

how do you guys handle converting over your accessors to certain types and dimensions?

feral trellis
#

I just read the value slice as it was given to me

dawn wave
#

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 KEKW

feral trellis
#

Aka only (floats, ints, uints, and vecs of those)

#

Common data types basically since those are all I need (and support) anyways

devout mesa
#

position will always be vec3

#

normal will always be vec3

#

tangents will always be vec4

#

texcoords will always be vec2

dawn wave
#

yeah but the types

devout mesa
#

always float

#

unless you use quantization

#

in that case it may or may not be float, but you decide what it will be

dawn wave
#

ahh im gonna kms

#

wrote useless code ;kek

#

@feral trellis Sorry for ponging but why not use gltf's document wrapper for json?

feral trellis
#

Oh no I do

#

I just decompose it

dawn wave
#

oh so it's just semantics?

feral trellis
#
// Decompose the JSON document
        let gltf::json::Root {
            accessors,
            buffers,
            buffer_views,
            scene,

            images,
            materials,
            meshes,
            nodes,
            samplers,
            scenes,
            textures,
            ..
        } = json;
feral trellis
dawn wave
#

mkmk

feral trellis
#

I get gltf.document and then get root from that

dawn wave
#

ikik i was just confused why you were doing ,into_json

eager chasm
#

18hrs have passed

#

where sponza at

dawn wave
#

still not here :(

#

with randomly selected texture (tm)

eager chasm
#

yeah ๐Ÿ˜„

#

could be a feature

dawn wave
#

yeah the first ever gambling renderer

eager chasm
#

you heard it here first

dawn wave
#

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?

devout mesa
#

no

dawn wave
#

oh ok then

devout mesa
#

that transform will be 100% wrong

feral trellis
#

It's only the relative transform to the parent

#

So you need to iterate through all nodes to get its global transform

devout mesa
#

Also don't do it recursively

dawn wave
#

i- was doing it that way KEKW

devout mesa
#

Bruh

dawn wave
#

bruh how are you supposed to do it non-recursively?

devout mesa
#

wat

#
ptr = node;
transform = mat4(1.0);
while (ptr->parent) {
    transform = transform * node.matrix;
    ptr = ptr->parent;
}```?
dawn wave
#

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?

devout mesa
#

?

#

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

dawn wave
#

clearly

#

this one isn't

devout mesa
#

average rust lib

dawn wave
#

I'm gonna assume they didn't add it cuz rust memory safety

devout mesa
#

Maybe getting the transform of a node already gives you the fully transformed node?

dawn wave
#

if that were the case

#

all my prior screenshots

#

would've been wacked beyond comprehension

devout mesa
#

sorry, how are you transforming it right now

dawn wave
#

I am literally recursively going through the entire scene tree, multiplying the transforms then applying them

devout mesa
#

remember your DSA classes? Any recursive function can be transformed into an iterative function

dawn wave
#

haven't taken DSA classes KEKW

#

but yeah it could i think?

dawn wave
#

oh my

#

i forgor stack

#

i can literally make a stack of nodes that need to be processed

devout mesa
#

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?

dawn wave
#

eh who cares just do a stack loop

feral trellis
#

Seems like glTF spec itself doesn't contain the parent node

dawn wave
#

yeah but most gltf loaders will include a parent pointer for QoL

feral trellis
#

Yelp this one doesn't ig

#

It's not that big of a deal tbh I managed to do without it

dawn wave
#

it's ๐Ÿด'n time KEKW

#

yeah

feral trellis
#

I just start with the root node and go down from there

dawn wave
#

im makiung sure im not being dumb

#

wait nvm

#

Aw rust doesn't have variants :(

feral trellis
#

Wdym "variants"?

#

enums?

dawn wave
#

std::variant<int, string, type>

#

i kinda get it via enums yeah

devout mesa
#

bruh you have better variants

#

enums

#

Like 100x better

feral trellis
#

Yea

dawn wave
#

probably is

feral trellis
#

I mean you can also use unsafe unions but you shouldn't use unsafe for that

dawn wave
#

oh yeah i can do match and all that stuff

feral trellis
#

Enums are the way to go

dawn wave
#

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)

feral trellis
#

I mean it's kinda like the only way of doing this sanely

dawn wave
#

blud thinks im still sane after 2 weeks of non-stop graphics programming

#

you cannot lose what you don't have

feral trellis
#

Ok that's true lol

dawn wave
#

men we shall go on a mission to save that 0.0004 mb of memory ๐Ÿซก each byte counts

devout mesa
#

I can load 100 million triangles models into 1.5GB of VRAM

#

you're good

dawn wave
#

if I did the document wrapper it's uh questionable

eager chasm
#

when you see patterns emerge in the soup that is coleured micro tringles for debug isms

feral trellis
devout mesa
#

it's not good to stare at tiny triangles for too long bleakekw

eager chasm
#

like these 3d images which were popular in the mid 90s

dawn wave
#

oh my god

#

this is insufferable

#

why the hell does gltf's document wrapper not iterate in order bleakekw

dawn wave
#

LVSTRI, do you handle sparse accessors at all?

#

or you throw that to gltfpack to take care of

devout mesa
#

I don't think I have seen any glTF model that uses sparse accessors

#

at all

#

so no I don't handle them KEKW

dawn wave
#

๐Ÿค“ uhm ackshually

devout mesa
#

amazing

#

count is now 1

dawn wave
#

besides from the examples yeah

#

i really need to stop basing my gltf capabilities on those sample models KEKW

#

its making me overengineer for stuff that i will never come across

feral trellis
#

Well thanks for letting me know now I found a bug in my code lel

#

(yet it somehow worked out this whole time)

dawn wave
#

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 bleakekw

feral trellis
#

Ok then I guess am gud

dawn wave
#

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

feral trellis
dawn wave
#

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

feral trellis
#

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

dawn wave
#

but that however just covers the mesh, no? and not the primitive

#

unless I'm high

feral trellis
#

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

dawn wave
#

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

devout mesa
#

I mean

#

to be fair

#

primitive_index is a bad name if you refer to a mesh

dawn wave
#

noon i understand what they meant

#

primitive_index refers to the index the prim itself is in within the mesh

feral trellis
#

Node -> Mesh -> Multiple Prims

dawn wave
#

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

devout mesa
#

You should avoid it

dawn wave
#

really? Well the issue is a lot my test gltf file kinda don't have normals

devout mesa
#

wat

#

All khronos samples have normals

dawn wave
#

yeah but when i open some it will just say no normals??

#

but if you say so

#

i won't generate them

devout mesa
#

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

dawn wave
#

oh KEKW just default it all to zero?

#

ah

#

now that makes sense

devout mesa
#

You add the result to each vertex, smoothizing the normals

dawn wave
#

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?

devout mesa
#
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);
}
devout mesa
#

You want to duplicate your computations in fact

#

You will be adding the normal for every vertex you encounter

dawn wave
#

ohh i do the process at the end

devout mesa
#

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

dawn wave
#

eh fine ill change it so i just iterate over every mesh

devout mesa
dawn wave
#

its works for you so i mean

devout mesa
#

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 KEKW

dawn wave
#

im so fucking jealous

#

rust does have meshopt bindings but they're 3 years old

devout mesa
#

You could do it too, I just don't think RT needs meshlets

#

Er well

dawn wave
#

heh

devout mesa
#

It could use meshlets

dawn wave
#

yeah there is a recent paper that goes into using it

devout mesa
#

There's this thing I'm starting to work on for RT

dawn wave
#

yaa that paper

#

looks really interesting

devout mesa
#

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

dawn wave
#

RADV?

devout mesa
#

(opensource) Vulkan driver for AMD GPUs on linux

dawn wave
#

ahh i see

eager chasm
#

lustri? are you distracting danny with nanitebrainwormisms?

devout mesa
#

wasn't my intention frog_sweat

eager chasm
#

thihihi

dawn wave
dawn wave
#

fuck i realized your solution

#

won't work with mines KEKW

#

unless i do a decently large rework

devout mesa
#

how is it even possible

#

you are storing all vertices in a vector right?

dawn wave
#

ah wiat yeah

#

nvm it is

#

ill just need to throw everything into one monolithic buffer

#

then suballocate the hell out of it

devout mesa
#

????????

#

what the hell are you doing

dawn wave
#

magic

devout mesa
#

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

dawn wave
#

ahh fine

#

ill put it all into one vertex vector

devout mesa
#

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

dawn wave
#

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

devout mesa
#

god

#

fucking damnit

dawn wave
devout mesa
#
vector<Vertex> vertices;
load_primitive_into(vertices);
process(vertices);
bigger_vector.insert(vertices);```
#

do you understand

dawn wave
#

OH