https://www.babylonjs-playground.com/#ITUDQS#25
If you zoom in and out everything is nice and smooth.
https://www.babylonjs-playground.com/#ITUDQS#26
The farther you zoom out the more it degrades the post process texture. I have no clue what is going on. The only thing that has changed was a camera.minZ and camera.maxZ were added.
Hi Pryme8,
Can you add screenshots to show the effect that you’re talking about? I tried the two Playgrounds (Chromium-based Edge) and looked at them in Spector.js, but I either didn’t repro or I wasn’t looking for the right thing.
The one with minmaxZ in on the left.
As you zoom out of the scene you will see pixels jumping and it’s obviously mipmap evaluation of the postprocess.
And I know it a bug, because here if I set the uniform manually (not through camera minZ maxZ) the artifacts disappear. These confirm that.
https://www.babylonjs-playground.com/#ITUDQS#39
https://www.babylonjs-playground.com/#ITUDQS#40
I mean obviously Ill just do this for the fix for now, but Its really weird how that does that when they are set.
Thanks! That’s helpful, and super interesting. I am actually not reproducing this in Edge, which is a surprise to me. What browser are you seeing this on?
Chrome, and it applies for Free Cams as well. I did not notice the effect at first, but then as I was working on stuff and moving around there was this jitter that I could not understand. So I fought with the ray system (which I have never had a problem like this before mind you) trying to figure it out, until I zoomed way out and recognized the mip pattern.
As soon as I leave the camera.minZ , camera.maxZ alone all is well. The crazy part is the camera is not even RENDERING ANYTHING! its gotta be a link between the post effect and the camera approaching what it considers the scenes limits?
I got the repro! Very cool; very odd. I’m not sure it’s a mipping problem; check out how the artifact behaves under very tight conditions:
https://www.babylonjs-playground.com/#ITUDQS#44
If you bring minZ and maxZ even closer, things go haywire even faster. I’ve far from proved it, but I think this is actually a floating point precision problem. At a guess, the difference between maxZ and minZ is appearing somewhere in the same equation as the camera’s position, so when the values in the latter get too large relative to the values in the former, floats are no longer able to represent the required magnitude and the required precision, and the math goes awry. Haven’t proved that, though. Thoughts?
https://www.babylonjs-playground.com/#ITUDQS#46
Which is really weird because the raymarching results should have nothing to do with it, it’s all the camera and what its deciding to do the to post process internal texture.
The ray marching code is impacted by the min/max Z values of the camera because you pass it the camera.getTransformationMatrix() matrix.
This matrix (well, the projection matrix, but it is part of the transform: transform = view * projection) is impacted by the camera min/max Z values, so you end up with different matrices when you change the camera near/far planes.
I never would have thought of that… Thank you!
