- User Since
- Nov 27 2016, 8:06 AM (187 w, 5 d)
Sun, Jun 28
Feb 24 2020
Forget it, I shouldn't program late at night. :)
Feb 23 2020
Nov 21 2019
Thanks for the speedy decision at least. I'll pursue my work around using multiple cameras for now, maybe a useful tiling addon will even come out of it.
The same way Blender solves it now when you change the camera's focal length and aspect ratio? Nothing is changing with the render path here, you're changing the camera being rendered to a camera that makes up the render region's aspect ratio with an adjusted focal length to match the original camera.
@Jeroen Bakker (jbakker) You don't need any math to fix screen space effects, just math to clip the camera to the region. Screen space effect artifacts from region renders can be dealt with by adjusting the overscan option, assuming that's properly integrated into the fix.
@Maciej Jutrzenka (Kramon) Unfortunately, it's not that simple. Try it yourself, if you shift the camera without changing the focal length, you just render more of the view, not a higher resolution version of the current camera view. I am working on an actual work around though, if i can figure out the math to generalize it, if they decide not to fix this.
@Philipp Oeser (lichtwerk) I think this can be avoided by clipping the viewport to the render region like Cycles does. You can see this in the viewport when it draws too, Eevee doesn't clip to the render region like Cycles will if one is set. I looked at the code and it appears Eevee uses very similar code to setting up for the viewport while rendering, which is probably where this slipped in.
Nov 19 2019
Sep 10 2019
@MACHIN3 (MACHIN3) The included Blender add-on F2 sets a keymap entry of F to mesh.f2. Node Wrangler also creates numerous entries in the keymap. These are not filtered out when Workspace Filter Add-ons is enabled but the add-ons are not checked, as far as I can tell.
Jun 2 2019
Confirmed, I get the same weird behaviour on Windows 10 64bit, Nvidia GeForce GTX 1080Ti, Blender 2.80 Beta Windows 64 bit Date: 2019-06-01 22:51 Hash: 079c7f918c81
Mar 17 2019
Confirmed on Windows Version 2.80 Beta Date: 2019-03-16 18:21 Hash: 2d3fbadfe36d
Jan 22 2017
This task is getting messy but I don't see a way to reconcile this task with a new one if they were to be merged at the same time, so here's a new version of mesh_carver.py with all of my changes for this task and the preferences/key for changing the solver while using it.
That's simply the opposite side of the same coin. Blender's default is supposed to be Carve according to the documentation and there wouldn't be an issue with the booleans if that were still the case in 2.78a(I don't know when the solver default changed or if it is supposed to and the docs are just out of date). I would like to bring up that if you turn off Apply Operations in Carver MT, that patch would still allow you change the solver to address those certain cases. Perhaps both my patch and your suggestion are out of scope for this task.
Jan 18 2017
I think all the boolean modifiers used by this addon should explicitly set the solver to "CARVE". The default "BMESH" solver in Blender 2.78a breaks Line Rebools that are entirely enclosed by the target mesh and in other cases. BMesh doesn't seem like it should be the default, either, if Blender documentation is correct. Here's a patch for my update.