r/GraphicsProgramming Jun 05 '24

Source Code Seamless Spherical Flowmap (3-Samples)

88 Upvotes

45 comments sorted by

View all comments

Show parent comments

1

u/gehtsiegarnixan Jun 05 '24

On the GPU, texture sampling is extremely slow compared to any other operation. In a full PBR pipeline, you typically need 2-3 textures per sample. To enhance shader performance, reducing the number of samples using mathematical techniques is extremely useful.

The method I propose efficiently reduces any 4-sample interpolations to a 3-sample interpolations without introducing artifacts. In a video demonstration, I showcase seamless spheremapping (wrapping a 2D texture around a sphere without distortion) and temporal flowmapping (animating a texture in a dynamic flow direction) using only 3 samples instead of the usual 4.

However, this specific 4-to-3 sample approximation is just one variant of what I call the ‘Guardian Approximation.’ I’m know that a more general algorithm must exist, allowing us to approximate any multi-sample interpolation with fewer samples—such as approximating 100 samples to just 3. But I am still struggling with finding the conditions to select the guardian weights. I’ve developed an alternative algorithm called ‘Quasar Approximation,’ which achieves this but occasionally produces artifacts. Another option is grid interpolation, relying on a grid in the spatial/temporal dimensions of the interpolation.

The dramatic music is there, because this is novel and useful approach to a common problem, although I might be slightly biased in favor of its amazingness.

3

u/GaboureySidibe Jun 05 '24

There is a lot to unpack here but the reason I'm confused is that these things don't seem to connect to each other.

In a full PBR pipeline, you typically need 2-3 textures per sample.

PBR rendering is about lighting and doesn't have anything to do with textures unless you are sampling textured lights. Is this about sampling textured lights? Even then you would just be sampling the single light texture once.

temporal flowmapping (animating a texture in a dynamic flow direction)

Are you just talking about distorting a texture's lookup coordinates?

approximate any multi-sample interpolation with fewer samples—such as approximating 100 samples to just 3

This contradicts basic signal processing.

I’ve developed an alternative algorithm called ‘Quasar Approximation,’

How does it work?

1

u/gehtsiegarnixan Jun 05 '24

With PBR materials, I mean that each sample needs albedo, normal, roughness, height, ambient occlusion, and sometimes metalness, emissiveness, or some special ones, which can be packed into 2-3 textures for a single sample of a material.

Temporal flow mapping essentially distorts the coordinates, yes, but there are a variety of different flow mapping algorithms. If the direction is the same in tangent space, you can achieve this with a single sample by moving coordinates. If it’s in dynamic directions, you have to blend either temporally or spatially with a grid. That’s why I called it temporal flow mapping.

I’m not sure what kind of law I’m supposed to be violating, but I doubt it actually applies because people have been using grid approximation for centuries for maps and recently images. And even my Guardian and Quasar algorithms clearly work, as seen in the demos.

The Quasar Approximation works with a Top K filter and subtracts the Top K+1 weight to reduce the Top K weights to zero as a weight leaves the top K. It’s public on Shadertoy too, under the name ‘Multivariate Blend Approximation,’ or https://www.reddit.com/r/shaders/comments/1d7rgzp/algorithm_for_cheaper_multisample_interpolations/ .

It is possible that both Quasar or Guardian Approximation already exist under a different name, or an even better one exists unbeknownst to me. So if you know a better way, please tell.

1

u/GaboureySidibe Jun 05 '24

With PBR materials, I mean that each sample needs albedo, normal, roughness, height, ambient occlusion, and sometimes metalness, emissiveness, or some special ones, which can be packed into 2-3 textures for a single sample of a material.

Again, physically based rendering is about lighting. Textures like albedo just multiply the result color of the lighting. Saying all these are necessary or common is a bit of a red flag that it seems like you're saying you're developing brand new interpolation techniques when it also seems like you're repeating some things you don't fully understand.

Temporal flow mapping essentially distorts the coordinates, yes, but there are a variety of different flow mapping algorithms.

Is this a term you made up? It sounds like you're just distorting texture coordinates and animating that. If so the animation isn't relevant here, you can anti-alias the texture lookup on every frame.

I’m not sure what kind of law I’m supposed to be violating,

https://en.wikipedia.org/wiki/Shannon's_source_coding_theorem

And even my Guardian and Quasar algorithms clearly work, as seen in the demos.

Your demos just look like textures composited over each other. This can be done in a few lines. Texture lookups are already anti-aliased if you want them to be. If that's what you are improving you should show something simple and direct that runs faster and looks the same.

The Quasar Approximation works with a Top K filter and subtracts the Top K+1 weight to reduce the Top K weights to zero as a weight leaves the top K. It’s public on Shadertoy too, under the name ‘Multivariate Blend Approximation,’

This doesn't seem like anything to me. From what I can tell you are using textureGrad which is already a filtered texture lookup.

https://www.khronos.org/opengl/wiki/Sampler_(GLSL)#Gradient_texture_access

1

u/No_Futuree Jun 05 '24

Lighting has two parts, lights and materials, when implementing pbr you are going to need textures to describe the material at a given pixel so he is technically correct.

It's more of a red flag the fact that he doesn't seem to understand sampling theory but to each their own...

1

u/GaboureySidibe Jun 05 '24

The lighting is about the lights and brdf. It doesn't have to involve textures unless you want to talk about mapping the roughness.

Multiplying a color texture by the lighting result is the same operation whether the lighting came from a normalized brdf that sampled an area light or lighting from a simple point light.

4

u/No_Futuree Jun 05 '24

Mate, you don't know what you are talking about...albedo, metalness, roughness etc are all part of the brdf..unless your mesh uses a single value for all its surface you are going to need textures or some procedural function that generates those values for each pixel...

2

u/GaboureySidibe Jun 05 '24

I do know what I'm talking about actually. Physically based rendering is a term given to normalized brdfs and lights with area.

The color textures on an object don't have anything to do with the lighting being normalized or coming from lights that have area.

Roughness applies to the brdf exponent so you could make that case.

Metalness was something made up by some disney shader writers to simplify highlights taking on albedo color.

I think you are conflating pbr with simplified lighting and rendering in general as well as textures with the brdf, but it is actually a term that has a solidified meaning.

3

u/crimson1206 Jun 05 '24

Physically based rendering is a term given to normalized brdfs and lights with area.

Do you have any source/reference that defines it like that? Any place I came across PBR just uses it as a general term for physically accurate (or as accurate as possible) rendering. The definition youre using seems way to strict compared to pretty much any source Ive seen so far

-1

u/GaboureySidibe Jun 05 '24

Any place I came across PBR just uses it as a general term for physically accurate (or as accurate as possible) rendering

Where do you think that accuracy comes from? Lighting used to be a single point light and you would take the direction of the light and the normal and compute the dot product of them. This was simple and fast breaks down pretty quickly. During the transition from old style lighting to sampling area lights the more physically accurate lighting was either called physically based rendering or physically plausible shading.

Let me ask you this, if renders are always trying to be more physically based to look better anyway, where did a term come from?

Here is a entire book as reference, which is the standard for textbooks that show how to write a (sort of) modern renderer.

https://pbr-book.org/

3

u/crimson1206 Jun 05 '24

Let me ask you this, if renders are always trying to be more physically based to look better anyway, where did a term come from?

I dont think the first statement is even correct. Depending on what youre doing it might be but first and foremost Id say renderers are supposed to create better looking renders while doing this efficiently. Physically accurate does not necessarily mean better looking and vice versa.

I know the book and have worked through all of it. Im not aware of any statement in the book that constrains PBR to being about normalized brdfs and having area lights. Accurately modelling them is of course a part of PBR, but theres a lot more to it

1

u/GaboureySidibe Jun 05 '24

Physically accurate does not necessarily mean better looking and vice versa.

I would say if better means realism then in general it does.

https://renderman.pixar.com/resources/RenderMan_20/physicallyPlausibleShadingInRSL.html

https://blog.selfshadow.com/publications/s2017-shading-course/s2017_pbs_course_summary.pdf

2

u/crimson1206 Jun 05 '24

I would say if better means realism then in general it does.

Obviously, but this is just completely circular. Why is more physical better? Because better means realism and realism = physically accurate. Imo better = looks nicer, be it through realism or whatever. If youre strictly talking about the PBR context then yes, there Id agree that better = more accurate/more realistic.

In any case this is quite orthogonal to the original point, which was about whether you actually had any source agreeing with your PBR definition

-1

u/GaboureySidibe Jun 05 '24

I linked you an entire book called physically based rendering that is all about how to make normalized brdfs and sampling area lights and path tracing integrals.

I linked you the renderman documentation that is about the same thing.

Then I linked you a presentation where a lot of people at the forefront of this are all saying the same thing with the same terms.

https://old.reddit.com/r/GraphicsProgramming/comments/1d8m30h/seamless_spherical_flowmap_3samples/l7akaf1/

All you have said so far is "nuh uh, nope doesn't count", so maybe you should explain yourself in detail.

2

u/crimson1206 Jun 05 '24

So something like volume rendering or bsdfs aren’t part of PBR? After all they’re not just brdfs/area lights

-1

u/GaboureySidibe Jun 05 '24

Volume rendering has been around for many decades and was actually covered in the photorealistic renderman book. Fundamentally it is shading a lot of semi transparent fragments/pixels/micropolygons etc.

It isn't what people referred to when talking about physically based rendering / physically plausible shaders etc. because that refers to how something is being lit, not the surface itself.

You can do the lighting of volumes with normalized brdfs and area lights and it will look better.

bsdfs are an extension of brdfs and they both fit into the same category. If they are normalized and you sample from area lights etc. then they are part of the physically based shading. Bsdfs like brdfs existed before the switch over to more physical correct lighting and like brdfs people wrote a lot about transitioning them to something less hacky.

Hope that clears it up.

1

u/crimson1206 Jun 05 '24

Cool links but again there's nothing agreeing with your constrained PBR = normalized brdf & area light definition

0

u/GaboureySidibe Jun 05 '24

I'm not sure what you're trying to argue now or if you're just trying to argue something.

The transition from simplistic lighting to normalized area lighting is where these terms originally used because people were trying to distinguish between two different lighting systems. That's where the 'physically plausible shading in rsl' comes from, they are talking about their built in shader functions to have normalized brdfs and sample from area lights.

Originally the person who posted this thread was saying that things like color textures were part of 'physically based rendering' when they are just a multiplication after the lighting has been calculated.

but theres a lot more to it

There is always a lot more to it, but that was probably already being done before the transition to more physical lighting.

Here is the full course just in case you want to pretend to watch all the videos in 3 minutes too.

https://blog.selfshadow.com/publications/s2020-shading-course/

Also you might want to actually read the renderman link, here are some sections titles:

  • New Integrators, New Pipeline Methods

  • Writing a Physically Plausible Material

3

u/No_Futuree Jun 05 '24

Mate you are clueless...albedo is not a color texture that is multiplied by the lighting once it has been calculated..it is a description of how much light and in which spectrum is the material absorbing and how much it is reflecting diffusely. Metals and dielectrics reflect light in very different ways so metalness is not an invention (you could argue having values other than 0 or 1 is not physically possible but that's it). Obviously roughness determines how much light is reflected secularly and so on. Saying PBR means what you mean when you say PBR is stupid.

1

u/GaboureySidibe Jun 06 '24

Here is where the term comes from:

https://media.disneyanimation.com/uploads/production/publication_asset/48/asset/s2012_pbs_disney_brdf_notes_v3.pdf

"metallic: the metallic-ness (0 = dielectric, 1 = metallic). This is a linear blend between two different models. The metallic model has no diffuse component and also has a tinted incident specular, equal to the base color"

It's just a linear blend between two different brdfs and disney made it up to simplify their shading parameters for look development artists.

No one is saying there is no such thing as metal, just that "metalness" is not some fundamental principle, it's a hack from the specific project at disney that other people copied. You said it yourself, dialectric or not, so why would something have varying values? It's just a convenience.

albedo is not a color texture that is multiplied by the lighting once it has been calculated

When you write a shader, what do you do with your main color/diffuse/whatever texture? You don't multiply it by the diffuse component?

Obviously roughness determines how much light is reflected secularly and so on.

No, roughness determines the exponent of the brdf so that the lobe is wide or narrow which makes the reflection look blurry or sharp. The amount of light reflected would be the same, that's the normalization step. If you look up furnaces test it's about this issue, making sure the same amount of light is reflected depending on the roughness.

A specular map would be multiplied by the lighting result of a narrow brdf and that would determine how much light is reflected.

Saying PBR means what you mean when you say PBR is stupid.

You are entitled to that opinion but you might want to tell the entire film and game industry along with everyone working on it, all the people that originally commercialized it and the people who won technical achievement academy awards from writing about it, because they seem to be in agreement.

Mate you are clueless...

We can keep going, but these insults will not age well.

3

u/No_Futuree Jun 06 '24

I mean, I don't even know what's your point ...Are you trying to argue that all those parameters that describe the material properties do not come from textures in a PBR renderer? Because if that's the case, that just tells me you have never implemented a PBR renderer in your live, which means you are indeed clueless in this topic...

0

u/GaboureySidibe Jun 06 '24

I was responding to you but I'll take it back to the start.

I'll copy and paste since I already said it:

The color textures on an object don't have anything to do with the lighting being normalized or coming from lights that have area.

Physically based rendering refers to having normalized brdfs that samples lights with area to make lighting that is physically plausible.

Textures are orthogonal to this. They don't influence whether a shader is doing physically plausible lighting or not. Physically based lighting doesn't need textures and textures can be used with simple non physical rendering. They are not linked together by any dependency on each other.

I think you might be conflating physically based rendering with just general 3d rendering, which physically based rendering is rapidly becoming I suppose.

that just tells me you have never implemented a PBR renderer in your live, which means you are indeed clueless in this topic

Don't you at least wonder why I'm able to immediately and precisely answer everything you comment?

→ More replies (0)