# Use of .read in fragment function for MTLTexture

**URL:** <https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807>\
**Category:** Metal by Tutorials\
**Created:** [May 30, 2023, 4:45pm UTC](https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807 "2023-05-30T16:45:51Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![stewy](https://s3.amazonaws.com/cdn.raywenderlich.com/community/forum-assets/noun-game-ghost-878668.png) [@stewy](https://forums.kodeco.com/u/stewy)\
**Post date:** [May 30, 2023, 4:45pm UTC](https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807/1 "2023-05-30T16:45:51Z")

</div>

You didn’t explain using .read in the fragment function to render the textures on the quad. Specifically, in.position is float4, so why is in.position.xy cast as uint2, apparently to read the texture pixels?

uint2 coord = uint2(in.position.xy);  
float4 albedo = albedoTexture.read(coord);

---

<div class="post-metadata">

**Author:** ![caroline](https://assets.chunter.kodeco.com/user_avatar/forums.kodeco.com/caroline/32/111867_2.png) [@caroline](https://forums.kodeco.com/u/caroline)\
**Post date:** [May 30, 2023, 11:36pm UTC](https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807/2 "2023-05-30T23:36:35Z")

</div>

Hi @stewy and welcome to the forums 😃

I assume you mean in Chapter 14? I don’t quite understand the question, but I’ll attempt to explain.

The G-Buffer render pass renders all the objects to textures that are the same size as the Metal view you’re rendering into:

 ![Screenshot 2023-05-31 at 9.18.39 am](https://files.chunter.kodeco.com/original/3X/0/0/009014b0b046889cc1d1b7b9f6929aa0e1471ed4.png)

`albedoTexture` is the resulting color texture. You’ll need to use object colors, but also the normals and position to work out shading.

After creating the G-buffer textures in `GBufferRenderPass`, you pass them on to `LightingRenderPass` where you set the fragment textures on the render encoder in `draw(commandBuffer:scene:uniforms:params:)`.

The GPU now has albedo/normal/position textures that are all the same size as the render view. You then draw a full screen quad in order that every fragment in the render view gets processed.

Each fragment has a position passed in. The rasteriser has converted `out.position` from the vertex function to screen space for the fragment input (See _Chapter 7: The Fragment Function - Screen Space_).

This is debug code from the Metal debugger showing the value of the fragment at the marked position.

 ![Screenshot 2023-05-31 at 9.33.55 am](https://files.chunter.kodeco.com/original/3X/6/3/63de68137dc885bcc93a26ff149d5eb122d4eb98.png)

 ![Screenshot 2023-05-31 at 9.31.40 am](https://files.chunter.kodeco.com/original/3X/c/e/ce29ebe4c1e68b6f63efe5560e149588fc4aa588.jpeg)

You used `.read` in _Chapter 12: Render Passes_ to read the render texture at touch coordinates.

> Notice that `read` differs from `sample`. `read` uses pixel coordinates rather than normalized coordinates.

`in.position` is a `float4` in screen space and you’re going to read a pixel from a texture the same size as the screen, so only the `x` and `y` are useful here, as `read` uses a `uint2` to read textures.

---

<div class="post-metadata">

**Author:** ![stewy](https://s3.amazonaws.com/cdn.raywenderlich.com/community/forum-assets/noun-game-ghost-878668.png) [@stewy](https://forums.kodeco.com/u/stewy)\
**Post date:** [June 1, 2023, 9:57pm UTC](https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807/3 "2023-06-01T21:57:18Z")

</div>

Seems odd to transform the first two components of a float4 (x and y) from clip to screen coordinates, and it doesn’t seem to be explained in the MSLS. Anyway, it is not transforming those components correctly. The scaling seems to be off by a factor of two and the image is shifted by (width, height)/2. So I get a quarter image of an expanded area in the corner.

---

<div class="post-metadata">

**Author:** ![caroline](https://assets.chunter.kodeco.com/user_avatar/forums.kodeco.com/caroline/32/111867_2.png) [@caroline](https://forums.kodeco.com/u/caroline)\
**Post date:** [June 7, 2023, 12:56am UTC](https://forums.kodeco.com/t/use-of-read-in-fragment-function-for-mtltexture/187807/4 "2023-06-07T00:56:59Z")

</div>

I suspect this is the issue where I hard-coded the scaling.

Does this fix your issue?

> [@Question about input coordinates in fragment shader](https://forums.kodeco.com/t/question-about-input-coordinates-in-fragment-shader/179791/2):
>
> Looks like I took the easy way out woman_facepalming. x2 is the scale factor of the screen, and the Pro Max has a scale factor of 3. This is the fixed final sample. The changes are: Common.h - add this to Params: uint scaleFactor; Add this to Renderer.init(metalView:options:): #if os(macOS) params.scaleFactor = uint(NSScreen.main?.backingScaleFactor ?? 1) #elseif os(iOS) params.scaleFactor = uint(UIScreen.main.scale) #else params.scaleFactor = 1 #endif In PBR.metal, change coord: …

If not, perhaps you could give me more details of your device, GPU, operating system, and even your zipped-up code?