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.
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; |
Edited by Nick_zzz
on
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.
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.
* 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.
Edited by Jerry Siebe
on
Reason: typos, grammar, clarification, lack of sleep
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.
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
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); |
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.
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.
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...
A good point, and another reason we may want to try encoding something slightly different instead of doing real reflection directly.
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.
- Casey
..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
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
Edited by d7samurai
on
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
- Casey
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.
This is rendered by raytracining in POV-Ray. Top and bottom planes are infinite and sphere is 100% reflective.
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)?
Edited by d7samurai
on
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).
But maybe that's just a consequence of the current y flip (where red ground is up and blue sky is down).
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
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
Edited by d7samurai
on