- User Since
- Mar 9 2013, 1:23 PM (382 w, 4 d)
Mar 6 2020
Jan 28 2020
Thanks Lukas for implementing the feature! <3
Here is the devtalk thread for why this is a nice little thing to have:
Nov 2 2019
Oct 13 2019
Sep 28 2019
Sep 24 2019
If it is working as intended/designed, then i would reconsider the design.
Because right now when changing the "width type", it resets the "width" value, as percentage and the offset values are not compatible.
One is done in a 0-100% range the other uses a integer from 0-1.
The usual offset bevel is the preferred one as the percentage will not create even bevels you need most of the time.
Sep 7 2019
Can confirm, that with percentage it does work.
Thank you for the quick reply.
Sep 6 2019
May 27 2019
I took two screenshots of how it looks like.
Maybe it is helping.
I can confirm the issue in a different blend file.
This issue appears when toggling "maximize area" (ctrl+spacebar) or as described above while toggling edit/object mode.
It is not 100% reproducible in a few simple steps, but i can always reproduce it with trying a few times the above mentioned cases.
A clean fresh blend file doesnt appear to display these issues, i can not share the work file for NDA reasons.
Apr 4 2019
Jan 6 2017
Could reproduce the issue with a new blendfile and blender units setup. Domain has to be moved to -5700/-1300/-800 to get the same result.
Mar 31 2016
Aug 7 2015
"u f enter" works, but is way slower to type than "u f o", therefore i do not use this combination.
My "u f o" is gone and i would like to have it back ;)
Aug 6 2015
May 19 2015
Mar 25 2014
Thank you for your fast workaround, helped a lot! :)
Mar 24 2014
Similiar slow down as i experienced?
Jan 9 2014
Thank you very much Brecht, you are awesome :) Keep it up!
And thanks for the showcase Metalliandy ;)
Jan 5 2014
Could not reproduce with the official 2.69 r60995 win64bit build. Adding a text object and dupicating it immediately afterwards does not cause a crash.
Seems to be a newer bug then.
Jan 4 2014