- User Since
- Sep 22 2010, 1:49 PM (460 w, 5 d)
Jun 15 2019
May 26 2019
May 21 2019
May 15 2019
well, if I try to click on the socket circle to pull out a connection/noodle to another node, it is not possible, because I cannot access the socket by clicking. Instead the whole node or the whole frame will be grabbed and moved.
If I delete the layout frame behind that node, everything works well.
I didn't say that 2.7 is affected. It's just the usual report line which was generated automatically by Blender when clicking the report bug menu... as bracht said.
I would raise the status to high, because all framed nodes are not accessible for people having the same issue since this version.
seems to be some change in the node behaviour.
The node setting is quite complex. When I change my complex setting to a normal principled BSDF then no artifacts anymore.
Have to investigate in this a few more minutes.
Meanwhile changed status to resolved and will write another ticket if I find the culprit.
May 14 2019
May 12 2019
Mar 30 2019
I can second this behaviour. UVMap node does work, but Texture Coordinates Node lets Blender crash.
It's not possible to work with materials as said before.
Show stopper ;-) unfortunately
Seems to work know.
Thanks to ...??
Jan 4 2019
Some more examination brings the following result:
depending on the armature's mode after deformation, the effect occurs or not.
Jan 1 2019
Funny thing is, I can get back the regular mesh, if I am in pose mode and choose another bone or just type R and ESC...
Why should a graphic driver react on the latter one?
I tried the official builds (beta from https://builder.blender.org/download/) - same behaviour.
Build blender as Debug build - same behaviour, no warnings/errors during run with "blender -d".
I changed to the loaded factory settings with a fresh config directory to reproduce the buggy behaviour, no other addons are installed know.
Same as before.
How to build a debug build? Didn't do that before?
Specifying it a little bit. Open the bendyBonesBug.blend file. Change the rotation of one of the bendy bones to deform the mesh.
Select the mesh.
Then switching off and on the armature modifier results into the reproducable buggy behaviour... strange
I tried the build from today and my own compilation with a fresh git pull.
The bug still stays (see attached image) after switching off and on the armature modifier i.e.
May 31 2018
I changed the render samples to 1 and render size to 50% to speed up things.
I started rendering. System memory consumption raises to >16GB after short time with blender displays memory usage around 70MB.
I can confirm Lukas' observation. I used blender-2.80-fbd614f1faf-linux-glibc219-x86_64 on a Debian stable system with a GTX1060.
Seems as if the jmalloc problem is here again??
Mar 13 2018
@Brecht Van Lommel (brecht) also for me: "MALLOC_CONF="dirty_decay_ms:0" blender" works fine.
No cumulation of allocated memory on system monitor/blender monitor. Memory is freed after rendering, loading new scene.
Seems to work fine with that env variable setting.
Mar 12 2018
LazyDodo, thanks for trying.
IMO it's not scene related, because it does work normally with 2.79.
The build is from blender.org and I am not using Ubuntu but Debian stable. Since the 2.79a release I never had any problems like this one.
Hash is: 8928d99270f (as of 2018-02-21 10:41)
Sorry to bother you again, but the problems seems NOT to be solved.
Again: Blender shows normal memory usage in the header information, but my system doesn't.
This is strange and appears to happen
.. with or without addons enabled,
.. with or without GPU rendering,
.. independent from starting rendering with Shift-Z, F12
Mar 10 2018
Thanks for the answer. But the hint looking at the Blender memory and the system memory usage gave the solution.
The guilty was not Blender but a system update without starting the system (which normally is not a problem if there is no kernel update).
I watched the Blender memory usage - it was ok. The system usage wasn't.
Restarted, tested... everything works fine - thanks for the fast reply.
The show can go on now :-)