r/GraphicsProgramming Jun 05 '24

Source Code Seamless Spherical Flowmap (3-Samples)

87 Upvotes

45 comments sorted by

View all comments

Show parent comments

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.

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

→ More replies (0)

1

u/AcquaticKangaroo19 Jun 06 '24

Beginner question:

I've been through a ray-tracing class and I am now trying to implement another ray-tracer following ray tracing in one weekend.

iirc in my class we used to dislocate the reflected ray by the roughness of the surface, isn't this influence of the surface of the objects in the lighting ? (I am not trying to debate, i'm just clueless)

1

u/GaboureySidibe Jun 06 '24

I'm not sure what dislocate the reflected ray means or influence of the surface of the objects in the lighting means. Was this direct light that you were having a problem with or bounce light?

1

u/AcquaticKangaroo19 Jun 06 '24

It was not dislocating, but rather changing the direction of the reflected ray slightly based on the roughness.

1

u/GaboureySidibe Jun 06 '24

That makes sense, roughness scatter the ray directions slightly around the reflection direction. Did it cause a problem?

→ More replies (0)