- User Since
- Jun 2 2006, 5:16 AM (577 w, 8 h)
- Revert "Fix grease pencil in sequencer not responding to scene scale [WIP]"
- Different approach, same results
Also @Clément Foucault (fclem) shouldn't we have this for all modes/engines? Instead of only Eevee?
I'm not sure. Hopefully MSAA or TAA would be default for rendering, and not crappy FXAA. The performance impact of even the highest setting on Haswell intel GPU is so small...
As for the settings, if we really need to expose them, maybe we could think of an enum with presets (low-medium-high).
We can even use DRW_state_is_image_render() as a test and use a higher quality if rendering. (you may need to re-merge 2.8 in for that).
I finally managed to test this (thanks for using arcanist). I like the results. However I wonder:
Wed, Jun 21
Just to clarify, when using arcanist we get:
- Context for the patch, so we can look at the patched files and see the lines before/after
- The exactly revision the patch was created against. This way when I do arc patch D2717 it always work flawlessly. Otherwise it tries to apply to the current branch as it is, and it often generates conflicts.
Can I automatically get an email at blender.studio whenever the 2.8 (or all) builbots fail then? That would be enough. Anyways, closing this for now.
An important thing, please start using arcanist for your patch submission. It makes testing it way simpler. As it is the patch is not applying cleanly.
Tue, Jun 20
Some minor comments inline, I will test the patch later.
Mon, Jun 19
Confirmed. And just to state the obvious (for developers), the same is valid for Japanese and probably any other unicode.
Small inline changes I had to do for OpenColorIO building (rB701a76769d4acb2dfda14a8fe2ef18ebd805d91c).
Overall I like the idea of adding consistence to the API. But I think we are shortening things more than we really need. See some inline comments.
That said I'm not passionate either way.
Fri, Jun 16
Thu, Jun 15
Driver 4534 has problems.
Drivers 4590 and 4627 work.
Wed, Jun 14
Tue, Jun 13
Fixed since e791e01c0b0b58facf69eef11b4c46de869886d9
Resolved a few weeks/months ago.
Confirmed, crash log: P498
Mon, Jun 12
(for the records the original claim that clamping is the issue could be solved with P494, but RNA is already clamping the values before we get to the compositor, so this patch is uneeded)
This is not related to the directional blur node. Here is an even simpler file using another node:
Note that the compositor node is not even being used.
The asan crash on exit was fixed on rB109447d008b4719f24a807560c6cb9a63fc8f51f.
Confirmed. Note to other testers on how to test it:
- Load file, enable auto-run scripts
- Switch viewport to rendered
- The viewport has nothing rendered.
Another way of testing the depsgraph warnings, which may (or may not) be related:
To reproduce it without the file:
./blender -b --python-expr "import bpy;bpy.context.scene.master_collection.collections.new('My Collection').objects.link(bpy.data.objects['Cube']);bpy.ops.scene.new(type='FULL_COPY');"
Mesh is corrupt, closing the report.
Full disclosure: This file may just be corrupt. Maybe it happened when applying modifiers, maybe at some other point. Unless there is anything we can do about those, I suggest we just close this bug.
@Bastien Montagne (mont29) @Campbell Barton (campbellbarton) ?
Sun, Jun 11
@Campbell Barton (campbellbarton) are all the critical topics addressed/committed already?