Handmade Hero » Forums » Code » Reflection Bug
nicstop
Nick_zzz
1 posts
#3356 Reflection Bug
2 years ago Edited by Nick_zzz on April 17, 2015, 5:41 a.m.

After tweaking some values, I found that BounceDirection.z is always negative, so I switched it to be always positive and the reflection bug shifted to the bottom texture.
I think that this might be the broken piece.

1
2
3
4
5
6
Normal.xy = Normal.x*NxAxis + Normal.y*NyAxis;
Normal.z = NzScale;
Normal.xyz = Normalize(Normal.xyz);

v3 BounceDirection = 2.0f*Normal.xyz;
BounceDirection.z -= 1.0f;
SlappedSilly
Jerry Siebe
4 posts
#3357 Reflection Bug
2 years ago

To comment on a different reflection bug, I believe the speckels around the periphery of the sphere is caused by lerping the normals at that sharp transition. To prove this you turn off interpolation of the normals and just use the nearest sample.
SlappedSilly
Jerry Siebe
4 posts
#3359 Reflection Bug
2 years ago Edited by Jerry Siebe on April 17, 2015, 9:23 a.m. Reason: typos, grammar, clarification, lack of sleep

As for the distorted reflection, I'm now suspecting it's caused by interference between ScreenSpaceUV and SampleDirection in SampleEnvironmentMap().

* When the DistanceFromMapInZ is large, the change caused by SampleDirection is much greater than the ScreenSpaceUV influence, thus it looks more correct the further it is.

* When the DistanceFromMapInZ is small, the ScreenSpaceUV overwhelms the influence of SampleDirection.

* Inverting the SampleDirection.z changes the Map.y of the intersection, altering the direction of interference, hence even though it should look the same, it's not.

* The intersecion calculation for the top reflection and bottom reflection are interfered in opposite directions since the ScreenSpaceUV always biases the Map.y in one direction, thus the interference is always different for top and bottom.

Every case seems to fit, but I'm too tired to walk through the code to verify (it's 2AM).

Some thoughts on SampleEnvironmentMap(). ScreenSpaceUV should alter the DistanceFromMapInZ, not the Map.y directly. DistanceFromMapInZ is poorly named, it should be OffsetFromMapInZ. Distances are not negative. Same holds in DrawRectangleSlowly() once it is adjusted for the chosen map. Lastly, an offset more applicable to directly apply to Map.y would be a bump map. :) You know, in case you want something fun to do with that leftover byte.
5umaleth
Rowan Crawford
13 posts
#3360 Reflection Bug
2 years ago

SlappedSilly:
To comment on a different reflection bug, I believe the speckels around the periphery of the sphere is caused by lerping the normals at that sharp transition.

Yeah, I think that lerp is creating a sub-pixel bevel between the two planes. So the speckle isn't a bug, it's just a visual artifact.

Let me see if I can ascii it:

1
2
3
4
5
6
7
   :
   |       as encoded by the normal map
   |________

   :
   |       as produced by the lerp
   \________



Bonus:

This isn't my image, but it shows which way the reflection should bend.

cmuratori
Casey Muratori
799 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3361 Reflection Bug
2 years ago

SlappedSilly:
As for the distorted reflection, I'm now suspecting it's caused by interference between ScreenSpaceUV and SampleDirection in SampleEnvironmentMap().


You are totally correct. The problem is that I again forgot that we are doing the weird "this is facing the camera even though it is technically not facing the game in world space" sprite perspective. Movement in Y _should actually be movement in Z_ for purposes of the map, so that is where the anomaly is coming from.

- Casey
5umaleth
Rowan Crawford
13 posts
#3363 Reflection Bug
2 years ago

cmuratori:
Movement in Y _should actually be movement in Z_ for purposes of the map, so that is where the anomaly is coming from.


I wonder if a do-nothing macro would help clarify this in the code. Something like:

1
2
3
4
#define YEncodedAsZ(y) (y)
.
.
float Z = -YEncodedAsZ(MyVar.y);
pajh
Paul
2 posts
#3364 Reflection Bug
2 years ago

Just 2 quick points on this after watching 103 -

To me the sphere has a distinct black border - ie the pattern does not seem to reflect all the way to the edge.

Secondly in this weird Y/Z "what to they mean?" scenario, you're intending on doing either laying down or standing up "cards" - but if you consider something like the way a barrel is drawn in most "2d" games - ie an upright cylinder where you also get a view of the top - as you start at the bottom and move up in Y (in terms of the sprite) you are actually moving "up" (ie away from the ground) ie the sprite needs to be treated as an upright card, however as you cross the boundary to the lid moving in "sprite Y" is now no longer moving away from the ground plane but parallel to it.
cmuratori
Casey Muratori
799 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3365 Reflection Bug
2 years ago

pajh:

To me the sphere has a distinct black border - ie the pattern does not seem to reflect all the way to the edge.

That is how reflections actually work - you cannot deflect a straight incoming vector with no upward or downward angle into something pointing greater than or less than 45 degrees upward or downward when the angle of incidence of the plane of reflection is nearly coincident. The reflected vector instead will always be very close to the incoming angle. So the edge of the sphere would always be sampling from the "green" map, the one that we haven't figured out how to work with yet.

Now, this may not be what we want, but it's the actual "correct" reflection, so in order to change that, we'd have to switch to a different reflection scheme. And I do have a few ideas for how we might want to do that...


Secondly in this weird Y/Z "what to they mean?" scenario, you're intending on doing either laying down or standing up "cards" - but if you consider something like the way a barrel is drawn in most "2d" games - ie an upright cylinder where you also get a view of the top - as you start at the bottom and move up in Y (in terms of the sprite) you are actually moving "up" (ie away from the ground) ie the sprite needs to be treated as an upright card, however as you cross the boundary to the lid moving in "sprite Y" is now no longer moving away from the ground plane but parallel to it.
A good point, and another reason we may want to try encoding something slightly different instead of doing real reflection directly.

- Casey
d7samurai
66 posts

innovation through innovation™

#3366 Reflection Bug
2 years ago Edited by on April 19, 2015, 6:09 p.m.

..that last point is what confused me on friday, Casey, when I suggested your normals were "inverted"; I misunderstood the perspective you were operating on / in.

This is the actual viewpoint / reflection perspective you are calculating (yes?):

http://i.imgur.com/BUz97zs.png (normals in green)

..while I thought you were calculating this viewpoint / reflection perspective:

http://i.imgur.com/tgeveYL.png

..since I intuitively thought in terms of a [quasi] top-down perspective, based on how I am used to seeing the game on-screen.

With that perspective in mind, the reflections seemed off to me, and I figured the normals somehow must have been "flipped" to account for what I saw. And so here is what I meant by "the center normals are pointing sideways, while the edge normals are pointing up":

http://i.imgur.com/CkAwwAZ.png

software development should be a creative exercise, not a technical ordeal
fierydrake
Mike T
22 posts
#3367 Reflection Bug
2 years ago

I haven't been watching live, so I want to queue up a question for the Q+A: can you explain why the eye vector is 0,0,1 rather than 0,1,0 when calculating the reflections for the upright card type objects?
cmuratori
Casey Muratori
799 posts
1 project

Casey Muratori is a programmer at Molly Rocket on the game 1935 and is the host of the educational programming series Handmade Hero.

#3368 Reflection Bug
2 years ago

So really, we could use 0,1,0 for the upright card objects, I think, then we wouldn't do the Y->Z conversion that we're doing right now in the sampler. When we do the coordinate system pass this coming week, we can see what is the most concise way to support both kind of cards ("lying flat" and "upright").

- Casey
mmozeiko
Mārtiņš Možeiko
1274 posts
1 project
#3369 Reflection Bug
2 years ago

Here's how reflections should look like: https://i.imgur.com/SWMoI5d.png (with planes a bit closer - https://i.imgur.com/yJ447I8.png)

This is rendered by raytracining in POV-Ray. Top and bottom planes are infinite and sphere is 100% reflective.
d7samurai
66 posts

innovation through innovation™

#3371 Reflection Bug
2 years ago Edited by on April 20, 2015, 1:12 p.m.

mmozeiko:
Here's how reflections should look like

I think the problem isn't really getting the reflections physically correct per se, but choosing the right viewing angle(s) in the context of the game's perspective.

In your illustration we are essentially seeing the sphere from a first person perspective, as if we are on the ground with it. But in the game we would be looking at it from a quasi top-down, third person view - and therein lies the dilemma: should it then be represented as reflections onto a sprite standing upright (perpendicular to the ground) - seen from the front - or a sprite lying flat on the ground - seen from above - or some compromise between the two (like a 45º angle: http://static.e-onsoftware.com//p...ntegration/reflective-sphereS.jpg)? I.e. what would produce the "most correct" content of reflection for either when seen through the game's camera, given its artificial game world projection (which is a mix of top and front views; the world is rendered from above, individual elements are rendered from the front)?

software development should be a creative exercise, not a technical ordeal
Fred
20 posts
1 project

None

#3373 Reflection Bug
2 years ago

I think someone pointed it in the stream, but when the sphere is moving "forward" (i.e. moving down the screen), the reflected squares should move from the center of the sphere towards its edge.
But maybe that's just a consequence of the current y flip (where red ground is up and blue sky is down).

None
d7samurai
66 posts

innovation through innovation™

#3374 Reflection Bug
2 years ago Edited by on April 20, 2015, 9:44 p.m.

So far there hasn't really been any conflicts between the 3D "simulation space" and the quasi top-down view of the game's "render space", but the physics of reflection mapping kind of has one foot in each camp..

When rendering sprites like we do in HMH, the Z axis is effectively "folded over" and merged with the Y axis and that's problematic to represent "correctly".

I did a visualization to illustrate it better:

http://i.imgur.com/EYr4mKh.png

software development should be a creative exercise, not a technical ordeal