I was going through a tutorial to make infinite scroll background, and they were trying to find the number of replications of the scene to make dynamically. In it the author was converting the camera to world space coords, like this:
)
That’s news to me!
That’s also news.
An ortho camera and a perspective camera both by default anchor to screen height, so unless you lock yourself to ONLY work on a known aspect ratio, one must compute the width of the visible area if one wants clouds (for instance) to loop at that lateral interval, which kinda smells like they might be trying to accomplish (I am not watching the video).
“projection is not a linear transformation” , it also became news for me. 
It’s seems it’s linear, I mistook it for something else.
The width and height of the camera are essentially bounds for the screenspace right? After NDC transformation, these are just multipliers and sholdn’t be part of the usual model->…->projection transformation pipeline(coming from openGL , but the concepts should apply). Why would they need to get into the world coordinates.
Again, without seeing the video, I assume it is because … everything in a normal 3D part of a scene is done in world space.
There are several ways to interpret your question, and I’m not sure which one you’re asking, so I’ll answer them all.
1. What is the difference between screen space and world space, and why do we need to convert between them?
Screen space is a map of pixels on the 2D screen denoted by an X and a Y coordinate. World space is the 3D coordinate grid made of X, Y, and Z in which objects are placed. If you’re given a point on the screen, it does not yet signify a point in 3D space and must go through several transformations. Additionally, any point on a 2D screen is associated with an infinite number of points along a line projected from the camera position to infinity, so you need to narrow that down a bit to focus on the actual point you want.
Sometimes, it makes more sense to work within screen space and then convert it back into world space to use. The most obvious example of this is working with the mouse, whose coordinates only exist within screen space.
2. Why calculate the width and height in code when we know it already and know it won’t change?
It is usually considered a bad practice to use so-called “magic numbers” in code. Let’s say that the height of the camera is known to be 5. If we use the number “5” in our code, that code will only continue to work as long as the camera continues to have a height of 5. If it changes, our code breaks. For this reason, wherever possible, ensure there is only a “single source of truth” about where data comes from – and this includes inside the source code.
3. What does the line of code mean in the tutorial? Why is he getting the width/height of the screen in such an esoteric way?
To be frank, line 12 in the video is not very good and contains a subtle bug. What he is essentially doing is getting the upper-right most pixel on the screen, and converting that into world space. When the camera is at the origin, it will return the half width and half height of the view frustum. At any other point, it will not. I do not recommend using this line of code. It is technically possible to make it work in all situations but it is more trouble than it’s worth, and there are better ways to achieve the same result.
If you know you’re working with an orthographic camera, getting the camera world space width and height is straightforward; height is camera.orthographicSize * 2, and width is height * camera.aspect.
For perspective cameras, the world-space width and height depends on the depth at which you’re measuring it, since perspective cameras’ view frustum is a pyramid shape. You can measure the width and height of the frustum at a given distance using some clever math.
You can use also use these techniques to calculate the world space bounds of the camera at a given distance, if you need the bounds rather than the size.
Another reason why that line of code (12) is problematic is that he’s deliberately taking a Vector3 from ScreenWorldToPoint and implicitly converting it into Vector2 which is the type of screenBounds. Surely this must be the fastest way into confusing viewers with any desire to get better at Unity and C#.
