Conversation
poweifeng
force-pushed
the
docs-update-readpixels
branch
from
0985c4c to
bb73db2
Compare
poweifeng
changed the title
And remove the pngs that documented the same thing.
poweifeng
force-pushed
the
docs-update-readpixels
branch
from
bb73db2 to
f0a3b10
Compare
| - Filament defines its coordinate system using the *top-left* of the image as \\((0, 0)\\) and | ||
| the *bottom-right* is \\((1, 1)\\). |
There was a problem hiding this comment.
Is that true though? (like it's not true for textures). Maybe give an example of a filament public API that uses that convention?
pixelflinger
left a comment
pixelflinger
left a comment
There was a problem hiding this comment.
I think i would structure things differently.
The first paragraph is good. I would then describe what each backend does:
GL:
- uploads: low-address is bottom
- readbacks: bottom is low address
- rendering: origin is bottom-left
- sampling: origin is bottom-left
Others:
- uploads: low-address is top
- readbacks: top is low address
- rendering: origin is top-left
- sampling: origin is top-left
Then I would explain that this means that:
- upload + read: works in all backend
- but: render + read: produces different results
Then I would say that filament addresses this by:
- inverting reads when reading
- this fixes the render + read path
- this sacrifices the upload + read path
- this is an unsolved problem in filament, only case where backends behave differently
| coordinate system. | ||
|
|
||
| The GL function for uploading texture is `glTexImage2D`. Even though GL interprets \\((0, 0)\\) as | ||
| the bottom-left of a 2D image, `glTexImage2D` uploads the lower-bits as the *bottom* of the image |
There was a problem hiding this comment.
I would say "lower-address bytes/data/pixels".
|
|
||
| | | | ||
| |---| | ||
| | *Filament's internal texture coordinate space defines the **top-left** corner of the image as the origin.* | |
There was a problem hiding this comment.
I see what you mean, but strangely I think of it the other way around.
| origin. Hence, the first row of the image in CPU memory is the bottom-most row of the image (when | ||
| displayed). | ||
|
|
||
| This creates two related inconsistencies: |
There was a problem hiding this comment.
This bothers me to say this because GL is actually very consistant (it's in fact the most consistant of the APIs, imho).
| displayed). | ||
|
|
||
| This creates two related inconsistencies: | ||
| - First, (not a real use case), if one were to upload a texture, attach it as an attachment, and |
There was a problem hiding this comment.
True, but since glTexImage2D also did that, this all works out perfectly. The image wouldn't be "upside down". You'd get exactly the same bytes that you used for glTexImage2D.
| - Second, the other backends consider the top-left corner as the origin, which means their | ||
| readbacks would place the top of the image as the first row of the image in CPU memory. |
There was a problem hiding this comment.
This also works out because their upload is consistant.
| To account for these inconsistencies, *the GL backend vertically flips the rows of the readback | ||
| image*. |
There was a problem hiding this comment.
That's actually not correct. The GL backend inverts read pixel for a different reason!
It's for the case where you RENDER into an attachment. We want to get the same data back on all backends when using readPixels.
bejado
left a comment
bejado
left a comment
There was a problem hiding this comment.
Are the diagrams inside art/diagrams no longer accurate? If so, maybe we could update them instead of getting rid of them entirely.
Yes initially I just wanted to add text to the pictures because I found the pictures themselves a little confusing. But as I started writing, I thought words enough would be sufficient. But we could do something in the middle where the pictures are included in this doc as embedded illustrations. |
3 participants
No description provided.