I did those restore things , but how to make that camera view is the same size than render border area, it speeds up a lot viewport rendering for my case.
I want simply to set render border area and immediately see whats going on there on 3d viewport and then restore and then see another places. And I can keep camera settings for final render that way.
Unfortunately that seems to be a little beyond my scope at my current python and blender api skills.
I understand your use case a little better but I don’t get why you need to do things this way. If it’s just meant for temporarily previewing specific areas in the 3D viewport, why is the border render not good enough for you ?
Just to notify that I moved the add-on (and all my repositories) to Gitlab. Link in first post that I just edited.
No news apart from that.
Thank you!
This was exactly what I was looking for! Unfortunately I can’t use it with blender 2.8. Would it be possible to upgrade this addon to 2.8?
i needed to render a huge image with evee and my pc didn’t have enough ram to do it, so i used some code from this addon to make a camera array, the split part. It creates a new linked scene and creates an ‘array’ of cameras so you can render on lower ram machines.
Just change the variable tiles (tiles=4, for a 2x2; tiles=9 for a 3x3 …)
import bpy
import math
tiles = 9
camera = bpy.context.scene.camera
resolution_x = bpy.context.scene.render.resolution_x
resolution_y = bpy.context.scene.render.resolution_y
# duplicate scene
bpy.ops.scene.new(type='LINK_COPY')
bpy.context.scene.name= 'Camera Array'
for column in range(round(math.sqrt(tiles))):
for row in range(round(math.sqrt(tiles))):
# add new camera
bpy.ops.object.camera_add(location=camera.location, rotation=camera.rotation_euler)
# name
bpy.context.object.name = '%s_array[%s,%s]' % (camera.name, column, row)
bpy.context.object.data.name = '%s_array[%s,%s]' % (camera.name, column, row)
# lens
bpy.context.object.data.lens = camera.data.lens * math.sqrt(tiles)
# resolution
res_x = round(resolution_x / math.sqrt(tiles))
res_y = round(resolution_y / math.sqrt(tiles))
bpy.context.scene.render.resolution_x = res_x
bpy.context.scene.render.resolution_y = res_y
# shift x
bpy.context.object.data.shift_x = -(math.sqrt(tiles) / 2) + 0.5 + row
# shift y
ratio = resolution_y / resolution_x
bpy.context.object.data.shift_y = -((math.sqrt(tiles) / 2) - 0.5) * ratio + (column * ratio)
Glad to see I’m not the only person on Earth to need this.
Sure I’ll update it, after 2.8 gets officially released (because the python API is still subject to change) and after I’ve learned some more about python code and Blender add-on development.
Until then you should be able to use it in 2.79 and import your camera in 2.8.
I created all my arts with 2.80, i always worked with 2.80( yeah I’m new-comer).
So i can’t work with 2.79 I’m not familiar to it’s ui , we need it in 2.80.
Ok, I can give some time next week to work on this, but given the massive leaps Blender’s render engines have made since I first made this add-on, I must ask you: are you sure this is the best solution for you?
Unless you either have to render in 8k or have a toaster for a computer, render times have dropped to a point where I don’t find this tool necessary in most situations anymore.
Most of the times, long render times can be divided many times by optimizing render parameters for your specific scene, which I strongly encourage doing.
However, if that’s not enough for you, I’m curious to know your situation.
This is very interesting. The main problem I can think that could happen is screen space effects that depend a lot on the edges of the camera. I guess that Film > Overscan configuration could minimize the problem. I will test the code later.
I still haven’t updated it to 2.8. I plan to do it asap since I acutally need it in my job but otherwise its main purpose is definitely not to speed up Eevee renders as it was created before this engine existed and I highly doubt the “frame-splitting” approach would have any positive effect on its rendertimes.
Yes, I understand it, but it is a nice use that can be given to your code. We don’t really talk about speed up Eevee render. It happens that Eevee could use a lot of vRAM in some cases, especially for large output resolutions. So this method to divide the camera into camera tiles could help users with GPU with not much vRAM, or to render very large resolution outputs.
I just updated the cropper to 2.8: https://gitlab.com/ChameleonScales/camera-cropper/tree/master
I decided to split the add-on in 2 (no pun intended), as the camera splitter serves a different purpose.
I haven’t started updating the splitter though.
In the cropper I added support for equirectangular cameras.
More updates to come but at least this is usable.
Sorry for the long delay.
Update for Camera cropper:
- support for orthographic camera
- buttons to place cropped render back in original frame
Read the readme for instructions
Update:
- Automated 8 steps that you previously had to perform manually
- the whole process is now non-destructive. Previously, using it would replace camera and render data which could not be retrieved other than by Ctrl+Z or prior note taking. Not anymore, because now it adds a new cropped camera and stores render data in both the original and the new one.
- new feature/button to retrieve render dimensions from any camera
- new addon preference to change the tab name
- can now be installed the “normal” way (download the zip and install it directly from the Blender User Prefs)
- can be used in combination with my new Equi to cyl region add-on if you need a central cylindrical projection
See the Readme for more info
I also changed the url of the add-on: https://gitlab.com/ChameleonScales/camera_cropper
Don’t forget to give suggestions and bug reports if you use it and feel free to ask questions.
any video tutorial how it works. Thanks
ok I’ll do that
there you go : https://peertube.mastodon.host/videos/watch/1f21e0a5-3ca6-4b7b-979c-ee5ec333869c
If you have further questions feel free to ask.
I remade the tutorial and updated the above link 🠕🠕.
It should be a lot clearer and more complete now.
New version coming very soon. Just some cleanup to do and small user-safety functions to add. Stay tuned.