#DARE (Danny's Awesome Rendering Engine)
1 messages Β· Page 4 of 1
my code doesn't even do type conversion
as it will auto return if it's the same type
which most are
so 
show me the new loading code
ill nuke it soon-ish after i fixed this stupid bug
it's not that bad actually
This is the best compliment I have recieved in my lifetime 
minus this garbage of course get_accessors_from_primitives
yeah that is garbage
This should instantly disappear but w/e
can't really find the bug though
it doesn't help that me and rust are infinitely distant 
yeah that's the issue. my tests are passing, smaller meshes work but larger meshes bork
try it out with the smol mesh that bork
Right I meant stepping in the code
the buffer is fine so this is really ethereal
ohh yeah
ill do that
but like my print statements kinda did that 
I can only accept print statements inside shaders
yeah
It's basically the number 2 major reason why Vulkan appealed to me so much
WAIT YOU CAN?
the number 1 major reason was validation layers
yes, you can't in OpenGL though π
it...
no way
debugPrintfEXT
All hail debugPrintfEXT
is there a vulkan extension that needs to be enabled as well?
i refuse to believe
it's this easy
no way
oh
phobos has abstracted this away from me
VkValidationFeaturesEXT as well
but you really shouldn't use validation layers in your app
just use vkconfig
what
ohh
use the built-in sdk stuff
oh phobos has indeed
hidden this away from me
AHHH I NEED TO STOP GETTING DISTRACTED
so uh
everything works fine

yet my uvs
scream otherwise
I LIED THEY DO
Mesh index: 67379424548
[Shader] My albedo_texture ID: 0.000000 - 2955270660
Now my critical thinking brain is telling me
67379424548 != 2955270660
Hear me out
so the issue was
actually how i represented my meshes
π€
Texture ID being float is also very concerning
kekw that is me being dumb
ill change it to int
iirc %i
struct ObjectDescription {
// 0 - None
uint64_t vertex_buffer;
uint64_t index_buffer;
uint64_t normal_buffer;
uint64_t tex_buffer;
int material;
};
hmmmm this should be fine?
sure
I just need to make sure to include the scalar block i think
scalar block layout will save your ass every time
yeah
hmmm
#[repr(C)]
#[derive(Clone, Copy, Hash, Eq, PartialEq, Ord, PartialOrd)]
pub struct CMesh {
pub vertex_buffer: u64,
pub index_buffer: u64,
pub normal_buffer: u64,
pub tex_buffer: u64,
pub material: i32,
}
unfortunately I do not read Rust spec
so I dunno alignment rules
assuming Rust is a sane language, this should be fine
well repr(C) forces it to follow c alignment rules
Then it is probably fine, uncertain
so I think we should be fine?
do you have #pragma pack(push, 4)?
can you manually tell rust how to align a struct
i.e: I want to align this to 4 bytes please
WAIT FUCK
we don't
hehe
hehehe manual alignment
π
nvm we do
that uh didn't fix it
in fact i'm starting to think this debug output
is faulty
and wrong
that is extremely unlikely
it's weird how it;s only outputting that however
like you would think it would output other things too for other primitives
but it only outputs that
also tilting my camera too far will cause it to crash 
you may have your vkconfig set to call std::terminate on debug output
uhh where is that?
oh I don't think I did so
if you're talking about the Break under Debug Action
no it doesn't
but oddly only happens with the vkconfig validation layer
what
the bug fixed itself
what the

it seems like one mesh is causing the behavior
ah yes
bugs fixing itself
or as I like to call it
undefined behavior
or unacceptable behavior

ill uh hunt it down
it's weird it only happens when the validation layer is on only but the vkconfig one
the one phobos has doesn't crash
just for the record
validation layers are one and the same
the ones enabled through the app and enabled through vkconfig
they call into the same functions and use the same parameters
oh

Seems like it's the GPU base causing the crash
i lied it was the printf
debugPrintfEXT("My albedo_texture ID: \n");
I have no clue how this is even causing the crash
WARN phobos::core::debug > [VALIDATION]: UNASSIGNED-DEBUG-PRINTF (-1841738615): Validation Warning: [ UNASSIGNED-DEBUG-PRINTF ] Object 0: handle = 0x203f484d020, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x92394c89 | WARNING - Debug Printf message was truncated, likely due to a buffer size that was too small for the message
I thought the message size only applies to per-message
does it apply to the entire log?
btw @dawn wave you can add extensions in phobos just fine
i think so, it writes to a hidden global ssbo
if you call debugPrintfEXT too many times you will overrun the buffer
you are supposed to call it once per subgroup or only in one or two invocations
it is not a tool to be used lightly
hm how to have it run once
if (all(equal(gl_LaunchIDEXT, ivec2(0))))
gotcha thanks
Mhm crash is no more
that was it thank you
I have unfortunate news huston
the addresses lineup
so it's not input
67379780100 = 67379780100
i need to think harder
the issue must be import then
ah i'll nuke the accessor function
and redo that and see if that fixes anything
Is there a gltf viewer that allows me to read the buffer data decoded?
okay so my buffer is correct so it isn;t the loader at least the accessors
images...
not images too
dafauq is causing it then 
Ahhh can someone look at my shader again
I'm talking the UV data from the gltf file
then using that directly to determine the UVs
yes, i have tried to invert the v component
JAHAHAHAAH
i found my first bug replication
clearly
something is wrong
(rotated wrong)
barycentrics are supposed to be vec3(1 - u - v, u, v) if that helps
hmm okok
does this look right...?
const vec3 barycentrics = vec3(1.0 - attribs.x - attribs.y, attribs.x, attribs.y);
this should be correct UVs
I mean I doubt NVIDIA would provide you with wrong barycentrics 

hmmm
now it's time to trial and error
each gltf file
and find the common demoninator
i realized the duck models are the same 
it's just that they have diffenet lighting

now the average person wil say
"Wow, the channels seem reversed"
ya
maybe the indices are f'd?
that can't be possible however
if indices were f'd
vertices would be
so what
it works with stupid simple meshes

probably
as simple meshes work fine
/// Convert a slice of bytes as another
fn cast_bytes_slice_type<
T: 'static + num_traits::ToPrimitive + bytemuck::Pod + Sync,
U: 'static + num_traits::NumCast + bytemuck::Pod + Send,
>(
contents: &[u8],
) -> Vec<u8> {
// If same type, return early
if std::any::TypeId::of::<T>() == std::any::TypeId::of::<U>() {
return contents.to_vec();
}
let from_size = std::mem::size_of::<T>();
let target_size = std::mem::size_of::<U>();
assert_eq!(contents.len() % from_size, 0); // Must be perfectly sliced
// Cast contents (bytes) -> T -> Cast to U -> Reinterpret back to bytes
let contents: Vec<U> = bytemuck::cast_slice::<u8, T>(contents)
.par_iter()
.map(|x| num_traits::NumCast::from(*x).unwrap())
.collect();
bytemuck::cast_slice::<U, u8>(contents.as_slice()).to_vec()
}
ah.
ah.
ah.
ah.
this is all uselessly clamplicated
don't you have a way to memcpy all the uvs of a primitive into a vector
it's a oneliner in C++
no
i could just memcpy it all
you must
yeah but type conversions :(
do you need those
have you actually come across a mesh where this code actually does something
I haven't
well regardless
right that's one type conversion I will allow
sometimes models do come with u16 indices
but others are just useless
I'm not even telling you to nuke this code tbh
Just shelve it somewhere and use it when it is needed
Otherwise a memcpy will suffice
ill quickly override it
Holy moly
Why all of this bro
bytemuck does it for you no?
ah fuck
If you're doing numeric conversions just use as
misinformation
kekw rust doesn't let you
as least with generics
common rust L
i had to use num_traits
tried adding a + Into<U>
complains about it being a non-primitive cast
Oh yea with generics you can't
Forgot to type the 't
we live another day
Still odd that you'd require to do something like that though
Where do you call cast_bytes_slice_type?
It's so I can do this
regardless
cast_bytes_slice_type<u8, u32>
cast_bytes_slice_type<u16, u32>
cast_bytes_slice_type<..., u32>
It seems overcomplicated nyo capperinos
yeah but complicated thing better
shrimple first
no
again
- make it work properly first, doesn't matter if the code is slow
- refactor
to be fair
it'll probably be faster
but ye
at the cost of sounding like a broken record, KISS
They even made a wiki page
Yess I love kiss (KISS)
that's one less place to look at then
hmmm mismatched accessors?
nope
Tex buffer used by: Some("V-Tech_0 0"). Index: 6. Name: Some("V-Tech_0 0 accessor Gltf(TexCoords(0)) 6")
π«‘ ethereal bug
after a whole day of bug hunting
this bug alludes me
π«‘
indices can't be wrong.
i know that for sure
bro i'm so done with this bug man
i've verified that my buffers are indeed the same
wtf do i do
is it because the gltf package is importing things wrong?
this is just sRGB vs non sRGB
Ahhhh i havenβt learnt much of that yet
IH NY GOD
IS IT BECAUSE OF SRGB
NO WAY
OH MY FUCKING GOD
IS IT BECAUSE OF THAT?
NO WAY
srgb won't make a chunk of sponza have 0 uvs
my reference sponza image is srgb btw
looks correct now
epic
i'm crying rn this bug is a menace
0.012300 29.703600 i:40 id:37
π€
it seems fucked
this be the uv?
definitely fucked yes
it actually looks like the x and y components are swapped
i tried doing that
but it ends up fucked
ill play around with it
shifting does not help
ill try to reverse uit
0.012300 14.850000 i:62 id:37
uh
this seems wrong
swapping did not work
there is an offset
i can't figure out why
it seems to be -1.000
meaning UB
Buffer [0.6061, 0.9925]
vs
Shader -1.000000 0.606090
like it's obvious what the data is supposed to be
what are you comparing
data in the buffer itself
wdym?
yeah it seems to be a shift
at least you have a lead
hmm
layout(buffer_reference, scalar) buffer TexCoords { vec2 v[]; }; // TexCoords
I believe this is fine for Vec2_F32
layout(buffer_reference, scalar) buffer Indices {ivec3 i[]; }; // Triangle indices
HMMMMM
all my indices should be uint
that fixed nothing

a shift that randomly appears...
I really don't think the issue is in the shader
as a quick test you could try displaying gl_PrimitiveID
Well my buffer says everything is perfectly fine
hmm ill try
but I doubt that is the issue
ye, it's how you memcpy it into the phobos buffer
if there is a mismatch between what the GPU sees and what the CPU sees
I checked already on the GPU
then the vkCmdCopyBuffer or the memcpy(buffer.mapped, ...) is wrong
there wasn't any issues

it is pulling a -1.000 out of it's arse
maybe i'm calculating my offsets wrong?
see shifting it back
by 4 bytes
reproduces it
uh i'm a bit stupid
how would I convert a bufferview's vkaddress (962140119452) into an index usable by nsight?


wtf am i supposed to do then
go into the device memory tool and find the buffer
wym convert
take the address given and find the index
yeah no that's not how addresses work
pain
GPUs too use virtual memory
this is a problem i cant seem to fix
i got zero clue what is causing this
My buffers on cpu are fine
gpu seem fine
but that assumes the offsets are right which i assume they would be
maybe this is some fukery related to alignment?
But buffers aren't subjected to those same rules
I can't compile your shit
error[E0560]: struct `phobos::image::ImageCreateInfo` has no field named `memory_type`
--> src\assets\scene\loader\gltf.rs:769:21
|
769 | memory_type: phobos::MemoryType::GpuOnly,
| ^^^^^^^^^^^ `phobos::image::ImageCreateInfo` does not have this field
|
= note: available fields are: `width`, `height`, `depth`, `usage`, `format` ... and 3 others
match image_data.format {
Format::R8 | Format::R16 => vk::Format::R8G8B8A8_UNORM,
Format::R8G8 | Format::R16G16 => vk::Format::R8G8B8A8_UNORM,
Format::R8G8B8 | Format::R16G16B16 | Format::R32G32B32FLOAT => {
vk::Format::R8G8B8A8_UNORM
}
Format::R8G8B8A8 | Format::R16G16B16A16 | Format::R32G32B32A32FLOAT => {
vk::Format::R8G8B8A8_UNORM
}
}``` also wtf is this
shhh
you return the same thing all the time
will it even work on your system 
main.rs 102 is where you indicate file location to load assets
SER?
shader execution reordering
oh heard that new tech was really good for having a shit ton of shaders
also changes pushed
"use of unstable library feature" what
how do I do that
rustup install nightly
rustup override set nightly
do in the project directory
oh yeah ignore anything to do with transition layout 
it was blindly copy pasting it from older code
so it's gonna produce errors
oh yeah scroll wheel to increase camera speed
damn it's unbearably slow
no, the loading
oh yeah it's shitte
i made it all single threaded
cuz i became paranoid it was misordering of stuff
oh then it's doodoo architecture
or the gltf importing
i'm using the default one by the package 
that might also be why
ill try to add padding and see if that fixes it
istg if this was padding issues this whole time
@devout mesa IT WAS PADDING
LMAOOOOO
IT WAS FUCKING PADDING
this man managed to get a padding issue with scalar block layout
idfk how i did it too
all my types are multiples of 4
oh no
problem still exists
manual padding
you know
i think you were right
in the idea of making giant f32 vecs
dealing with the mess that this is
oml
It isn't that bad nvm
I compacted all my buffers into one vector which is why i got alignment issues. I didn't align them
tears in my eyes
i need mip mapping
was it padding?
yeah
So I was storing it all into one monlithic buffer
but storing it as bytes
so I could just throw it all into it
and I forgor padding
it was a simple fix. alignment - (offset % alignment) where alignment is size of dimension * component_size
epic
i'm gonna settle of linear mip maps and no more none of that fancy compute shader stuff with like trilinear or smth whatever penguin did
I'm afraid, but mipmaps are a sort of fever dream with RT
it's not as easy as enabling them
well go ahead and try different things
oh no
Could you uh
not use distance from origin to hit to determine the mip map level?
or am I beyond brain dead
not really
I know that they're smaller compressed versions of their original textures which are then selected depending on their distance
I'm strictly speaking about selecting a mip btw
and no, they are not selected based on distance
when you call texture the hw will compute a gradient for your uvs and compute partial derivatives
these derivatives are used in the formula 1 + floor(log2(max(dudx/dudy, dvdx/dvdy)))
mhm
this ain't possible with RT
because you don't have triangles from neighboring invocations to take derivatives from
you have rays
and rays can intersect any triangle of the scene
so you get ridiculous numbers
mhm
therefore
I present to you two solutions
The second one is easier than the first one, but exponentially more expensive
ray cones
:D
so this mayber
is worse

this looks like hell
so does a ray cone
basically simulate what we want from the pixel quad?
Oh 
so good luck
LVSTRI i'm gonna join you in radiance only
textures are for nerds
oh
they have code
thank god
okay we're safe
oh
it isn't that bad
huh
I think I understand it?
Oh it makes sense
ah fuck this
let's do actual ray tracing
i'll get punctual lights working
then it's off to the rays
i wanna pretty lights not mf debugging
one piece of advice
iteration >>> recursion
do not even consider recursion where possible
yeah i've learnt that from the nvidia
recursion -> oh no
me when my shader exponentially recursively grows
ahh i need to restudy raytracing theory and all i completely forgor it all

just random
Integration -> Sum
bro legit just do
for (bounce = 0; bounce < N; ++bounce) {
trace_ray();
if (hit) {
ray_color *= hit.material.color;
incoming_light += hit.material.emissive_strength * hit.material.emissive_color * ray_color;
ray.origin = ray.origin + ray.t * ray.direction;
ray.direction = random_lmao();
} else {
break;
}
}
imageStore(output, gl_LaunchIDEXT.xy, incoming_light);
start shrimple ok
AHHHHHHHHHHHHHHHHHHHHHHHHHHHH
alignment
once again
/// Represents the material c-struct for use in shaders
#[repr(C, align(16))]
#[derive(Copy, Clone, PartialOrd, PartialEq)]
pub struct CMaterial {
pub albedo_texture: i32,
pub albedo_color: [f32; 3],
pub normal_texture: i32,
pub emissive_texture: i32,
pub emissive_factor: [f32; 3],
}

this still doesn't work
yeah but it's complaining about the stride not be a multiple of 16
who's bitching
the validation layer
and it crashes
ERROR phobos::core::debug > [VALIDATION]: VUID-VkShaderModuleCreateInfo-pCode-01379 (706474367): Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-01379 ] Object 0: handle = 0x2283e778f30, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x2a1bf17f | SPIR-V module not valid: Structure id 40 decorated as Block for variable in StorageBuffer storage class must follow relaxed storage buffer layout rules: member 0 contains an array with stride 36 not satisfying alignment to 16
Do I just bite the bullet
and add padding into the struct itself?
yes
are you sure
layout (set = 1, binding = 2, scalar) buffer MaterialDescription_ {
MaterialDescription m[];
} MaterialDescriptionArray;
Seems very scalar to me
also alignment issues somehow still exist 
/// Describes the material properties of the object
struct MaterialDescription {
// -1 - None
int albedo_texture;
vec3 albedo_factor;
int normal_texture;
int emissive_texture;
vec3 emissive_factor;
};
ahhh ill bite the bullet
and just throw junk data for padding
btw
I use vec3's all the time with scalar block layout
And there has never been any complaint, so there must be something wrong
did you recompile your shaders
wat
i don't get it either
you weren't doing that?
no i was letting phobos do it
it was probably tightly packing all of it
which is possibly why it borked
yeah and i end up with alignment issues with me textures
it's how i ended up getting a normal texture of a flower to show up
100% certain
this is the same behavior
of misaligned (these are supposed to be normals)
uh
I dunno what kind of issue this is tbh
it could be a skill issue
or a Rust issue
or a phobos issue 
no way phobos
mfw the normals give me the tangent
this is a certified alignment moment
it betrayed me
f32, int
shouldn't cause issues
why
WHAT DOES THIS
EVEN MEAN ANYMORE
ERROR phobos::core::debug > [VALIDATION]: UNASSIGNED-Debug-Printf (-1804403757): Validation Error: [ UNASSIGNED-Debug-Printf ] Object 0: handle = 0x1b44e54a300, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x9472fbd3 | Error during shader instrumentation: line 176: Structure id 40 decorated as Block for variable in StorageBuffer storage class must follow relaxed storage buffer layout rules: member 0 contains an array with stride 36 not satisfying alignment to 16```
array elements must align to 16 bytes
they are 
there is no array in the material struct
was
also what the hell is that rule, never heard of it lol
do I just change my struct to align(16)?
it also holds for non scalar
I mean
your MaterialDescription struct is 36 bytes
just pad it manually to 48
imo
well my vulkan is built different
lol
hmmm
I have a buffer that's 1584365 bytes in size
so i figured it out
it seems to think
wait
it's a shift
again
oh my god
no i refuse to deal with this
if i pretend the issue does not exist
it doesn't exist π
it's obvious as
- this does not affect smaller meshes
- this does affect larger meshes
- it's a small shift of 1-2 indices
kowalski analysis
struct MaterialDescription {
// -1 - None
vec4 albedo; // xyz is factor, w is texture (cast to int)
vec4 emissive; // same
int4 normal; // x used, yzw unused
};
this is what i would use
what about them

i'll yoink and twist that
this wouldn't be align to 16 bytes however
wait i'm brain dead
please ignore me
it does 
4*4
i literally forgor
Praige
no work :(
WAIT
THIS WAS BETRAYAL BY MY ASSET SYSTEM
plot twist of the century
lmao
well you see, uint8
to determine the index of the image and not my image
hehehe
now uh how do i make an image that i can use to average out my results
i forgor
make storage image
if (pc.frame_id > 0) {
vec3 old_color = imageLoad(old_image_in, ivec2(gl_LaunchIDEXT.xy)).xyz;
// Calculate contribution ratio of this frame's color data
float a = 1.0f / float(pc.frame_id + 1);
// Mix the old and new colors together
vec3 final_color = mix(old_color, hit_value, a);
// Store to the image
imageStore(rt_out, ivec2(gl_LaunchIDEXT.xy), vec4(final_color, 1.0));
} else {
// This is the first frame rendering this scene, we don't need to do any
// accumulation, simply store the value
imageStore(rt_out, ivec2(gl_LaunchIDEXT.xy), vec4(hit_value, 1.0));
}
increment frame_id and reset when anything changes
hmm okokok
why do you want to average results you don't have
first you get results
then you average
you're not wrong
I will not allow you to write averaging code until I see a noisy image
generate 3 random numbers with a normal distribution
normalize the result
a normal distribution is spherically symmetrical
Im not sure if thatβs uniform
it's uniformly distributed on a unit sphere
lemme get the source
uh how would I calculate the final color
see here
maybe I'm stupid but how is ray_color relevant then?
I forgor to mul it by the inc light
lmaoo okok it makes sense
there
ah fuck i forgot
in emissive textures
R channel is the only one you only care about yeah
no im stupid
i am begging
can i finally average :D
pls
good, you may average
ik one doesn't have it
no :(
yes
nuh yh
ok fine
π«‘ goodbye pc
there has to be a better way of formatting my images
it takes up 90% of my loading time
for doing something relatively minor
I have never had to poke an image's format btw
o-
I just don't care about it
either rgba8 srgb or unorm depending on the texture
right, no one supports rgb8
just use rgba
yeah but that means i have to go through each pixel and add an A channel
what kind of textures require you to do that
huh i assumed you had to add the a channel
no I mean
or else it would end up taking the next pixel's R channel
usually you can load base color and normal textures as rgba just fine
I recall
hmm
yes you mentioned your gltf library being dumb and stupid
yeah
it doesn't automatically format the images i import in
as rgba
nono it insist
i take the rgb
because uh

I'll probably find another image import crate
that can do that for me
yes
sun
I'll leave that as an exercise
hint: you don't make a sun by making a literal flaming ball of death
you use good ol math
probably but rn i should focus more on getting my entire engine polished
shrimple then refine

pretty graphics rule
ReSTIR any%

think, what is a sun ray
let me add averaging
a sun ray is a sphere?
what direction do sun rays have
think about the sun irl
yes
well 150 million km away but we can consider that infinite distance
so we can think about sun rays being always in the same direction
ie parallel to each other
now how do you trace a sun ray
you just point that ray in the direction to the sun
yes
wait how would i add this nicely
without having to do a seperate ray trace
for the sun for each bounce
what happens then
if it misses, then it's in the sunlgiht therefore sun
the final bounce?
yes
it's phobos thingy
hmmmm
does this resource last
or is it just a per-frame thing
judging by how it's being refreshed every frame
i assume so?
where sun
sun :D
π
i forgor how to make another shader
and tell it explicitly to use that shader
they are the best solution to an impossible problem
what about that new out order shader execution thingy
then i;ll target only for 40 series
you don't even have a 40 series card
amazing
unfuck it then
doesn't look like sun to me