- Home /
WorldToScreenPoint returning VERY high values
So I am trying to implement quad-tree terrain. I want the terrain chunk to subdivide into 4 child chunks on the condition that the chunk is taking 25% or more of the screen space.
Here is the code I use to determine that (found elsewhere on here):
private void CheckForSubdivision() {
Vector3[] corners = boundsCorners;
float minX = Mathf.Infinity;
float minY = Mathf.Infinity;
float maxX = -Mathf.Infinity;
float maxY = -Mathf.Infinity;
for (var i = 0; i < corners.Length; i++) {
var corner = transform.TransformPoint(corners[i]);
corner = Camera.main.WorldToScreenPoint(corner);
if (corner.x > maxX) maxX = corner.x;
if (corner.x < minX) minX = corner.x;
if (corner.y > maxY) maxY = corner.y;
if (corner.y < minY) minY = corner.y;
minX = Mathf.Clamp(minX, 0, Screen.width);
maxX = Mathf.Clamp(maxX, 0, Screen.width);
minY = Mathf.Clamp(minY, 0, Screen.height);
maxY = Mathf.Clamp(maxY, 0, Screen.height);
}
float width = maxX - minX;
float height = maxY - minY;
float area = width * height;
float percentage = area / (Screen.width * Screen.height);
if (percentage >= Terrain.MAX_CHUNK_SCREEN_PERCENTAGE) {
Debug.Log("Chunk " + transform.name + " uses " + (percentage * 100) + " screen space; subdividing");
Subdivide();
}
}
boundsCorners is an array of 4 vertices that represent the 4 corners of the plane that make up the current chunk.
This works perfectly at first. As I move my camera closer to the terrain, the chunks are subdivded further and further. However...
After about the 5th subdivision, the screen space being used always registers as 100%, and unity hangs. Debugging showed me that when this happens, the corner variable has values like this after being processed by WorldToScreenPoint:
BEFORE:
x: 2.605358f
y: -1.97875226f
z: -4.22133827f
AFTER:
x: 126353.117f
y: 54890.8555f
z: 0.00229765475f
These are clearly WAY off the boundaries of my screen! What could possibly cause this? As far as I understand; the values should be within the range of my viewport resolution no?
It is worth noting that this terrain is spherical, and as such we will almost never be looking at it from the global x/y/z orientation (aka: camera will almost never point at -Vector3.up for instance).
I'm just trying to understand why values like this are being returned when I get very close to the mesh, and also interested in hearing about alternative approaches to get the same result.
I think the numbers can legitimately get that big.
If the position is off the screen, the resulting numbers will (and should) be off the screen. In theory, if you're in really tight on a plane, the corners could give huge numbers (meaning they are off-screen by many, many screens.)
I thought of that after posting this, and maybe it is a sign of a deeper issue. The thing that throws me off is that my log messages consistently say 25%, then jump to 100% after the 5th subdivision.
Just to make sure I understand, what SHOULD be happening; the screen space percentage used by each subdivision should grow LESS with each subdivision, right?
Assu$$anonymous$$g Owen is correct (usually as safe bet): this means you may have multiple subdivision happening BEFORE you get to less than 100% screen size (if the initial corners are way off screen.) But, the part where you clamp the $$anonymous$$ and max values to the screen size, means that even if greater than 100% screen size is actually used, it will still yield only 100% value.
$$anonymous$$gest a debug.log() with an UNCLA$$anonymous$$PED final percentage number to help figure things out. Since you compare to 25%, shouldn't even need to change any logic.
Here is what is supposed to happen:
presented with terrain, camera looking straight at it from a distance.
zoom in (by moving camera transform)
as i get closer, the chunks i am near take up more and more space on screen.
once they take up 25% of screesn space, subdivide, and disable self; showing children.
should now be 4 - 16 children (4 if hovering over 1 chunk, 16 if i was zoo$$anonymous$$g into a corner). chunks are smaller, so take up less screen space now.
goto step 2
Perhaps I should try to limit this check to chunks that are actually within the view frustrum of the camera as well.
Ok, that's what I suspected. So, I think this is an important clue:
After about the 5th subdivision, the screen space being used always registers as 100%
Why is the percentage going UP, rather than down? The code looks correct to me, if we ASSU$$anonymous$$E, that each Subdivide() call yields smaller ....
AH! because you are clamping those values, even if ALL the corners for a particular subdivision are far off the right side of the screen, you will still have a $$anonymous$$X of 0 (left side of the screen).
Just remark out those clamps, I think that will help.
edit: had a brain fart- that just ain't right.