Example shaders?

[Trainmaster9977]

I was too invested in my own research to remember for a bit, but I recently realized again that well-

Given how this is used for ssbh_wgpu, and the material research website, both of which have their own variable names to my knowledge, there is a likely chance that there are some specific shaders that you have translated at least parts of, with variable names, and everything.

Given renderdoc and your own possible rewriting, it's not 100%, but I want to ask ya anyways- If you've translated any specific shaders by hand, to use as reference/example, which ones were they? And may I see them?

Obviously both ssbh_wgpu and the website have snippets, but unless parts correspond to a specific file, there's only so far things can go.

(And for the record, I'm referring to the things that the annotated shaders annotate. Referring to things like labeling specific temp values SSS_Blend or finalDiffuseShading, as well as fp_cNs that the annotated shaders don't cover.)

Thanks!

[ScanMountGoat]

There aren't really "correct" labels for variables, which is why I don't provide them. It's also not really feasible to annotate all the shaders manually like this. All the hand translated code should have an associated comment in model.wgsl in ssbh_wgpu. The shaders are just math, so variable names don't help as much as you might think. Most of the work in analyzing shaders is finding the lines related to a value that you care about. There should be a script that I used for doing this for Yuzu's shaders. I can't guarantee that it's correct or still works.

[Trainmaster9977]

Oh yeah obviously, I'm not asking you to manually do so for every file or something. I'm just asking if you have like, ones that you've already done for reference. Like. When I asked the question, what I'm hoping for is for you to have 1-3 you've done in the past for research.

Also personally seeing just the math is a bit overwhelming, and I spend a lot of time annotating the things that I know.

I can of course do the annotating myself, and I am actually in the process of doing so, but if some of the work has already been done, then it's worth it for me to ask about it so I don't spend time trying to figure out something that already has been figured out.

Either way, apologies that my initial question came off wrong.

[ScanMountGoat]

If something has been implemented in ssbh_wgpu, than it has already been at least partially "figured out". It may be helpful from a learning perspective to see if you can identify the code from ssbh_wgpu in the decompiled code. For example, if you find the last parameter for textureLod calls in almost any fragment shader, you should be able to work backwards and find the similar code to ssbh_wgpu. This was taken directly from shader code and then cleaned up a bit. The variable names are largely meaningless and mostly just serve to avoid writing everything on one line and to reuse the results of certain computations.

fn RoughnessToLod(roughness: f32) -> f32
{
    // Adapted from decompiled shader source.
    // Applies a curves adjustment to roughness.
    // Clamp roughness to avoid divide by 0.
    let roughnessClamped = max(roughness, 0.01);
    let a = (roughnessClamped * roughnessClamped);
    return log2((1.0 / a) * 2.0 - 2.0) * -0.4545 + 4.0;
}

Also personally seeing just the math is a bit overwhelming, and I spend a lot of time annotating the things that I know.

Shader code is "just the math". Translating shaders is largely a mechanical task. The process is similar to reverse engineering assembly in ghidra but with less programming concepts and more math. You find an input/output that looks relevant and collect all the assignments by working forwards/backwards through the code. I like to put comment descriptions on the end of each line that I'm annotating with notes about what it does. You could also copy paste into a new document and clean it up there. The format of the code is simple enough, so you could automate most of this like what I tried to do in the python scripts. The next step is to "clean" the code. This is mostly applying basic algebraic operations like substituting variables, simplifying expressions, etc. While it's possible to automate this in theory, writing a program for this that works correctly is hard in practice. You can always copy paste your cleaned up code into renderdoc and hit F5 to make sure nothing obvious changes visually.

The hardest part is figuring out what the code is doing and why. Recognizing patterns comes from experience looking at tutorials, other people's code, research papers, etc. There isn't really a straightforward way of doing this. My advice is just find something that interests you and try and find the code that controls it in game. Once you have a fragment of code that you think does something, then you can try and figure out how it works.

[Trainmaster9977]

Due to wanting to modify the shaders, I don’t actually plan to simplify stuff- no clue whether changing the length will have bad side effects. Either way I think I’ll be able to annotate most of it with renderdoc currently- at least for glsl. We’ll see how dealing with registers in the assembly turns out.

The comment about variables is interesting- for you, it seems to be so you don’t have to rewrite everything over and over again. For me, it’s more that while I can handle tons of variables, I need at least a framework of what is actually what.

But that framework has partially been provided by your current annotations, so thank you for that! In should be able to figure out the majority of it from there, it’ll just take another couple days.

Though the big piece I’m missing is well. The other shader buffers besides fp_9. Any idea what those contain? I imagine it’ll be harder to figure out if all the material stuff that we can easily change is in fp_9 .

As for wgpu, I was kinda approaching it from the opposite end- using annotated code to compare it to an unannotated version in order to learn how it maps. Either way if theres only wgpu, no worries, I’ll make do with what I can annotate myself. It’ll just take a bit longer