[Scummvm-tracker] [ScummVM :: Bugs] #11847: EMI: Animated sea surface texture looks clamped instead of repeated in set "shi" with TinyGL

[ScummVM :: Bugs]

#11847: EMI: Animated sea surface texture looks clamped instead of repeated in set
"shi" with TinyGL
----------------------------------------+--------------------------
  Reporter:  aquadran                   |      Owner:  (none)
      Type:  defect                     |     Status:  new
  Priority:  low                        |  Component:  Engine: Grim
Resolution:                             |   Keywords:
      Game:  Escape from Monkey Island  |
----------------------------------------+--------------------------
Description changed by aquadran:

Old description:

> I am investigating the cause of this issue, but so far I understand
> little of it.
>
> [[Image()]]
>
> I read this as: we see texture's edge, the texture being centered
> somewhere below camera position. Lines going towards Guybrush move along
> with the pixels near the edge. The solid-colored area on top-right
> changes color periodically, likely extending from texture's corner.
>

>
> Here the texture looks mostly fine. There are flashes in the shadow (the
> bottom of one pole is lighter in this screenshot), which I assume are the
> underlying solid color showing through. There is a likely-unrelated issue
> on this scene that the see looks darker when I load the save than after
> the first camera angle change. Texture issue being present both before
> and after.
>

>
> And here we see another border and corner area, plus flickering glitches
> (the darker rectangular patch in the distance).
>
> To me, this looks as if this texture was configured for GL_CLAMP_TO_EDGE,
> but TinyGL only supports GL_REPEAT (and by applying a factor to s & t
> coordinates on vertices, I could confirm textures do get repeated).
>
> I have found a handy illustration of GL wrapping modes.
>

> I think I understand a tiny bit more: this is "uniwaterhilite.cosb"
> costume with mostly transparent textures "hilites???.tga" (declared in
> "hilites.sur") and a mesh, "uniwaterhilite.meshb".
>
> I should have mentionned opengl and opengl_shaders do not have the main
> described issue, so it seems unlikely to be a data or parsing issue, but
> really something specific to tinygl.
>
> And for completeness about opengl modes, they do have the dark-water-on-
> load (including the "set_renderer" implicit save/load) which become
> lighter when camera angle changes, and opengl_shaders has the row boat
> partly in the water. But these are other bugs.
>

> The mesh has texture coordinates going from 0 to 8, hence forcing the
> texture to repeat itself.
> I changed it to 64 and hacked the software renderer to show texture
> coordinates as colors. We would expect the square pattern in the bottom
> left to repeat for the entire quad, but this is not the case.
>

> Slowly rotating the shi.water3 actor causes the lines at the top to jump
> around erratically. I ran out of time yesterday, but my next step would
> be to reposition the camera above, looking down.
> If viewing the entire quad at once works properly, the issue might be due
> to clipping...
>

> I lack the skill to play with scenes like that, but I like a lot the idea
> of coloring according to u and v. I also suspect clipping may be the
> issue, and am working my way back from ztriangle.cpp, simplifying code by
> dropping optimisation to get a better understanding of what happens
> where.
>
> Something surprising I noticed when viewing the scene with all its
> components but the uv hack is that the wideness of these "rays" to
> horizon changes, meaning xyz coordinates are involved in uv errors.
>

> Tested this morning with glOrtho camera setup and a quad perpendicular to
> the camera angle: no issues.
> Next up: perspective-correct rendering with glFrustum and/or giving the
> quad a slight tilt.
>
> Having done a bit of reading this week-end on texture mapping, I wonder
> now if this would be "just" the effect of perspective-incorrect texture
> mapping. I'm still having trouble wrapping my head around the code, but
> it looks like it does (try to ?) adjust texture mapping for perspective
> correctness: runs of 8 pixels with linear(?) interpolation, and z adapted
> between each.
>

> https://github.com/residualvm/residualvm/issues/1336

New description:

 I am investigating the cause of this issue, but so far I understand little
 of it.

 [[Image(c8f3e98a-2b47-11e7-98d8-5e5abbef8d4f.png)]]

 I read this as: we see texture's edge, the texture being centered
 somewhere below camera position. Lines going towards Guybrush move along
 with the pixels near the edge. The solid-colored area on top-right changes
 color periodically, likely extending from texture's corner.

 [[Image(44ec2fb6-2b48-11e7-8f6c-e8c842c62df9.png)]]


 Here the texture looks mostly fine. There are flashes in the shadow (the
 bottom of one pole is lighter in this screenshot), which I assume are the
 underlying solid color showing through. There is a likely-unrelated issue
 on this scene that the see looks darker when I load the save than after
 the first camera angle change. Texture issue being present both before and
 after.

 [[Image(88af2226-2b48-11e7-9b18-4569f32946a9.png)]]


 And here we see another border and corner area, plus flickering glitches
 (the darker rectangular patch in the distance).

 To me, this looks as if this texture was configured for GL_CLAMP_TO_EDGE,
 but TinyGL only supports GL_REPEAT (and by applying a factor to s & t
 coordinates on vertices, I could confirm textures do get repeated).

 I have found a handy illustration of GL wrapping modes.


 I think I understand a tiny bit more: this is "uniwaterhilite.cosb"
 costume with mostly transparent textures "hilites???.tga" (declared in
 "hilites.sur") and a mesh, "uniwaterhilite.meshb".

 I should have mentionned opengl and opengl_shaders do not have the main
 described issue, so it seems unlikely to be a data or parsing issue, but
 really something specific to tinygl.

 And for completeness about opengl modes, they do have the dark-water-on-
 load (including the "set_renderer" implicit save/load) which become
 lighter when camera angle changes, and opengl_shaders has the row boat
 partly in the water. But these are other bugs.


 The mesh has texture coordinates going from 0 to 8, hence forcing the
 texture to repeat itself.
 I changed it to 64 and hacked the software renderer to show texture
 coordinates as colors. We would expect the square pattern in the bottom
 left to repeat for the entire quad, but this is not the case.


 Slowly rotating the shi.water3 actor causes the lines at the top to jump
 around erratically. I ran out of time yesterday, but my next step would be
 to reposition the camera above, looking down.
 If viewing the entire quad at once works properly, the issue might be due
 to clipping...


 I lack the skill to play with scenes like that, but I like a lot the idea
 of coloring according to u and v. I also suspect clipping may be the
 issue, and am working my way back from ztriangle.cpp, simplifying code by
 dropping optimisation to get a better understanding of what happens where.

 Something surprising I noticed when viewing the scene with all its
 components but the uv hack is that the wideness of these "rays" to horizon
 changes, meaning xyz coordinates are involved in uv errors.


 Tested this morning with glOrtho camera setup and a quad perpendicular to
 the camera angle: no issues.
 Next up: perspective-correct rendering with glFrustum and/or giving the
 quad a slight tilt.

 Having done a bit of reading this week-end on texture mapping, I wonder
 now if this would be "just" the effect of perspective-incorrect texture
 mapping. I'm still having trouble wrapping my head around the code, but it
 looks like it does (try to ?) adjust texture mapping for perspective
 correctness: runs of 8 pixels with linear(?) interpolation, and z adapted
 between each.


 https://github.com/residualvm/residualvm/issues/1336

--
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/11847#comment:1>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM