I'm running into memory issues trying to render an image with Eevee at a resolution that can be cleanly printed onto a poster. After increasing the render resolution past a point I crash the GPU. Is there any way to render the image in small grid tile chunks like cycles and blender internal (which devs claimed Eevee was completely sufficient to replace) to prevent over working the GPU? Ide use cycles but the difference in how lights works destroys the composition I've set up and I don't have 12+ hours to spare on rendering this image. If this can't be done can I have an explanation as to why such a basic feature cannot be implemented?
I have an old script(add-on) never intended to be shared and I would probably be ashamed of it if I read it now, but it does split a camera into many and puts markers on the timeline for each new camera. The math is wrong and it does not handle portrait orientation cameras that are shifted correctly.
You can install it like an addon and then just select a camera, set desired start keyframe and use search (F3) to find "Camera Split". It will create the cameras and make markers on the timeline for them:
Blender currently doesn't support tiling in Eevee, however as stated in Rich Sedman comment, this can be achieved by tinkering with the focal length, Shift X, and Shift Y. First, you will need to figure out how many tiles you want. Try to figure out what is the maximum resolution you can render in your project, it is usually not much higher than the maximum resolution supported by your graphics card, but it doesn't seem to be capped at it anymore. Divide the resolution of the final image by the number of tiles on each axis so it is smaller than or equal to the maximum resolution you can render, let's call this number
n. For example, if I want a final image with a resolution of 20000 by 11250 and the maximum resolution I can render is 8000 by 4500 I can use 3 as
20000/3 = 6666.66... ≤ 8000 and
11250/3 = 3750 ≤ 4500.
Now you have to change the lens unit to
Field of View and divide your focal length by
Now you have to divide the sensor size by
n, you could use depth of field but different depths of field cause different distortions as Jachym Michal pointed out – thanks Jacym :).
Now you have to set up the Shift X and Shift Y. If the image is wider than it is tall the first Shift X value is
n/2 - 0.5 times -1 (just add a minus in front of the number) if it is taller than it is wide you must multiply the value by the width divided by the height e.g. if the aspect ratio is 9:16 you should multiply the values by 9/16 which is 0.5625, keyframe the Shift X value. Now you need to set up the last Shift X value of this row, to do this, go to the frame
n (assuming the first keyframe was on frame 1), and enter the new Shift X value, which is the same value as before but not negative and keyframe it again. It should look something like this:
Now duplicate these keyframes
n - 1 times, so the camera will go from the left to right
n times. It should look something like this:
Now it's time to set the Shift Y values, the values should be
n/2 -0.5, just like before. If the image is wider than it's tall you must multiply the value by the image height divided by the width e.g. if the aspect ratio is 16:9 you should multiply the values by 9/16 which is 0.5625. Where the values were negative in Shift X they should be positive and vice-versa. So go to frame 1 and set the Shift Y to
n/2 -0.5, multiply it by the height divided by the width if the image is wider than it is tall, and keyframe it. Now go to the frame where the next Shift X keyframe is and keyframe the Shift Y again, this will make the Shift Y remain constant while the Shift X goes from left to right. Now advance one keyframe so the Shift X goes back to the initial value, and subtract
n/2 - 0.5 if the image is wider than it's tall multiply it by the height divided by the width of the image and keyframe it. Now go to the next keyframe (the default key for this is the arrow up), keyframe the Shift Y value again (like on the last row, it will keep the value of the last keyframe, so the Shift Y will remain constant as the Shift X scans through this row). Repeat this process for all the rows so you have an
n grid of tiles. Now change the interpolation to linear by selecting all the keyframes and right-clicking them and then choosing linear under interpolation. It should end looking something like this:
Now you change the end frame to the total number of tiles or
n². You will also need to change the resolution to your original resolution divided by
n on both width and height. Render an animation rather than a still frame.
Now you have a sequence of images that when read from left to right and top to bottom with a limit of n images per row will create the final image (that's why it is important that the Shift X starts negative and Shift Y starts positive). To create the final image you can use a variety of pieces of software, such as image editors, however, due to the large dimensions of the images you can run into memory issues with them, so you should probably use a free and open-source software called ImageMagick. To do this open a terminal on the folder with the images you rendered and run
magick montage -mode concatenate -tile 3x *.png final-image.png replacing the 3 in "3x" by
n and the .png in "*.png" by the format you are using if it's not PNG. This will take a while and can make your computer irresponsive depending on the size of the final image. If you feel like throwing 75 euros at the problem or you don't mind a bunch of demo marks on the final image, there is a little piece of software called Very Large Image Joiner you can use, it will make the process way faster and will use almost no RAM, but it's 75 euros if you don't want those demo marks.