All Questions


Daniel Queiroz Porto
posted to: 2D Reflections

Confusing Diagrams

I don't know if it's just me, but I found the offset diagrams confusing. It took me a long time and a lot of drawing in a paper to actually understand what was going on with:

vec2 uv_reflected = vec2(SCREEN_UV.x, SCREEN_UV.y + uv_size_ratio_v * UV.y * 2.0);

I think there were some things that weren't clear in the explanations:

  1. Using different names for the variables in the code and the terms in the diagram was not helpful
  2. I think the term offset_v is misleading. We are not getting an offset, and the vertical distance from the point to the texture origin is already UV.y, what we are doing is converting that distance from "texture units" to "screen units", so there is no offset there, it's just kind of a "measurement conversion"
  3. We need to convert to "screen units" because we are going to sample the SCREEN_TEXTURE, so that all our distances need to be in the same kind of unit.
  4. If anything actually works as an offset it's SCREEN_UV.y, specially with a texture that is not going down to the bottom borders of the screen or...
  5. ...If we are in the editor. It took me some experimenting to understand that in the editor the SCREEN_UV is not relative to my screen preview area, it's actually relative to whatever is visible in the editor.

So I tried to draw a diagram that tries to make this more clear. It's a poorly edited version of yours and I don't know if it makes it more clear in general or just makes it more clear to me, but here it is:

  • Nathan Lovato replied

    Thanks for the feedback. I'll write this down.

    It's not just a unit conversion. We're always trying to get what's above the rectangle. A simple conversion from UV to screen would sample the entire screen texture from the bottom to the top. While we are mapping the rectangle on the screen, flipping it vertically, and offsetting it vertically.

    But I get the idea and the source of confusion. The diagram was just here to say we flip and offset the UV coordinates in the visual sense. It was not meant to represent code.

    It's on my todo for the next patch.

  • Daniel Queiroz Porto replied

    Thanks Nathan!

    What I meant about unit conversion was more that if I understood correctly texture_uv.y represents a certain amount of pixels in the screen and to be able to sample that same amount above the screen we need to get this same amount of pixels in screen_uv "units" (maybe I'm using the word units incorrectly).

    But in the end, UV.y and UV.y * uv_size_ratio_v represents the exact same amount of pixels but in different "units"? Is that way of thinking correct?

  • Nathan Lovato replied

    You can think of it like that if that helps you. When working with UVs, you're not working with pixels. They're normalized coordinates to map a point on your surface (it can be any 3D surface) to a texel (texture pixel) on your texture image. Even in 2D, when you scale or rotate your objects, you deform them, or you zoom the view, the same value in UVs corresponds to pixels in different places on the screen.

    What we are doing precisely in that UV calculation is:

    1. Mapping our UV coordinates to a corresponding portion of the SCREEN_UV.
    2. Flipping it and offsetting it up, both at the same time.

    And using these coordinates to map the sampled fragments to the reflection plane.

    It's a confusing topic at first to be honest. It's not that easy to explain either.

  • Daniel Queiroz Porto replied

    Thanks for the more in depth answer!

    It really is a confusing topic, and I understand how hard it must be to explain it. But I think I have a better grasp of it now, and will try to focus on thinking about it not as a conversion of "units" but a conversion of coordinate systems.

    I guess it would be more correct to say UV.y and UV.y * uv_size_ratio_v represents the exact same amount of "space" but in different coordinate systems.

    Anyway, thanks again for your patience and explanations! GDQuest is awesome, and I'm owe a lot to you and your team!

  • t
    duong tuan replied

    Thank Daniel Queiroz Porto.

    Your drawing helped me to understand the problem.