#Iris - A Journey through OpenGL and beyond to learn Graphics

1 messages · Page 17 of 1

wicked notch
#

it's still gonna merge some stuff but oftentimes it's good enough™️

#

uh it's -kn btw

#

-km was for materials

delicate rain
#

I'll try both

#

we kinda rely on our meshes having few primitives

#

well not few but it does not scale well with increasing number of primitves

wicked notch
#

aren't you and potrick meshlet enjoyers

#

it shouldn't matter innit

#

ah wait potrick has the instance culling madness

delicate rain
#

Uh it does matter because of the way we store the data

#

each mesh has an array of primitive indices so that we can allocate GPU buffers and all

#

and the size of this array is set globally

#

(-:

wicked notch
#

I don't follow

#

is this for software meshletisms?
(no mesh shader)

delicate rain
#

yes no mesh shader

wicked notch
#

then I do follow

#

rip

delicate rain
#

yeah

#

mesh shader soon as I get new GPU

#

but even if we do mesh shaders, we still would have

struct GPUMesh
{
  PrimitveIndices[MAX_PRIMITIVES_NUM]
  Transform
  BlaBla other data
}

no?

wicked notch
#

mm I like using ranges and having it all separate

delicate rain
#

so your primitive indices are hiden behind another indirection?

wicked notch
#

I set a fixed budget for max primitives and max vertices and allocate gpu buffers with those

delicate rain
#

I see, uhh hmmm it would be like 10th indirection lmao

#

I'll talk to Patrick

wicked notch
#

it's fine

#

we're already memory bound anyways

#

but I haven't profiled in depth so perhaps some investigation™️ is in order

delicate rain
#

We'll see how it goes

wicked notch
#

everyday I wonder why expression statements are not standard

glass sphinx
#

thats just the meshlet layout from nvidia/ the one meshoptimizer gives us

glass sphinx
wicked notch
#

ye, I prefer to keep stuff separate so I can avoid duplication of stuff

#

like two meshes can share a primitive, so I decouple meshes from primitives

glass sphinx
wicked notch
#

mesh info, meshlet info and primitive info

glass sphinx
#

you talk in gltf terms

wicked notch
#

oh ye primitive in the gltf meaning

glass sphinx
#

we call primitives meshes and meshes mesh groups

wicked notch
#

ah I see now

glass sphinx
#

i thought you mean triangles with primitive

delicate rain
wicked notch
#

terminology is hard kekkedsadge

#

why does the same word mean 634712763 things

delicate rain
#

That's why we have //gltf mesh is our mesh group and //gltf primitive is our mesh all over

glass sphinx
delicate rain
#

👾

glass sphinx
#

we allocate primitives into their own buffers so they are able to be unallocated if we want that

#

simpler to think about imo, one buffer = one primitive

#

doesnt really matter tho, the same in the end

glass sphinx
wicked notch
#

ye

delicate rain
glass sphinx
#

ah the cope

#

yea

delicate rain
#

Now they are in an array which is some other place in memory

#

Yeh

glass sphinx
#

luckily we nearly never pay that price

#

we solve the indirection on cpu

#

when we create the draw lists

#

gpu never needs to do the indirection, it just eats mesh + entity pairs prepared from cpu for each frame

delicate rain
#

Beast abstraction

glass sphinx
#

now i just need to fix the retard pointer access corrupting tidos buffers

#

im close

wicked notch
#

btw zeux is working on a better shrimplifier that will make my job so much easier froge_love

primal shadow
#

I sadly don't have mesh shaders either (webgpu)

delicate rain
#

Thanks froge_love I'll check it out once I'm on my PC again!

primal shadow
wicked notch
#

JetBrains will soon release a software to write plain text and call it "The most advanced writing tool ever"

#

though I have been liking Writerside

#

it's nice to have first class support for both markdown and LaTeX

delicate rain
#

Reject modernity, embrace overleaf

primal shadow
primal shadow
#

@wicked notch couple questions:

#
  • Why do you have to lock meshlet borders before simplifying?
  • What METIS API do I use for partioning the graph?
  • How do you project whatever this "error" metric meshopt's simplify gives to screen space pixel size?
  • Do you use meshopt's meshlet builder for the initial clusters, or metis for that too?
#

I don't get why subdividing without locking can cause seams

#

METIS insits on 2 letter variable/API names -_-

#

the heck is ncon

wicked notch
#

I use PartGraphRecursive

wicked notch
wicked notch
#

there is a handy manual for metis, you need to read it at least 45 times before you figure it out though

#

you can project the error in many ways, I just scale it by the size of the sphere in screen space (this is stupid though, do what unreal does)

primal shadow
#

Thanks!

primal shadow
#

Do I understand the steps correctly?

  1. Split mesh into initial meshlets
  2. While meshlet_count > 1:
  3. PartGraphRecursive, target partitions = meshlet_count / 4
  4. For each group, simplify group
  5. For each group, build meshlets within that group (same as step 1.)
  6. Goto step 2
#

Meshoptimizer and metis already implement the hard parts for simplifying and graph partioning, I just shell out to them and move the triangle data around

#

Seems easy

#

Also mind giving me a list of all the dumb edge cases that break things that I should know about 😅 ?

wicked notch
#

hehe

#

he_doesnt_know.meme

#

yes there are so many edge cases that meshoptimizer's mesheltifier just straight up fails, also you forgor a step (building locality info)

#

the most infamous edge case are disconnected meshes

#

then you have the fact that partgraphrecursive doesn't give you a strict upper bound on partition size

#

after that you have to solve vertex welding for close vertices so you have to build locality info between edges of triangles

#

this brings its own set of edge cases like:

  • what if vertices are close spatially but UVs are completely opposite of each other
  • same thing applies for normals and tangents, but at least you can recompute those if you accept some more error
#

there are more edge cases but I have an exam

faint crane
#

Edge cases are the friends we made along the way.

primal shadow
primal shadow
wicked notch
#

also it's strictly required for triangle/vertex limits for meshlets no?

#

partitioning triangles will meshoptimizer will not work

#

it's unusable for any LOD level other than 0

wicked notch
#

locality info just refers to triangle-to-triangle (or meshlet-to-meshlet) distance info

#

building locality info means building edge weights for adjacent triangles

primal shadow
primal shadow
wicked notch
#

even for the leaf LODs

#

meshoptimizer will just not work, forget about it for generating meshlets

primal shadow
#

So, meshoptjmizer for simplify only

wicked notch
#

it prefers topological locality to spatial locality

primal shadow
#

Sadge

wicked notch
#

yeah

primal shadow
#

Well in that case it's more of a problem as metis can't guarantee partition size to ensure <= 64 triangles 😭

#

So manually fixes and such necessary:/

#

That's depressing

primal shadow
#

Even with the manual, METIS_PartGraphRecursive is so dumb

primal shadow
#

I don't get how to build the initial meshlets

#

each node in the graph is a triangle, ok

#

what the heck are the weights supposed to be?

primal shadow
#

How the heck do you turn those into per-triangle pair edge weights

primal shadow
#

Atl for now I feel like I should just use meshoptimizer's meshlet builder

wicked notch
#

I am

#

free

#

time to eep for 48 hours

primal shadow
#

When you have time to answer questions, I'd like to know how you merge the vertex/index buffers for meshlets. I'm curious if you have to group meshlets based on their real original-mesh vertex IDs, or if using the local indices/vertices to the meshlet is fine.

wicked notch
#

they remain the same after initial clustering

primal shadow
wicked notch
#

The vertex buffer remains the same

#

the index and primitive buffers change per LOD level

wicked notch
primal shadow
#

I think METIS is actually just this easy

// Group meshlets into roughly groups of 4, grouping meshlets with a high number of shared edges
let mut xadj = vec![];
let mut adjncy = vec![];
let mut adjwgt = vec![];
for meshlet_id in simplification_queue.iter() {
    xadj.push(adjncy.len() as i32);
    for (connected_meshlet_id, shared_edge_count) in
        connected_meshlets_per_meshlet[meshlet_id]
    {
        adjncy.push((connected_meshlet_id - simplification_queue[0]) as i32);
        adjwgt.push(shared_edge_count as i32);
    }
}
xadj.push(adjncy.len() as i32);
let mut groups = vec![0; simplification_queue.len()];
Graph::new(1, (simplification_queue.len() / 4) as i32, &xadj, &adjncy)
    .unwrap()
    .set_adjwgt(&adjwgt)
    .part_kway(&mut groups)
    .unwrap();
#

Next up: simplifying each group

frank sail
#

you can use vowels in identifiers btw

primal shadow
frank sail
#

uh

primal shadow
#

This is what metis calls their parameters

#

I know, it's cursed

frank sail
#

I mean, "adjcny" isn't a random jumble of letters

primal shadow
#

Yes, but adjaceny isin't any better 😛

#

I'd rather just copy metis's name so it's easy to tell what's what when referencing the manual

frank sail
#

ok

wispy spear
#

: (

#

yes, please more unreadable spaghetti code

primal shadow
#

Why does meshopt_SimplifyLockBorder not work for meshlet LODs?

wicked notch
#

it does, I use that

primal shadow
#

Also I'm a bit confused on some things. You have:

  • Original mesh vertices
  • Meshlet lod 0 "vertices" (points into above)
  • Meshlet lod 0 "indices" (points into above)

When grouping meshlets, you use edges defined by the meshlet indices
When simplifying meshlets, you do the same?
When you split your groups into new meshlets, what do you do with that info?

#

Also hmm, I somehow need to pass the original mesh vertices to the simplkifier

wicked notch
#

I fail to understand what they mean by "outer border" of a mesh

primal shadow
#

Ok, so ignoring that

#

meshopt_simplify needs the original mesh vertex positions

#

But my index buffer for meshlets points into the meshlet vertices..

#

Am I supposed to remap the index buffer to the original vertices myself before simplifying? Or am I missing something

wicked notch
#

I just build another temporary index buffer tbh

primal shadow
#

When you split your group, do you just copy the group's error to each new meshlet?

wicked notch
#

yes

primal shadow
#

Cool, almost done!

#

Ok, testing time!

#

Also curious, did you call any of meshopt's vertex/index buffer optimization functions, before simplifying or building meshlets?

#

The docs imply they help a lot

#

I lost my example code to simplify gltf files 😬

#

Gonna need to write that again 😦

wicked notch
#

they do help a lot

#

having duplicate vertices/edges is horrible

primal shadow
wicked notch
#

just call all the optimization functions but the overdraw

hollow pagoda
#

does that one even help?

primal shadow
#

It crashes 😦

#

somehow I'm indexing out of bounds, somewhere

primal shadow
#

LOD 1 bunny. Seems a bit off...

primal shadow
#

LOD is not supposed to just remove meshlets and keep some others 😅

wicked notch
#

welcome to "the problem" I was talking to you about meshopt's generator

primal shadow
wicked notch
#

between triangles? spatial distance

#

inverse of the spatial distance actually

primal shadow
#

How do you get it to 64 per partition?

#

Oh it's just target partitions = triangle count / 64 ig

wicked notch
#

you bisection the mesh (i.e the graph) until it's within your vertex/triangle limits

primal shadow
#

You've lost me lol

wicked notch
#

you know how graph bisection works right?

#

it's just dividing the graph in two partitions

#

and assigning a good weight to said partitions

#

then, until the number of nodes or edges in the bisectioned graphs are within your limits, you keep recursively bisectioning

primal shadow
#

Hmm ok

pale horizon
#

I compiled GCC 13.2 and had to fight SPIRV-tools and KTX to get them to compile, but then...

~/work/repos_to_check/Retina/build$ ./RetinaMeshShadingSample 
./RetinaMeshShadingSample: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./RetinaMeshShadingSample)
./RetinaMeshShadingSample: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by ./RetinaMeshShadingSample)

bleakekw

#

That's it, I'm updating to Debian Testing and I hope nothing breaks bleakekw

pale horizon
#

@wicked notch it can't find Retina/test/Models/compressed/bistro/bistro.glb bleakekw

frank sail
#

download it

#

then gltfpack it

#

intermediate blender step may be necessary

pale horizon
#

Why doesn't CMake build not do it, 2/10 literally unusable

frank sail
#

lvstri doesn't want to upload multi-gb models to github listenyoupieceofshit

pale horizon
#

The build script can download it from somewhere gpAkkoShrug

frank sail
#

hardcoding my beloved

#

imagine figuring out blender's CLI and shit when you could just convert it yourself

pale horizon
#

Oh wait, Bistro is not even in glTF, I guess I have to export it manually via Blender, yeah

#

Most user friendly GP build process be like kekkedsadge

frank sail
#

at least I'm kind enough to keep a shrimple test model in my repo

pale horizon
#
~/work/repos_to_check/Retina/build$ ./_deps/meshoptimizer-build/gltfpack -i ~/Desktop/Bistro_v5_2/Bistro.gltf -o ~/work/repos_to_check/Retina/test/Models/compressed/bistro/bistro.glb -tc -tq 10 -vpf -kn -km -ke -noq
Error: gltfpack was built without BasisU support, texture compression is not available

bleakekw

frank sail
#

oh yeah, you need lvstri's gltfpack fork kekwfroggified

#

I wonder if his renderer has a fallback for non-compressed textures

pale horizon
#

Where can I find it though

frank sail
#

idk

#

I never tried running it lol

pale horizon
frank sail
#
  • ratio
#

you can still see his repos btw

#

somewhere

pale horizon
#

I did it by reading TFM

git clone -b gltfpack https://github.com/zeux/basis_universal
cmake . -DMESHOPT_BUILD_GLTFPACK=ON -DMESHOPT_BASISU_PATH=basis_universal -DCMAKE_BUILD_TYPE=Release
#

damn son

#

This, but only core 23 is looking and doing nothing KEKW

delicate rain
#

I think you can also try with the gltfpack from the releases page

#

That one definitely supports basisU

pale horizon
#

I compiled it anyways now gpAkkoShrug

#

gltfpack has been doing its work for 9 minutes now bleakekw

#

Hope it's not stuck in some endless loop KEKW

frank sail
#

it doesn't normally take that long

#

on my 5950X though

pale horizon
#

I have 7950X even bleakekw

frank sail
#

lol

#

buy a threadripper NOW

pale horizon
#

it's stuck here

#

IT DID IT

frank sail
#

high quality bc7 encoding be slow I guess

pale horizon
#

And that's it...???

#

I've been jebaited

#

RayTracing:

[2024-03-05 11:20:13.139] [Device] [critical] Required Extension "VK_KHR_ray_tracing_position_fetch" not supported

AMD sisters...

frank sail
#

what driver

#

RDNA 2+ supports it though

#

on windows

pale horizon
#
    driverID                                             = DRIVER_ID_MESA_RADV
    driverName                                           = radv
    driverInfo                                           = Mesa 23.3.5-1
frank sail
#

radv skill issue?

pale horizon
#

I guess. pixelduck, plz fix

hallow cedar
#

use newer mesa

#

24.0 should have it

frank sail
#

there are some radv reports here ye

#

old software-having mf

pale horizon
#

It's on Debian unstable, but not on testing bleakekw
Maybe some day it'll reach testing

hallow cedar
#

wat distro

pale horizon
#

Debian Tesiting aka trixie

frank sail
#

why is everything related to that distro out of date

hallow cedar
#

oh

pale horizon
#

Because stability(tm)

hallow cedar
#

"we keep things broken too" stability

frank sail
#

use arch (I don't know anything about arch)

pale horizon
#

soooo outdated

hallow cedar
#

i think the "stable" debian version of mesa has not been updated in literally a full year

pale horizon
#

That's what "stable" means, yes KEKW

#

They do stable releases every 2 years

frank sail
#

man that's a full gpu generation

pale horizon
#

And they only receive security patches

frank sail
#

that's the wrong distro for cutting-edge giraffix

hallow cedar
#

m'lady distro and arch loonix should have both by now

pale horizon
#

Debian Unstable has it, so it will land into testing eventually

#

I'm not brave enough to use unstable, but I guess it will be similar to Arch KEKW

#

m'lady distro
Gentoo? KEKW

hallow cedar
#

fedora

frank sail
#

fedora

pale horizon
#

Ah, Gentoo also fits, as it's the target audience KEKW

hallow cedar
#

gentoo should probably indeed have it too

pale horizon
#

If Debian unstable has it, everyone should have it
But I'll wait for now for it to hit testing anyways gpAkkoShrug

pale horizon
#

GP will force me to use Arch and buy programming socks mindblown

#

@wicked notch anyways, I had to do this for it to compile. Classic template bruh momento:

#

Also had to update KTX to the latest since they used some funny enum conversions which are deprecared + Werror
Also SPIRV-tools didn't compile for me, but I'll research it and will probably make an issue

wicked notch
#

yea nearly all of khronos' tools require some sort of hacks to compile

#

it's actually incredible how annoying it is

#

I should also make public my fork of gltfpack lol

pale horizon
#

I actually didn't need to use a fork, just had to pass it path to basisu

pale horizon
wicked notch
#

yes

#

it's due to the exam speedrunning

#

I am currently resting

pale horizon
#

Enjoy your rest 👍
I know how it feels

But also
REMOVE main PLZ AND USE FIXED COMMITS, OK THNX

FetchContent_Declare(
    spirv_cross
    GIT_REPOSITORY https://github.com/KhronosGroup/SPIRV-Cross
    GIT_TAG        main
    GIT_PROGRESS   TRUE
    GIT_SHALLOW    TRUE
)
set(SPIRV_CROSS_EXCEPTIONS_TO_ASSERTIONS ON CACHE BOOL "" FORCE)
set(SPIRV_CROSS_ENABLE_TESTS OFF CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(spirv_cross)

FetchContent_Declare(
    spirv-headers
    GIT_REPOSITORY https://github.com/KhronosGroup/SPIRV-Headers
    GIT_TAG        main
    GIT_PROGRESS   TRUE
    GIT_SHALLOW    TRUE
)
#

Because apparently they can have borked commits in main. Cringe

wicked notch
#

incredible

#

will do

pale horizon
#

I guess only 2-3 people in the world compile this stuff from main KEKW

wicked notch
#

I'm thinking to move to glslang anyways like jaker did

#

shaderc (and all its dependencies so SPIRV-Tools, SPIRV-Headers, etc.) have consistently given me pain

#

or, better yet slang, but I hear potrick is still fighting with the ptr guy KEKW

frank sail
#

yeah I'll let them cook for a few years

pale horizon
#

Cook FreeSLANG AMD(tm) Edition for us plz

#

glslang is glslValidator, right?

wicked notch
#

it should allow me to ditch many dependencies

pale horizon
#

So you're telling me there's the third glsl compiler? KEKW

wicked notch
#

I think this is just glslc and glslValidator combined

wispy spear
#

would be cool if khronosgroup just renames itself to JohnKhronos, it do be more authentic

pale horizon
#

Maybe after someone from the GP becomes Khronos chair KEKW

wispy spear
#

: )

wicked notch
#

JohnKhronos is not a person, it's a title

#

the ultimate title

wispy spear
#

John Khronos
John Khronos

#

works for me 😄

#

title adjusted for inflation: Senior Principal John Khronos

pale horizon
#

@wicked notch did you compile Retina on Linux before, btw?

wicked notch
#

many moons ago yes

#

but I use arch btw

pale horizon
#

I’m impressed that it only took me two lines to fix it
Compiling a random Vulkan anime engine now and it’s so full of MSVCisms, it hurts

wicked notch
#

btw

#
class NvidiaDlssFeature;
class NvidiaDLSSFeature;
class NVIDIADLSSFeature;
class nvidia_dlss_feature_t;```
#

choose

#

I'll let this go democratically

pale horizon
#

Nvidia don't know how to write their name too, I think KEKW

frank sail
#

just write it in spongebob-mocking style

#

nViDiA

finite quartz
#

NvidiaDeepLearningSuperSamplingFeature; froge_evil

#

or if too long: NvidiaDeLeSuSaFeature; 🎵

wispy spear
#

i also dont know if serious or not bleakekw

wicked notch
#

I kinda am

#

I am facing some issues with the C#isms

#

like get this

#
class Graph {
public:
  struct Partition {
    // ...
  };
  Partition Partition();
};```
#

but ultimately it doesn't matter too much

wispy spear
#

i decided to prefix mzy Fukisms with Fk

#

and can still go with Pascal style where i want then

#

ala

struct FkPartition { };
FkPartition Partition;

#

mayhaps Retina stuff can be ReThism or ReThatsm

wicked notch
#

makes sense

wicked notch
#

why the hell does glibc's format not implement 202311L features

#

fucks sake

primal shadow
#

Getting LOD building working is so difficult ugh

primal shadow
#

Oh hold on, does meshopt simplify take target index count??

#

oh, hell

#

Ok that's a little bit better, but still cursed, and still z-fighting

#

Ok back to sleep since that didn't work

#

Tm I should try visualizing the cluster groupings before I try and simplify

primal shadow
#

Hmm I think tuple_windows is not correct to generate edges 😅

#

ok yeah I see a lot wrong fml lol

primal shadow
#

Nope still didn't fix things ahhh

wispy spear
#

theres just one flaw with your code

#

its written in rust skull_laugh

wicked notch
primal shadow
#

I modified the code to throw away lod 0 after calculating lod 1

wicked notch
#

does renderdoc have any insight for us

#

do the meshlets appear scuffed or something

primal shadow
#

Hmm let me check in a bit, I just woke up lol

wicked notch
#

US moment

primal shadow
#

oh, wait, hold on

#

I think I was rendering both LODs

#

nope still looks weird though :/

wicked notch
#

is this all of LOD 1?

#

it's weird for only a section of the bunny to be scuffed innit

primal shadow
#

yeah

#

right??

#

And also even lod 0 looks weird compared to what it used to be

#

It used to be nicely distributed, but now there's some weird patches of small meshlets

#

But the code didn't even change

wicked notch
#

I guess you should first focus on fixing that then

#

scuffed leaf meshlets will inevitably lead to scuffed LOD'ed meshlets

primal shadow
#

I didn't even change anything though 😭

wicked notch
#

debugging is a core part of the process

#

at least you're not hanging your system, like I have many times KEKW

primal shadow
#

I'm litterly using the same test model and my previous branch and it's not working as well anymore -_-

#

This is bizzare

wispy spear
#

@wicked notch is there any chance that i can make you fix the archived Iris? master is not buildable as is : (

primal shadow
#

I'm checking out a much older commit, maybe I broke something at some point

wicked notch
#

git checkout saves lives

wispy spear
#

if you are not in the middle of learning for exams : )

primal shadow
#

no, older commit is still broken...

wicked notch
#

I shall hop on the penguin

wispy spear
#

GL

primal shadow
#

Even older commit is not wokring. Maybe this is a bad mesh?

#

time for blender

wicked notch
#

alright I'll dive into the deepest pit of hell

wispy spear
#

i think some fixes is using model.h vs mesh.h (which doesnt exist anymore) bt wants mesh_t plus a potential fix for its ctor if i saw that correctly to work in the older examples < 5.2

#

and the warnings from dependencies (looks like ktx is the offender here) need to be silenced

primal shadow
#

I mean looks fine

wispy spear
#

jasmine, mayhaps try suzanne or the deccer cubes?

wicked notch
#

we need deccer spheres tbh

#

to meshletize better

distant lodge
#

where is the PBR thread

#

those count

primal shadow
#

The thing is the bunny used to work fine

#

The meshlet_mesh I have saved is great

#

But trying to convert it again, even using a very old commit, looks horrible???

#

I feel like I'm missing something 😦

wispy spear
#

hmm

#

i thought there was a thread called This other mesh will also crash your engine or something similar

frank sail
#

deccer balls
deccer balls

distant lodge
#

yeah, I remember it being under a random channel

primal shadow
#

I think it looks ok?

distant lodge
#

is that the main LOD

wicked notch
#

somewhat

distant lodge
#

I remember the eyes having more detail

wicked notch
#

some of the meshlets look very small

wispy spear
#

hmm it looks also fucked somehow, the green center and white bttom one

primal shadow
#

Yeah idk what meshopt is doing all of a sudden

wicked notch
#

yeah this definitely does not look like the main LOD

distant lodge
#

I mean, I think I recognize some of the main geometry

#

maybe the debug view needs triangle outlines

primal shadow
#

I can switch it to per-triangles, 1s

wispy spear
#

i doubt the spheres will produce neat meshlets 😄

primal shadow
#

triangles look fine

wicked notch
#

is this just a very low poly suzanne?

wispy spear
#

yeah crank up subdivision

distant lodge
#

that's the default one, so I guess you've been using subdivision

primal shadow
#

mhm let me figure out how to do that

distant lodge
#

subdivision surface modifier

wispy spear
#

add modifier on the blue wrench symbol in the bottom right window

primal shadow
#

triangles

#

Btw, do I even need normals/tangents?? I can just bake detail directly, and use geometric normals derived from the triangle position with this amount of density no?

#

Well lod 0 looks great now

#

Lets try a different LOD and just give up on the bunny for now, idk why

#

Lod 1 looks the same??

#

heck

#

LOD 0: 1968 meshlets
LOD 5: 1968 meshlets
???
each LOD is just a copy of LOD 0
huh

wicked notch
#

try building now @wispy spear

wispy spear
wicked notch
#

epic

#

which errors

wispy spear
wicked notch
#

ah you're trying to build the old schtuff

#

yeah idk how to fix the old ones bleakekw

#

I don't remember anything about them

#

it was also an unwise decision to name those "5.0" and"4.2" kekkedsadge

wispy spear
#

let me comment out all the old projects

wicked notch
#

try building the "AntiAliasing" target

#

that should work

wispy spear
#

i wanted the 5.2 thing

#

ah ye

#

AntiAliasing 😄

wicked notch
#

I didn't finish implementing FSR btw, it's very aliased bleakekw

wispy spear
#

das ist ok

#

im mainly using this to learn me some c++ : )

primal shadow
#

I'm suspicious simplification isin't actually doing anything 🤔

wispy spear
#

because your code is somewhat readable

wicked notch
#

because simplifying can very easily fail

#

if you have lots of duplicated vertices or your error value is too small or your mesh is super disconnected

#

btw look at this guy

#

5.6ms to render bistro with some shadows

#

so slow

primal shadow
#

Each group has 4 meshlets, and after simplication and re-meshletifying, there's 4 meshlets... it's litterly doing nothing 😭

wicked notch
wispy spear
#

thats not correct

frank sail
#

glVertex5f

wicked notch
wispy spear
#

is that AntiAliasing.exe?

wicked notch
#

ye

wispy spear
#

ah

primal shadow
#

Simplification is litterly doing nothing

#
[crates\bevy_pbr\src\meshlet\from_mesh.rs:140:17] (simplified_group_indices.len(), group_indices.len(), error) = (
    384,
    384,
    0.0,
)
#

same triangle count before and after

wicked notch
#

step into meshopt and see why it's failing

#

my guess is bad triangle index data

primal shadow
#

yeah me too, lets find out

wispy spear
#

did you push the fix already lustri?

wicked notch
#

I hate ktx

wispy spear
#

: )

wicked notch
#

why is khronos like this

#

ffs

wispy spear
#

iirc if you target_link_libraries(iris SYSTEM ktx) it should be quiet somehow

#

but i kind of forgot how it really worked

wicked notch
#

how can they make the greatest graphics API in the entire universe and have the worst possible tooling imaginable

#

ok I push

wispy spear
#

because its also just a bunch of weird people and a bnch of smart people like everywhere else : >

#

your .gitignore looks interesting hehe

primal shadow
#

@wicked notch can you sanity check me, what are the steps to simplify meshlets? Which index buffers do you use?

wicked notch
#

the ones you generate anew from the grouped meshlets

#
for group in groupedMeshlets {
  vertices = [];
  for triangle in group.triangles {
    index = vertexIndices[group.indexOffset + triangle];
    vertex = vertices[group.vertexOffset + index];
    vertices.push(vertex);
  }
  indices = GenerateIndexBufferFrom(vertices);
  (simplifiedIndices, error) = SimplifyHalf(indices);
}```
primal shadow
#

What does GenerateIndexBufferFrom do?

wicked notch
#

calls meshopt_remapVertexBuffer and stuff

primal shadow
#

and vertex is an index into the mesh's original vertex data yes?

wicked notch
#

no vertex is the actual vertex

#

like position data

#

meshopt_remapVertexBuffer needs the original vertex data

primal shadow
#

hmm

#

I'm doing basically the same thing I think, just not calling any of the meshopt remapping stuff

wicked notch
#

you need to do that though thonk

primal shadow
#
let mut group_indices = Vec::new();
for meshlet_id in group_meshlets {
    let meshlet = meshlets.get(*meshlet_id);
    for meshlet_index in meshlet.triangles {
        group_indices.push(meshlet.vertices[*meshlet_index as usize]);
    }
}
wicked notch
#

in this particular case

wicked notch
#

yes, this is wrong

#

these are not the indices you want

#

you want indices local to the group

primal shadow
#

Why not? What indices should I be using, if not the concanated meshlet indices into the original vertex buffer?

wicked notch
#

you want to treat this group of meshlets as if it were your only mesh

primal shadow
#

I'm confused why that would make a difference tbh?

wicked notch
#

because meshlet.vertices is not really an index buffer

#

it does not represent the topology of the mesh

primal shadow
primal shadow
#

Once you build a list using meshlet.triangles into meshlet.vertices, do you not have a list of triangles?

wicked notch
#

meshlet.primitives is the topology meshlet.vertices is just a counter for how many times a certain vertex has been used

wicked notch
#

meshlet.vertices is a counter for vertex reuse

#

if you look at how meshlet.vertices is generated, you will understand

#

nevermind it's the opposite KEKW

#

yeah you're right

#

it should work

#

idk why it don't

primal shadow
#

But it dosen't 😭

wicked notch
#

did you figure out where meshopt is failing yet

primal shadow
#

No, going to go try and figure out how to attach gdb tbh

wicked notch
#

inside meshopt_simplify there's a prepass that classifies all the edges

#

look at what the classifier is doing

primal shadow
#

I think meshopt-rs is mapping a null ptr to a no-opt instead of telling me it's erroring 😛

wicked notch
#

does rust not have its own debugger? thonk

#

classifyVertices

primal shadow
wicked notch
#

I guess it all works the same independent of lang if you export the symbols ye

#

I figured the rust people would just "rewrite it in rust" 😛

#

@wispy spear it should work now

#

let me know

#

also damn it's almost been a full year since I started this thread

primal shadow
#

bash: gdb: command not found

#

ugh

wicked notch
#

pacman -S gdb

primal shadow
#
Running `cargo build --example=meshlet --package=bevy --release --features meshlet_processor --message-format=json`...
error: unexpected argument '--features meshlet_processor' found

  tip: a similar argument exists: '--features'

Usage: cargo.exe build --example [<NAME>] --package [<SPEC>] --release --features <FEATURES>

???

#

ok fixed

wispy spear
#

still no worki, lvstri, ill dinglefart from here, no need to be hanging on the penguin for me (for now)

wicked notch
#

it's ok I like the penguin :)

wispy spear
#

ktx's fmt dependency now complains about warnings treated as error

wicked notch
#

btw are you using clang or gcc

wispy spear
#

gcc

wicked notch
#

13.2 right?

wispy spear
#

yes sir

#

let me also yoink build once more

primal shadow
#

ok finally got a debugger attached lol

wicked notch
#

how am I not getting your same error with the same configuration

#

I'm also using latest gcc

primal shadow
#

vscode lldb is frozen wtf

#

I finally got into meshopt and now it's stuck -_-

wispy spear
#

heh still this one

wicked notch
#

can you try cloning the thing again

#

from scratch

wispy spear
#

when you updated submodules i dont have to do that, since you modified .gitmodules right

#

kk

wicked notch
#

man I'm glad I switched to fetchcontent lol

wispy spear
#

oof works now

wicked notch
#

pog

wispy spear
#

i did have to update the submodule myself

#

wtf

#

sorry for the interruption jasmine, luigi is all yours again

#

thx lustri ❤️

primal shadow
#

ugh the debugger just freezes all the time

#

I can't step in

wicked notch
#

yeah idk vscode

#

I think jetbrains has an IDE for rust now

primal shadow
#

nor can I kill my app anymore, it's frozen 😛

wicked notch
#

ye jetbrains has rustrover in EAP

#

which means it's free to use

#

maybe give it a try if it's not too much hassle idk

primal shadow
#

What exactly should I be looking for? I'm unsure why it's failing tbh

wicked notch
#

look inside vertex_kind

#

is everything Locked?

primal shadow
#

It's not showing up in my debugger, ahh what

wicked notch
#

I guess you can use the age old technique

#

std::printf to the rescue

primal shadow
#

It'll be annoying to figure out how to bind to a custom build of meshopt, sigh

#

Yeah the debugger doesn't recognize VertexKind, it's just binary

wicked notch
#

just printf tbh

#

I want to see LODs working

#

so get a move on 😛

#

(I'm kidding, but I do want to see your LODs working)

wispy spear
#

me too : )

primal shadow
primal shadow
#

Maybe it dosen't like that I'm passing the entire mesh's vertex buffer to simplify, instead of a stripped down one for just the meshlet vertices? idk

wicked notch
#

it's always great to read misinfo guy's ramblings KEKW

wicked notch
#

this ends up duplicating a lot of stuff so maybe having a deduplication pass later when everything has been shrimplified can be beneficial

#

the remapping will be hell though bleakekw

frank sail
#

who is misinfo guy? nervous

wicked notch
#

the FuckTAA guy, in #questions

frank sail
#

ah, no better way to start the day than with some entertainment from the court jester

wicked notch
#

real

wicked notch
#

is there a cursed way to avoid duplication here

frank sail
#

I delete them

#

Or rule of 0

wicked notch
#

what if you actually need a copy ctor bleakekw

frank sail
#

You could implement it the same way as my move semantics, where the assignment operator just calls the constructor

wicked notch
#

ye but you need swap innit

#
T::operator =(const T& other) {
  if (this == &other) {
    return;
  }
  T(other).swap(*this);
}```
frank sail
#

Why is swap needed?

wicked notch
#

I guess you could do it with placement new

frank sail
#

Yep

#

That's what I meant

wicked notch
#

yeah that's cursed enough

#

this placement new thingy is great, too bad it don't work when destructors are protected :(

#

and even if it did, the move constructor would be insane in derived classes

frank sail
#

why is it protected

distant lodge
#

thing::clone()

#

wow holy shit there wasn't even a hint my messages were behind what the hell is going on

wicked notch
#
class Base {
public:
  Base(Base&& other)
    : _state(std::exchange(other._state, {})) {}
private:
  T _state;
};


class Derived : public Base {
public:
  Derived(Derived&& other)
    : Base(std::move(other)),
      _moreState(std::exchange(other._moreState, {})) {}
private:
  T _moreState;
};```
wicked notch
#

I realized it in the end

distant lodge
#

isn't swap only really the elegant thing for move ctors, my understanding was that it was just a convenient way to let the old garbage in the lhs object be swept up because the dtor of the rhs object is about to be called

wicked notch
#

having the destructor protected that is

wicked notch
frank sail
#

delete this bleakekw

distant lodge
#

something about that seems inherently cursed

wicked notch
#

yes, that's why I hide it

#

core::reconstruct(*this, std::move(other))

#

nobody needs to know

frank sail
#

I put mine on full display

distant lodge
#

I wonder if there's some obscure rule about object lifetimes that makes that ackshually UB

frank sail
#

I looked in the spec to make sure it's not UB

wicked notch
distant lodge
#

are you sure? my dad works at spec and he said you will be banned for this code

wicked notch
#

Derived's move ctor is insane and it looks like a use-after-move bleakekw

#

linter complains as well

frank sail
wicked notch
#

typo

frank sail
#

Looks fine to me

wicked notch
#

ye but linter complains because use-after-move

#

even though we all know it's actually fine

frank sail
#

The linter complains about nonstandard move assignment too

#

Because it dumb

wicked notch
#

rip

frank sail
#

Just take the linter thing as advice rather than a serious issue

#

And if you know what you're doing you can safely ignore it

wicked notch
#

does one ever know what one's doing

frank sail
#

C++ lets us try regardless

wispy spear
#

can you not add an override for the linter at that spot?

#

with a oneliner comment thing

wicked notch
#

perchance

wicked notch
#

behold

#
def main():
    includeDirectories = [
        os.path.join(os.environ['VULKAN_SDK'], 'include'),
    ]
    compileDefinitions = [
        'VK_NO_PROTOTYPES'
    ]
    cppStandard = 'c++17'
    cppArgs = []
    for includeDir in includeDirectories:
        cppArgs.append(f'-I{includeDir}')
    for definition in compileDefinitions:
        cppArgs.append(f'-D{definition}')

    cppArgs.append(f'-std={cppStandard}')
    cppArgs.append(f'-x')
    cppArgs.append(f'c++')
    vulkanEnumFile = os.path.join(includeDirectories[0], 'vulkan\\vulkan.h')
    index = Index.create()
    translationUnit = index.parse(
        vulkanEnumFile,
        args=cppArgs,
        options=TranslationUnit.PARSE_INCOMPLETE
    )
    for diagnostic in translationUnit.diagnostics:
        print(diagnostic)

    stack = [translationUnit.cursor]
    while len(stack) > 0:
        current = stack.pop()
        if current.kind == CursorKind.ENUM_DECL:
            print(current.kind, current.location)
        for child in current.get_children():
            stack.append(child)

    return
#

worst python code ever written by humans

#

AI had no hand in the creation of this abomination

#

this has been painfully handcrafted by yours truly

pale horizon
#

It’s fine. What years of bikeshed to a man KEKW

wicked notch
#

I now have a list of all vulkan enums

#

this is so good

pale horizon
#

Now write a tool that does vk validation in compile time KEKW

wicked notch
#
duplicateKeys = []
for (k, v) in enums.items():
    if HasVendorSuffix(k):
        removedVendor = RemoveVendorSuffix(k)
        if removedVendor in enums:
            duplicateKeys.append(k)
``` mmm efficient python code
wispy spear
#

what are you building exactly? : )

wicked notch
#

thing to convert vk enums to retina enums

#

I got tired of writing them by hand

wispy spear
#

ah

wicked notch
#

python is almost not cancerous to write with type annotations btw

#

who knew that types were useful

wispy spear
#

the only real gripe i have with it is tab and the stupid indentation

wicked notch
#

if only

wispy spear
#

and 100 ways of doing 1 thing

pale horizon
wicked notch
#

no :gigachad:

pale horizon
#

Append and loops in Python are forbidden frog_whip

wispy spear
#

its weird why they call it like that

#

rather than just map reduce blabla

#

like any other lang....... wait.... c++ also calls it different, c# too 😄

wicked notch
#

alright the conversions have been executed

wispy spear
#

now rename vulkan_core.hpp to retina_core.hpp

wicked notch
#
def as_retina_enum_values(name: str, values: {str: int}) -> {str: int}:
    output: {str: int} = {}
    common = find_common_enum_string(name)

    for (entity, value) in values.items():
        entity = entity.replace('VK_', 'E_', 1)
        entity = entity.replace('_BIT', '', 1)
        entity = entity.replace(f'_{common}', '', 1)
        entity = remove_vendor_suffix(entity)
        if entity.endswith('MAX_ENUM'):
            continue
        output[entity] = value
    return output``` peak python code
wispy spear
#

readable

wicked notch
#

I could make it more readable

#

there it is

#

now I only have to figure out mako templates and the codegen is officially complete

#

it only took a few hours

#

@pale horizon mistrusted me

#

smh

pale horizon
#

It’s only the beginning… you think you’re almost done(tm)

wicked notch
#

the good news is that I don't have to write any more python

#

thank god

wicked notch
#

lads

#

it's done

#

269KiB of pure enum goodness

wicked notch
#

aight now I have all the enums it's possible to wish for

#

time to continue the engine™️

wicked notch
#

9000 untested lines of code of allah froge_love

wispy spear
#

you little nutjob

#

Regtina better be a baller engine then

wicked notch
#

it is currently all infrastructure kekkedsadge

#

I don't even have a triangle yet

wicked notch
#

it'll be baller though

#

I can promise that

#

actually you know what

wispy spear
#

noice

wicked notch
#

code review time

wicked notch
#

@frank sail are you in as well

#

for the code review

#

I want the two professional™️ engineers of the server to see this

#

(because everyone else is a fake engineer frfr)

frank sail
#

I'll look later

#

!remindme 169.420 minutes review da code

vivid boughBOT
#

Alright gpgpu, I'll remind you about review da code in 2 hours, 49 minutes and 25 seconds. ID: 66379570

delicate rain
#

I guess I can spare a minute

wicked notch
#

small caveat, you may or may not have to update your Vulkan SDK

#

enums were generated from 1.3.275

glass sphinx
#

inserting barriers non batched like this will have performance penalties on at least nvidia

wicked notch
#

interesting

#

something to solve when I make the rendergraph

glass sphinx
#

they arent auto merged

wicked notch
#

ye right now I can't merge them, unless I do it manually I guess

#

rendergraph is probably next on the list

glass sphinx
#

good luck

#

daxa has a cursed auto merge in command recorders

wicked notch
#

man smooth resize is stupid easy lol

#

why did nobody coerce me into doing it

wicked notch
#

(there were bugs, of course there were)

#

@frank sail I await your code review

wispy spear
#

its readable

#

i like that

#

i also like that not everything is public and static like in any other engine

#

CommandBuffer's interface is dangerous : )

#

the uninitiated could just call .End().Begin()

#

which you might block with some asserts inside, hehe you dont

#

im not a fan of the screaming constants E_ISMS but ill let it slide, this time

wicked notch
wispy spear
#

to solve this puzzle, temporal coupling could solve it, but might explode the class count

wicked notch
#

I've been lazy because it maps to vulkan 1:1, so validation layers will automagically catch stuff like that (End() before Begin())

wispy spear
#

fair

wispy spear
#

you would not be able to call on .CommandBuffer at all, but .Begin() would return a new object, which allows all the things you usually record in order when recording a record

#

and only then you can call .End() on it

#

which returns CommandBuffer& again

wicked notch
#

ah I see

#

smart

wispy spear
#

recording commands probably follows the same patterns for various things

#

with that in mind one could cook up a few of those "temporal couplings" probably

#

anywho was just saying

wicked notch
#

ye it's definitely something I will use when rendergraph times come about

#

because command buffers in that thing will be more clamplicated

wispy spear
#

heh i can imagine

#

the class prefix C is also weird

#

but its tolerable

#

because all the other stuff is so neat and readable 😄

wicked notch
#

ye I hate it

#

But I decided to stick with it because it made everything else nicer

wispy spear
#

you could name all your classes and things RtXXX or RetXXX or even RetinaXXX

#

ah, oki

wicked notch
#

I'm still thinking about that

wispy spear
#

including enums and schtructs

wicked notch
#

It doesn't feel "right" because you're already in a namespace

#

but who knows

wispy spear
#

yeah

#

i know what you mean

#

im in the same dilemma rn 🙂

frank sail
frank sail
#

so far it looks clean though

frank sail
#

also I'm not sure how useful it is to have these things that return a vector of objects

wicked notch
frank sail
#

your code is very clean btw

wicked notch
frank sail
#

sometimes I feel like like a princess when I sprinkle auto, const, noexcept, and [[nodiscard]] around my code, but then I see your code and it looks like a c++ genie visited

wispy spear
#

there is one more thing which i dont like that much

#

MakeXXX instead of CreateXXX

#

Create shows intent better than make

#

i blame std::make_xxx<T>

frank sail
#

std::make_lifetime_at

wispy spear
#

😛

#

c++ people dont know how to name shit properly imho

#

but its also a hard problem

#

id also get rid of the Entry folder and have everything in Regtina's root

wispy spear
#

i should hand in "N6969: Name your shit properly ffs"

#

or was it P

glass sphinx
#

i will steal the way you do features

#

long overdue refactor in daxa

wispy spear
#

lustri is the Dr. Frankenstein of gp

wheat haven
#

ah good another engine to steal inspire my own design choices

wheat haven
#

What is the benefit of postfix return types anyway?

delicate rain
#

All your functions are nicely padded

pale horizon
#

When will this thread be renamed? KEKW

frank sail
#

we "beyond" now

wicked notch
delicate rain
#

Everyone hyped for Retina while I'm out here waiting for the "optic nerve" (version 3.0)

pale horizon
#

LVSTRI gets Neuralink and starts hacking it KEKW

#

Finally, ray tracing IN YOUR BRAIN mindblown

frank sail
#

ray tracing at 3am (gone sexual)

wispy spear
#

need a postfix ctor and dtor too

#

auto Foo -> ()

#

auto Foo -> ~()

#

😄

frank sail
#

did you know that you can put [[nodiscard]] on constructors

wicked notch
#

how do I stop clangd from complaining about hidden non virtual functions ffs

delicate rain
#

You can add comment decorations to turn off warnings

wheat haven
#

hidden non-virtual functions?

wicked notch
#

ye, when you do

struct Base {
  int Get();
};

struct Derived : Base {
  int Get();
};```
wheat haven
#

ah, that does feel a bit weird

pale horizon
#

You should put override here though KEKW

wheat haven
#

is that allowed on a non-virtual?

pale horizon
#

No misinfo

#

clangd is being goofy ah then

wicked notch
#

I don't need dynamic dispatch, I'm 100% sure I'll always know the type statically

wheat haven
#

I would just name them differently then

pale horizon
#

Just don't inherit from stuff. Ever smart

wicked notch
#

ye perhaps that's a solution

#
RetinaDeclarePushConstant() {
  uint u_ViewBufferIndex;
};

RetinaDeclareBuffer(restrict readonly, SViewInfoBuffer) {
  mat4 Projection;
  mat4 View;
  mat4 ProjView;
};
RetinaDeclareBufferPointer(SViewInfoBuffer, g_ViewInfoBuffer, u_ViewBufferIndex);``` this feels so good to use
#

With this the base Retina is ported over

#

raytracing is sadly missing but I didn't like the original API anyways

wheat haven
#

what do you do if the buffer has no qualifiers?

wicked notch
#

you just omit the first parameter

wheat haven
#

I thought macros didn't resolve like that, huh

wicked notch
#

I didn't test this but iirc they to

#

lemme try

#

ok yeah you're right

#

shit

#

fucking glsl piece of trash

wheat haven
#

it's a C thing too 😄

wicked notch
#

yeah

#

but I'll still take it out on glsl

distant lodge
#

I think you only had good variadic macros in C++ 17 or 20

#

that can automatically tolerate 0 args to the variadic

wheat haven
#

RetinaDeclareBufferEx

#

or keep with vulkan style and go RetinaDeclareBuffer2 😄

wicked notch
#

one could do RetinaDeclareQualifiedBuffer(, SViewInfoBuffer)

#

but it's garbage

wispy spear
wicked notch
#

why :(

wheat haven
wispy spear
#

because you hide Base::Get

wicked notch
#

that's intended tho

#

I don't want you to call Base::Get

wispy spear
#

then inheritance isnt the right tool for the job here

wicked notch
#

how would you do Buffer and TypedBuffer<T> then

wispy spear
#

same way jaker and i did itin the past

wicked notch
#
class Buffer {
  GetSize(); // size in bytes
}

class TypedBuffer<T> {
  GetSize(); // element count
}```
wicked notch
wispy spear
#

have GetElementCount

#

and GetSize returns the size in bytes in both classes

wicked notch
#

ok that's fair

#

but I still need buffer and typedbuffer to be related

#

that's a hard requirement

wispy spear
#

thats ok

#

or crtp it as devsh suggested

wheat haven
#

also random question, what exactly is ArcPtr? it seems to be a smart pointer of some kind, but it's...odd to me. Reset will delete the underlying pointer which implies the class owns the pointer, but the class is copyable so it's not unique either

wheat haven
#

ahh, I missed the Grab and Drop calls; I thought you'd have a requirement on the template

wicked notch
#

ye perhaps I should add that requirement

wheat haven
#

where'd the name come from? 'cause I have the same thing but I just called it IntrusivePtr (which is more of a mouthful)

wicked notch
#

Rust

#

but rust's Arc is actually not intrusive

#

so it's a bit of a misnomer

wheat haven
#

I might end up renaming mine to just Ref or something

distant lodge
#

I renamed my IntrusivePtr to RefPtr some time ago after a heavy dose of apple webkit code

frank sail
distant lodge
#

AmpersandOf<T>

frank sail
#

berfect

wispy spear
#

KaufmannsUnd<T>

wicked notch
#

I forgor to check whether my thing builds on the penguin

wispy spear
#

i can try

wicked notch
#

I can also probably integrate CI as well because I don't clone shaderc anymore kekkedsadge

wispy spear
#

i am on a penguin laptop atm

frank sail
wispy spear
#

btw thank you for not using vcpkg

#

ah build fails

wicked notch
#

sadness

wispy spear
#

xD

#
[build] /home/deccer/Code/External/Retina/include/Retina/Core/STL/ArcPtr.hpp:143:18: internal compiler error: in build_comparison_op, at cp/method.cc:1461
#

gcc 13.2.1

wicked notch
#

what in tarnation

wispy spear
wicked notch
#

actually incredible

wispy spear
#

and with clang it stops at including windows.h 😛

#
[build] /home/deccer/Code/External/Retina/src/Retina/WSI/Window.cpp:5:10: fatal error: 'Windows.h' file not found
[build]     5 | #include <Windows.h>
[build]       |          ^~~~~~~~~~~
[build] 1 error generated.
wicked notch
#

oh shit I forgor to remove it yesterday night KEKW

#

does it work without windows.h

frank sail
#

it makes sense that window.cpp would depend on windows.h

wicked notch
#

time to submit the Nth compiler bug

#

C++ is pain

wispy spear
#

you could always switch to c#

#

and leave c++ in the sewers where it belongs

wicked notch
wicked notch
#

figured it out yet?

#

I forgor to delete the copy constructor

#

clang decided to tell me in the most unhinged way possible

delicate rain
#

I tried to read the message on my phone, first I got a pop up to download it, then to read it in Google docs then another pop up that I first need to upload it to Google drive after which a popup of "give me permission to view your files" followed

#

After which I gave up

wicked notch
#

Bruh

delicate rain
wispy spear
#

@wicked notch we need to link with tbb as well

#

on lunix

wicked notch
#

huh wat

#

I don't remember using any parallel algorithms ever

wispy spear
#
[build] /usr/include/oneapi/tbb/detail/_task.h:169:(.text+0x3d9): undefined reference to `tbb::detail::r1::execution_slot(tbb::detail::d1::execution_data const*)'
[build] /usr/bin/ld: /tmp/cco0F0AY.lto.o: in function `tbb::detail::d1::current_thread_index()':
[build] /usr/include/oneapi/tbb/task_arena.h:451:(.text+0x3ed): undefined reference to `tbb::detail::r1::execution_slot(tbb::detail::d1::execution_data const*)'
wicked notch
#

does this tell you where the reference was named?

wispy spear
#

gcc complains only

#

clang has no problem and builds

wicked notch
wispy spear
#

thats weird, i can only find tbbisms in tracy but it also seems to be disabled there

wicked notch
#

it's probably cause of LTO innit

wispy spear
#

i wouldnt know, i only know what lto is spelled out

#

but not how it conducts its bisnes

#

i did the classic delete build, lets see if that fixes it : )

#

ah, itnt

wicked notch
#

ye it's definitely because of tracy

#

well that's my fault

wispy spear
#

NO_TBB = 1

#

i read that as "dont touch or use tbb"

wicked notch
#

you can pull now

#

I fix

hallow cedar
wicked notch
#

I do not

#

it's tracy's fault, though idk why it links fine with clang but not with gcc

wispy spear
#

nope

wicked notch
#

rip

wispy spear
#

did rm build/ and reconfictured

#

idk mayhaps pull tbb (if it has sources available soewhere) if gcc

#

build and link with it for the time being

#

or require lunix people to instal libtbb and you just link with it if gcc

pale horizon
#
~/work/edbr/build$ ldd src/game 
    linux-vdso.so.1 (0x00007ffe2bfd9000)
    libglm.so => /home/eliasdaler/work/edbr/build/third_party/glm/glm/libglm.so (0x00007f1b3db17000)
    libfreetyped.so.6 => /home/eliasdaler/work/edbr/build/third_party/freetype/libfreetyped.so.6 (0x00007f1b3da1c000)
    libSDL2-2.0d.so.0 => /home/eliasdaler/work/edbr/build/third_party/SDL/libSDL2-2.0d.so.0 (0x00007f1b3d600000)
    libTracyClient.so.0.10.0 => /home/eliasdaler/work/edbr/build/third_party/tracy/libTracyClient.so.0.10.0 (0x00007f1b3d200000)
    libvulkan.so.1 => /home/eliasdaler/work/vulkan_sdk/1.3.275.0/x86_64/lib/libvulkan.so.1 (0x00007f1b3d9a2000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1b3ce00000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b3d521000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1b3d951000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b3cc1e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1b3dbd1000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1b3d94a000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1b3d945000)
~/work/edbr/build$ ldd /home/eliasdaler/work/edbr/build/third_party/tracy/libTracyClient.so.0.10.0
    linux-vdso.so.1 (0x00007ffe0fef8000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1abf400000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1abf721000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1abfa45000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1abf21e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1abfa98000)
wicked notch
#

ye it be weird

#

does it compile for you?

pale horizon
#
fatal: reference is not a tree: 923e865b7da81bfcab5c54f260c0f034953d406e
CMake Error at spirv-tools-subbuild/spirv-tools-populate-prefix/tmp/spirv-tools-populate-gitclone.cmake:49 (message):
  Failed to checkout tag: '923e865b7da81bfcab5c54f260c0f034953d406e'

idk KEKW
Don't want to debug for now

wicked notch
#

incredible

pale horizon
#

FetchContent issue
Git submodule chads win once again

wicked notch
#

I don't even clone spirv tools

wispy spear
#

i think i saw it the conf part too

#

spirv_cross-src is in build/Deps 😄

#

also elias is on some outdated debian 😛

pale horizon
#

I’m on testing! KEKW

wheat haven
pale horizon
#

Okay, it builds, I had some merge conflict KEKW

#

Did git pull again:

CMake Error at Dependencies/CMakeLists.txt:174 (target_sources):
  Cannot find source file:

    /home/eliasdaler/work/repos_to_check/Retina/Dependencies/cgltf/Implementation.c


CMake Error at Dependencies/CMakeLists.txt:173 (add_library):
  No SOURCES given to target: cgltf

FetchContent is a meme

#

(Yes, I removed build dir and created it again)

#

Dependencies/CGLF
bro...

wheat haven
#

common windows L

#

case sensitivity

pale horizon
#

More like case insensitivity here

#
diff --git a/Dependencies/CMakeLists.txt b/Dependencies/CMakeLists.txt
index 4ee1997..ec72b9c 100644
--- a/Dependencies/CMakeLists.txt
+++ b/Dependencies/CMakeLists.txt
@@ -172,7 +172,7 @@ if (NOT cgltf_POPULATED)
   FetchContent_Populate(cgltf)
   add_library(cgltf STATIC)
   target_sources(cgltf PRIVATE
-    ${CMAKE_CURRENT_SOURCE_DIR}/cgltf/Implementation.c
+    ${CMAKE_CURRENT_SOURCE_DIR}/CGLTF/Implementation.c
   )
   target_include_directories(cgltf PUBLIC
     ${cgltf_SOURCE_DIR}

xoxo

wheat haven
pale horizon
#

Also what do I launch now KEKW

wicked notch
#

are you on latest

pale horizon
#

Yes

wicked notch
#

Retina.Entry

pale horizon
#

Beautiful, 11/10 raytracing

#
~/work/repos_to_check/Retina/build$ ldd ./src/Retina/Entry/Retina.Entry
    linux-vdso.so.1 (0x00007ffce9340000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcd50600000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcd50521000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcd5088c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd5033f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcd508df000)

hmm, no Tracy and no TBB

frank sail
wheat haven
#

also they're all static so they wouldn't be in ldd anyway

pale horizon
#

Build shared libs is ON by default I think. Unless LVSTRI overrides it

wheat haven
#

true, but all of the parts Retina.Core, Retina.Graphics, etc are set as static, which...I think forces all of their dependencies to be baked in too?

pale horizon
#

Ah, I see

wicked notch
#

we're back

#

now, time to make that VSM sample I promised to jaker

#

and then rendergraph

frank sail
#

VSM shrimple