- User Since
- Oct 18 2011, 11:01 AM (388 w, 16 h)
Mon, Mar 4
Sat, Mar 2
They disappeared early June 2018 which coincided with the changeover from the template_colormanaged_view_settings to template_curve_mapping widgets. The latter looks to be designed for reuse around the UI, but needs type="COLOR" to show the buttons.
Feb 14 2019
Yep, although I hesitated to say the UI colours are tied to the display device setting since they look slightly skewed;
Feb 13 2019
Jan 31 2019
Jan 28 2019
Jan 16 2019
With the viewport set to Rendered, the output still gives different results:
Oct 10 2018
@Campbell Barton (campbellbarton) I can't think of a clearer description with the current logic so the existing labels/tooltips are probably best left as-is.
Aug 26 2018
Aug 24 2018
But the first face is included in the sequence pattern, otherwise we'd see an extra selected face at the start: 1110011001100 and that isn't what's happening.
Aug 20 2018
Hi, any update on the first issue?
Aug 18 2018
Aug 16 2018
Aug 15 2018
The offset now looks OK, but the first face is still permanently selected so we get sequences like this:
Aug 14 2018
Hinting can sometimes add space between characters, but that does seem rather a lot.
Aug 13 2018
Just to recap:
It still seems that the v40 interpreter does no hinting horizontally. Since latin/western characters have a lot of straight verticals, it's an interesting design decision... Need to find out more to understand the reasoning behind this.
Aug 10 2018
Yep, that's a known tradeoff with hinted text and not really avoidable. Also the weight/boldness of the text won't be accurately represented. But you trade those things for sharp font edges. For desktop publishing, graphic design, you definitely wouldn't want it. But it's good for raw clarity (code markup, UI text, terminal/shell sessions, etc). I use both depending on the job.
Maybe I'm not reading this correctly, but in ttinterp.h from Freetype 2.9.1 on line 278:
Aug 9 2018
The change to 2.9.1 (v40) would adversely affect the font hinting.
Aug 6 2018
Aug 1 2018
Jul 28 2018
I'm unsure what the issue is.
Jul 4 2018
Sep 17 2017
Just to add:
Sep 12 2017
Sep 11 2017
I'm running Firefox dev branch (56.0b10).
Sep 8 2017
Sep 7 2017
The crux of this seems to be - "it's not a bug because the code works as intended, therefore it's a feature request" vs "the original design specification has a bug".
Sep 6 2017
Some examples drawn in the 2d editor and 3d viewport:
I can't see how this would be considered either a feature or enhancement.
Sep 3 2017
Sep 1 2017
Aug 18 2017
I can confirm this fixes the clamp function in all bevel modes except for 'percent' - in that case the bevel still sometimes stops short.
Jun 15 2017
Jun 6 2017
Jun 4 2017
May 25 2017
May 23 2017
Apr 18 2017
@Sergey Sharybin (sergey) looks like the latest linux builds are fixed.
Apr 17 2017
Confirmed. Removing the line from config.ocio is enough to fix.
Apr 16 2017
"My purpose is to enable a common/ universal audio codec by default e.g. .mp3"
Apr 15 2017
Mar 12 2017
Mar 1 2017
There seems to be two independent clamping events/rules. The 'clamp overlap' option only affects whether new bevel geometry overlaps other new bevel geometry. But even with that disabled, the bevel doesn't normally cross over pre-existing geometry (which seems sensible) - unless you're bevelling a complete edge loop.
Feb 28 2017
Looks like there's no single video format that's compatible with modern browsers...
Nov 29 2016
Is there a plan to fully define all the allowed combinations of containers, video and audio codecs, and their individual parameters? Maybe in some easily editable xml file.
Oct 11 2016
Just to add, I tried the supplied .blend and have got inconsistent results after removing the embedded images. On one attempt, RAM usage didn't decrease for the single channel image. Another attempt seemed to work.
Ah, sorry. Didn't realise the inline image was it.
Can you upload the unpacked png that's causing the problem?
I'm seeing similar behaviour on 2.78 (linux), but only for packed images. Files referenced from disk use less memory as long as they're true single channel. I'm not seeing any memory savings on GPU though - packed or unpacked.
Jun 21 2016
Jun 15 2016
It's now working as expected. Thanks for the fix!
May 7 2016
Apr 22 2016
Apr 2 2016
It's conceivable that Blender could be outputting non-standards compliant video in some way. Might be enough to confuse Windows where VLC and mediainfo interpret the file structure differently.
Mar 27 2016
Mar 26 2016
You haven't mentioned if the rendered video plays fine, but this is looking like a Windows reporting issue. I remember hearing about similar issues with the Windows file manager some time ago.
Mar 25 2016
Does it try and play at 244fps in VLC and other media players?
Mar 24 2016
For what it's worth; I used the supplied .blend, substituted all the media clips with the provided MVI_0023.MP4 and left it to render the full project length. It wasn't enough to reproduce this bug.
Mar 23 2016
Another vote for this being an option with the default set to the long-standing behaviour.
Mar 22 2016
Generating Record Run timecode is enough to fix this.
Mar 21 2016
Sorry, I missed your update while composing mine.
Mar 20 2016
Can you see if it's possible to create a test scene with this clip that triggers the bug first?
Mar 19 2016
You haven't said where the source video came from. Is it from a camcorder, output from another program?
Mar 16 2016
Can you clarify what you mean by working/not working?
Can confirm it's now working. Thanks for the fix :)
Mar 14 2016
It looks like the original video might be missing frames. Converting the MKV directly with ffmpeg (2.8.4) cli gives some useful info - *lots* of PTS/DTS warnings:
After running through some test charts at various sizes, it looks like the horizontal resolution needs to be divisible by 32 to avoid any colour shift.
Mar 11 2016
Unfortunately the patch has introduced some weirdness with the CbCr up-scaling. See T47766
Mar 9 2016
if it helps track down the issue;