- User Since
- May 23 2014, 12:55 PM (237 w, 5 d)
Tue, Dec 11
I wasn't aware that I was/am the one to apply those proposals.
Anyway, I've search the source and came up with a possible fix, to discard the "themable width".
Since the console and text editor both have a themable cursor color, I kept it in as well for the edit cursor.
Mon, Dec 10
Hi.. Since you're opening up themable colors again (see https://developer.blender.org/D3949) I'd like to re-propose my patch..
I think you need to check your topology.. you've got overlapping faces.. That's how that looks like.. has nothing to do with this (fixed) bug as I see it
Fri, Nov 30
ok.. this is really getting on my nerves.. sorry that I freak out now, but it’s really just a throw of a dice with trying to inform you about a bug/feature/ui issue/papercut or whatever you think you call something.
then it’s a feature, then it’s a bug, always just the opposite of what I think it is..
Mon, Nov 26
As long as you agree that there needs to be a contrasty and hidpi friendly cursor, then I'm all for it ;-)
A bit "jammer" that there is no support for customization via theming, but hey.. in the end that doesn't matter.
I don't know your specific ages, but please bear in mind that not everything you see, is what others see.. I can't distinguish that cursor from the background because of it's color.. and secondarily it's width.
And yes, I'm on a 5k screen.
As I can change the background color, sooner or later the contrast is gone.. you can't theme one thing and leave out it's opposite.
It was a suggestion others would enjoy too.. on rightclick select it gained a couple of likes..
Thu, Nov 22
Wed, Nov 21
Here's a quick screencap showing the bug (on ubuntu linux)
Mon, Nov 19
Nov 12 2018
Checking for NULL on XDG_RUNTIME_DIR
As if there are people not using systemd ;-)
Nov 7 2018
Added BLI_filelist_free. (should have been in there from the start.. seems I forgot to copy/paste that line before, and never noticed it)
It solves the leak.
Nov 1 2018
It happens on both my own as well as the daily builds.
It goes away when I set my "screens have separate spaces" off so I did that in the meantime, but it's not the solution I know.
Oct 31 2018
As noted by Campbell, using STRPREFIX makes more sense.
Made the filtering a bit smarter/error proof.
Oct 30 2018
forgot to include the #include "BLI_fileops_types.h" this last diff.
Removed one check for existance of /run/user/xxx/gvfs folder
If it doesn't exist no real problem arises.
Benefit however is that when the network is down, it won't have to wait twice for a dir-exists and dir-contents
it seems that when disconnecting the network, the share entries won't go away and the os will keep trying to look for them when asking for the directory list until timeout.
This slows down blender startup while waiting for the timeout..
- Get environment variable pointing to the XDG Runtime folder
- Loop through the gvfs folder to find/add shares
Oct 28 2018
BTW.. I don't know if this qualifies as feature request, but when starting out with Linux years ago, I always found it difficult to find shares made by Nautilus/Files (UI) in Ubuntu and other distro's. A new user will have that same "where are they in Blender" question.
Maybe have them available too? The /run/user/<username>/gvfs folder I mean.
Oct 27 2018
Oct 8 2018
Oct 4 2018
Oct 1 2018
Am I right to assume that only the blender 2.8 branch got your (perfectly working ;-) patch?
I've incorporated your patch in the master branch myself (personal use) but shouldn't it be in there officially? Still use the 2.79 daily a lot of course.
You've fixed the most important part (the crash)
Is it on purpose that you did not fix the not showing text on curve before entering edit mode (because blender doesn't crash on it) or indeed forgot to read the original report?
Sep 30 2018
BTW, please also follow the first instructions, because the crash happens because the cursor key is not after the last character I THINK, but you would only see that better if you'd follow my original instructions, without the blend file
In all this time it would only have taken an average blender user maybe 10 seconds to follow my "crash" path..
Sep 25 2018
On request some screenshots..
Sep 23 2018
Sep 17 2018
Sep 3 2018
Aug 28 2018
Aug 7 2018
I think it's the same issue I have in sculpt mode.. I've tracked it down to commit d79df6c0
the changes to space_toolsystem_common.py got result in not being able to cycle through brush presets.
Commenting them out fixes that (for the time being)
Did not investigate source further. Maybe committer Campbell knows more ;-)
Aug 3 2018
Aug 2 2018
I've built blender 2a8413a0ddd
So far I can say it's a stable build regarding this issue!
Jul 29 2018
And here is a backtrace when runned through lldb
This is the version I'm using:
Jul 28 2018
Jul 23 2018
That's what you get when dealing with noobs ;-) Sorry..
Fairly Sure ;-)
on AMD Radeon R9 M395X 4096 MB (OSX iMac 5k) the proposed Viewport Samples and viewport quality "fixes" the issue.
However in Eevee Render Preview and enabled screen(space)_subsurface_scattering, viewport still acts up.
Jul 11 2018
Oct 27 2017
Aug 9 2017
I have the 'same' issue, except that the rendered tiles on GPU are completely black. No artifacts.
iMac 5k, 4Ghz Intel i7
AMD Radeon R9 M395X 4096Mb
Jul 26 2017
Thanks for your explanation.
There is a "but" of course ;-)
I do understand conversion radians/degrees and all that,
but the same goes for rotation as it does for translation. A user doesn't care how or what is being calculated under the hood.. he/she just sees an unexpected change in his input field.
That's going to raise bug reports for sure and to my mind, rightfully so.
So I would urge you in advance to try to overcome this 'faulty' display of rotation.
Jul 21 2017
When entering Rotation values higher than around 14.4, and reentering, those still get rounded with 6 decimals.
So entering 14.1 is ok, 14.2, 14.3 works fine.. but after that the rounding occurs..
I've checked several lower numbers.. couldn't repeat the issue there.. strange..
Also if I would enter a rotation value of 45 it would return 45.000001
Jul 15 2017
Jul 7 2017
Searched like crazy to pinpoint where it goes wrong.
My findings are that everything is calculated fine from the movie file (anim_movie.c->IMB_anim_get_duration)
and it shows correctly throughout blender interface and even when querying the loaded movie in console:
bpy.data.images[x].frame_duration returns the correct number
Only the node itself displays "1"
executing bpy.ops.image.match_movie_length() sets the correct value
Jul 6 2017
Jun 19 2017
May 22 2017
May 18 2017
The error is the same, but you're using the 2.78c release version, not a daily build after 24th of april.
2.78c release is working fine here, so maybe your card is not supported (anymore)
you can also try to cleanup all leftover kernels in ~/.cache/cycles/kernels.
For me that was no solution, but maybe for you it will.
May 16 2017
there is no such thing as updating drivers on OSX (except for Cuda, but that's not the issue here)
May 10 2017
May 9 2017
May 7 2017
Commited to contrib as "render_renderslot.py"
May 5 2017
Apr 25 2017
there is no file attached
Apr 24 2017
If you would press R (for rotate in the viewport) you'll see where your object is located.. far to the left.. pan there and you're good to go..
(btw do you know you have the viewport locked to that object?)
committed to contrib, closed as resolved
Apr 15 2017
I've made some intensive changes.. The naming of the versions has changed.
There were way too many ways to get mixups when having multiple similar named objects in the scene.
Blender does that .001, .002 naming of meshes when there's already a similar named object.
Object will be named: Plane
Mesh will be named: Plane
Object will be named: Plane
Mesh will be named: Plane.001
Apr 14 2017
I've found out that due to automatic naming of objects in Blender it can get messy.. independent of the addon.
Create Plane (it will have the name Plane)
Blender attaches a mesh with the name Plane
Delete te Plane
Create a Plane
This time the object is still named Plane, but the mesh will be named Plane.001
The addon uses bpy.data.meshes.remove(..mesh..) function and it is working without the need for purging? In the outliner the orphaned meshes disappear when removed with the addon.
I don't know when Blender team implemented this purging, maybe long time ago, but I was always under the impression that you cannot purge without save/reopen..
Anyhow.. so the outliner button purge all is not required I would think.
So the option "delete unwanted meshes" has been implemented now.. the code needs a better approach in disabling deletion of the last mesh..
At this time I'm just iterating the same loop twice to find out if there is only one 'linked/stored' mesh in the active object..
The added tooltips.. and mesh remove!
deleting unwanted mesh versions is something I've investigated.. but it's Blender that is not allowing it..
It's the same behaviour as discarding textures/materials.. they only really get purged when saving/re-opening the file.
But maybe I'm wrong..
Apr 11 2017
Feb 24 2017
Dec 5 2016
Sep 8 2016
Jul 8 2016
Jul 7 2016
May 12 2016
Sep 9 2015
Jun 30 2015
Jun 11 2015
Hate to be a drag.. but I really haven't got a clue what you're saying with increase max memory based on your system..
Blender has no options like that, that I'm aware of.. only Undo Buffers and VSE preload memory allocation..
Neither of the two have something to do with CUDA memory allocation to my knowledge..
On .29 I got screen corruption without much trouble... after an update back to .36 (and reboot)
I gave it a large scene to chew on.. and almost immediate corruption: