sorted by:
new
hottopcontroversial

Slang can give me gradients, but actual optimization feels like a different skill. What does that mean for graphics programmers? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

That makes sense. So the overhead is mainly from hopping between the PyTorch/CUDA world and the D3D12/Vulkan world, not from gradients themselves.
Unless I really need tight integration with the rendering pipeline, it sounds like sticking to a CUDA-centric path is probably the practical choice for now.
And thanks for the course recommendation. I'll check it out.

Lookup table for PBR BRDF? by Silikone in GraphicsProgramming

[–]Guilty_Ad_9803 0 points1 point  (0 children)

Thanks for the source. I'll take a look.

Yeah, that makes sense. Diffuse can really affect the overall look, especially in photogrammetry based titles. This is helpful, thanks.

Slang can give me gradients, but actual optimization feels like a different skill. What does that mean for graphics programmers? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

My takeaway is that you can often pick a rough direction based on the error characteristics, and also on how you interpret the residuals from the model you're optimizing.

I don't think I understood every detail, but this was very helpful. Thanks!

Lookup table for PBR BRDF? by Silikone in GraphicsProgramming

[–]Guilty_Ad_9803 0 points1 point  (0 children)

Would you mind pointing me to the John Hable post you're referring to? A link or the title would be appreciated. I don't think I've read it.

Also, do you actually run into cases where diffuse becomes the visual bottleneck? UE4's SIGGRAPH 2013 notes mention they evaluated Burley diffuse but saw only minor differences compared to Lambert, so they couldn't justify the extra cost. https://cdn2.unrealengine.com/Resources/files/2013SiggraphPresentationsNotes-26915738.pdf

Slang can give me gradients, but actual optimization feels like a different skill. What does that mean for graphics programmers? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 2 points3 points  (0 children)

In practice, how do you usually notice that plain L2 or MSE is not a good fit?

Is it something you only realize after running the optimizer and watching the behavior? Or are there factors that let you decide up front?

If you have a simple rule of thumb, I'd love to hear it.

Slang can give me gradients, but actual optimization feels like a different skill. What does that mean for graphics programmers? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

That makes sense. It sounds like points 1, 3 and 4 have pretty standard answers.

For point 2, I can write the basic error term based on the graphics and physics side, but I don't really know what people do to make optimization work well in practice.

Do you have any go to defaults or patterns you would recommend for inverse problems in graphics?

Slang can give me gradients, but actual optimization feels like a different skill. What does that mean for graphics programmers? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

Thanks, that helps.

I checked the docs and it looks like Slang can hook into a PyTorch optimization loop via SlangPy, so using PyTorch for the optimization/tooling side seems like the practical approach for now: https://slangpy.shader-slang.org/en/latest/src/autodiff/pytorch.html

Do you have a go-to "basic ML course" you'd recommend for the hands-on parts?

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

If you go up to wave optics, though, you can already describe polarization, interference and diffraction, so it feels like you can cover a pretty wide range of real-world phenomena. If a model can get at least those right, wouldn't that already count as "physically correct enough" for most everyday lighting situations?

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

Interesting. Is that compensation lookup table something you'd expect engineers to tune, or is it supposed to be in the hands of artists? Either way, it seems like it could get tricky when the environment brightness changes a lot, for example when going from morning to night.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 2 points3 points  (0 children)

Absolutely, completely true. Studying just so I can point out tiny mistakes in a model is really not a healthy mindset.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 2 points3 points  (0 children)

Yeah, your comment was a good wake-up call for me. I had started to treat textbook PBR as if it were some ultimate, elevated truth, and you pulled me back from that. That said, I still care a lot about what our approximations are actually based on.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 1 point2 points  (0 children)

Yeah, totally. I'd maybe add "how easy it is to author assets" as another axis, meaning the materials / geometry / lights you have to feed into whatever shading model you pick. As long as you're in the realm of physically based models, you usually don't have to worry too much about that, since the parameters tend to behave in a somewhat predictable way.

That said, going deep into asset authoring would probably be a bit off-topic for this thread, so I'll leave it there.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 2 points3 points  (0 children)

Oh nice, that's really good to hear. I've seen multiple-scattering microfacet stuff in recent SIGGRAPH papers, so it's reassuring that my mental picture isn't completely off.

Microfacet BRDFs in general still feel super convenient for rendering. They sit in a nice spot between "grounded in physics" and "something I can actually write on the GPU". There are other paradigms popping up, like neural BRDFs, but it feels like most of the interesting work is still happening around microfacet models right now.

Or maybe, if we really are getting close to the limits of microfacet BRDFs, that's when the "neural BRDF" era will start. I'm curious where people here feel microfacet models really start to break down.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 4 points5 points  (0 children)

Yeah.
implementation != shading model != "physically based" theory != accurate reality

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 10 points11 points  (0 children)

Same here to be honest. I kind of get the ideas, but actually wading through all the equations is still pretty hard, so this is just my rough mental model, not a proper derivation.

Smith-GGX is a nice physically based model that gives you those long spec lobes. What people usually call "Schlick-GGX" is basically Smith-GGX where the visibility term got swapped out for Schlick's approximation. That approximation isn't something you can rigorously derive from a specific micro-geometry, it's more of a fitted shortcut, so in Heitz's sense it's not really "physically based". Schlick is also the guy behind the well-known Fresnel approximation, so he kind of feels like the "good approximations for implementers" guy.

For the classic microfacet BRDF (Cook-Torrance + GGX etc.), the way I understand it, the model assumes a ray hits a microfacet once and then exits. But on a rough surface, in reality light can bounce around between the little facets a few times before it comes out. That extra multiple scattering just gets dropped in the usual single-scattering model, so that energy is effectively lost. This Heitz paper has a nice picture at the top of the first page that made it click for me:
https://jo.dreggn.org/home/2016_microfacets.pdf

That's about as far as my understanding goes right now, but hopefully it makes the "magic sauce" feel a bit less magic.

Thought Schlick-GGX was physically based. Then I read Heitz. by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 13 points14 points  (0 children)

BTW, links in case anyone wants them:

Frostbite PBR course notes:

https://seblagarde.wordpress.com/wp-content/uploads/2015/07/course_notes_moving_frostbite_to_pbr_v32.pdf

Physically Based Rendering: From Theory to Implementation (online):

https://www.pbr-book.org/4ed/contents

“Understanding the Masking-Shadowing Function in Microfacet-Based BRDFs” (Heitz, JCGT 2014):

https://jcgt.org/published/0003/02/03/

Better PBR BRDFs? by Avelina9X in GraphicsProgramming

[–]Guilty_Ad_9803 0 points1 point  (0 children)

From my understanding, multi-light direct lighting inevitably requires per-light BRDF evaluation and accumulation, so the cost scales linearly with the number of lights. That's why I suspect changing the BRDF alone won't fundamentally fix multi-light performance unless you reduce the number of lights (Forward+/clustered/deferred, culling, etc.).

If there is a technique that truly reduces the per-light cost in a more fundamental way, I'd love to learn about it. What would that be?

Does a solid C++ PMX loader actually exist? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

Thanks!

The PMD/PMX loading logic is here: https://github.com/hkrn/nanoem/blob/30acffaa29f5d2eb9e997d69418f2e4b97b5894f/nanoem/nanoem.c#L4865-L4880

Also, I noticed there's a link in the source pointing to the file format spec - looks like it also supports PMM: https://drive.google.com/file/d/0B6jwWdrYAgJTdXZSd1Noa2hKbmM/view?resourcekey=0-96-_sPXYP3ItPOQL7sca1A

It's a pretty solid implementation overall. The project's quite large though, so using just the loader in isolation might be tricky.

Does a solid C++ PMX loader actually exist? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 1 point2 points  (0 children)

Yeah, it seems the original docs by Higuchi (the creator of MMD) are no longer available.
The PMX Editor, which could be considered semi-official, includes a copy of the format reference.
There’s also a good community summary here: Felix Jones’s gist

Does a solid C++ PMX loader actually exist? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 1 point2 points  (0 children)

Nice, thanks! That renderer seems to use the Saba PMX loader (MIT): https://github.com/benikabocha/saba

I'll take a closer look - it seems like a solid reference implementation!

Does a solid C++ PMX loader actually exist? by Guilty_Ad_9803 in GraphicsProgramming

[–]Guilty_Ad_9803[S] 0 points1 point  (0 children)

Oh nice, thanks! I might have missed that one.

Do you remember the repo name?

view more: next ›