- User Since
- Feb 7 2019, 1:58 PM (84 w, 1 d)
Sun, Sep 6
You have the limit method set to none which means every edge will be beveled. Turn on wire frame mode to see it.
Jul 15 2020
Is there a way for a non-coder to diagnose this under Linux? I would like to help in any way I can.
Jul 11 2020
Jun 20 2020
I see it now, I was trying it on a mesh which has 90 degree intersections. Thank you for the clarification! In my mind I was thinking of another patch: D6386
Hi Howard, this might not be the right place to ask, but is there any difference between "Offset" and "Absolute"? Based on my initial test, (which maybe wrong) I don't see any visual difference between the two. Is there any specific case where one should use Offset over Absolute or vice-versa?
Jun 7 2020
Jun 6 2020
Should we make a separate bug report for this?
Jun 4 2020
I can't seem to get this to work on Ubuntu 20.04, with a dual monitor setup and two Main windows of the same blender instance.
May 25 2020
May 14 2020
I have to disagree. I'm not requesting for modified/improved behavior. Just swap the sockets. This is clearly an aesthetic/layout issue. An "error"
May 12 2020
May 11 2020
May 7 2020
May 6 2020
May 1 2020
Apr 30 2020
With the D7574 fix, I no longer have this issue.
Successful renders with both F12 and viewport! Simply genius! Thank you!
Can we also test on Ubuntu 20.04 LTS? I understand it's not currently supported by the driver, it's just so we have an apple-to-apple comparison.
Installing with dkms breaks my whole display stack, (Unable to login to desktop; black screen with blinking white underscore) which is understandable because neither Ubuntu 20.04 nor 19.10 is supported by the current driver, hence the --no-dkms
Apr 29 2020
$ /opt/amdgpu-pro/bin/clinfo | grep -i "driver version" Driver version: 3075.10 (PAL,LC)
Apr 21 2020
@Richard Antalik (ISS) I think the issue is exclusive to this particular setup, at least the GPU.
With the 2.90 builds (rB5cc7e2ae16d4) and an upgraded driver (amdgpu-pro-20.10-1048554-ubuntu-18.04) the render does not hang anymore for me, instead this happens now: T75895
Are you using the same GPU?
I've managed to recreate a scene that produces the crash on my system. Note that it's not specific to this material; any material I append or link from my external material library will produce a crash on render.
Apr 19 2020
Apr 7 2020
I'm using amdgpu-pro-19.50-967956-ubuntu-18.04
Apr 6 2020
Tried out latest master, issue still persists when building with USD.
Apr 5 2020
Mar 28 2020
Hi Brecht, is there anything else I could do to help at this point?
Mar 10 2020
I agree it's a bit weird since there are no cycles-specific files edited in that commit, but I don't get the error when building with the commit before that. Or earlier. I'm only having problems after that specific commit. So maybe git bisect was on to something and this is something that could be looked at.
Mar 3 2020
According to git bisect: ec62413f803ee506633f0e52d1e52b0980c0ed0d is the first bad commit.
Mar 2 2020
should I mark commits that fail with Split kernel error: failed to load kernel_path_init bad or just the ones that hangs? The last time I tried to bisect, I marked those as good, git wasn't able to find the right commit.
Is there anything I could do to help?
Feb 28 2020
It's working with 2.81, so there must be a problem with 2.83.
Feb 27 2020
This fixed the error. Thanks for the quick fix Brecht! However now the render hangs indefinitely, without the black info bar at the top (the one that says how many samples are done, etc.) The render simply does not start, I don't know what to give you because there's no error out of the terminal or anything.
Feb 26 2020
Fixed for me.
https://developer.blender.org/T74217 might be related. Recent build crashes when changing viewport shading to Material Preview or When render engine is set to Eevee, set viewport to Rendered View and under viewport shading properties, unchecking scene world crashes blender.
Feb 21 2020
Happened to me with recent builds. Quite the headache.
Jan 25 2020
I wish UI changes like this could be decided via a public poll, or at the very least, like everything else in blender - a customizable option. I liked the clear distinction between edit and object modes.
Jan 3 2020
Added more info; the collection to be linked also has linked materials.
Jan 2 2020
You should attach a log file instead of dumping the whole output here.
Dec 18 2019
Dec 15 2019
Dec 11 2019
Dec 10 2019
It seems the problem only occurs on a Wayland session. The continuous grab works flawlessly on a regular X session.
Nov 30 2019
Nov 19 2019
I've had a more stable experience passing AMD_DEBUG=nongg,nodma as environment variables and having iommu=pt pcie_aspm=off amdgpu.dc=1 amdgpu.gpu_recovery=1 as GRUB boot parameters. Some of the arguments might not be needed and I'm not sure which exactly does the job making it more stable, it might be any combination of these... Just updating in case someone else comes across this.
Nov 12 2019
Yes, currently I'm using the latest version in your link (19.30) with slight modifications to the deb files for it work with Ubuntu 19.10.
Nov 9 2019
Oct 28 2019
Oct 3 2019
Sep 25 2019
Sep 24 2019
@Philipp Oeser (lichtwerk) Yes, this is with Factory Settings.
@Jeroen Bakker (jbakker) I believe 19.0.8 is the latest for Ubuntu 19.04... Trying 19.3 using a PPA caused my Desktop to fall into a login loop.
No crash with --debug-gpu-force-workarounds too.
Sep 23 2019
Sep 11 2019
Issue is fixed for me with latest master. Perhaps it's something to do with all the recent bump-mapping related commits. Feel free to close this.
Sep 8 2019
Aug 22 2019
Thank you! That was fast!
Aug 20 2019
Aug 10 2019
This is weird. Could this be a driver problem then? I'm still having the same result on the release build and master. Let me know if I could provide more info to help identify the problem.
Aug 6 2019
Jun 1 2019
That maybe from a developer point of view, but for end users with no knowledge of the inner workings of Eevee nor OpenGL this seems counter-intuitive and confusing especially when one configuration works and the other doesn't despite it having a simpler configuration. With that said, of course any optimisation would be welcomed and greatly appreciated.
May 31 2019
May 29 2019
May 17 2019
Hi guys, just want to know if this is still being worked on? I would really like to jump on the 2.80 wagon, but the lack of unit display makes modelling really hard at the moment.
May 11 2019
Z scale is set to -1. Apply or clear scale, the modifier will work as expected.
Apr 25 2019
I have the same issue with build 19-04-25 (905f2d84af4d). N or T does not work even after loading factory settings or changing keymaps (default, 2.79 or industry compatible).
Mar 13 2019
Thank you for the clarification regarding unit scale, I come from an architectural background where specifying everything in mm is quite normal. Typing in 25 instead of 0.025 is faster and significantly less confusing. I mainly use 0.001 unit scale in 2.79, where that's the only option you have if one wants to use mm. I never imagined it would have an effect on precision.
Mar 12 2019
Forgive me if this sounds ignorant, but it just seems weird having to have separate settings on the same scene with a different unit scale. Am I right in thinking that the underlying problem here is that lights don't use the unit system yet as mentioned by Brecht? And this goes away once it does?
Mar 11 2019
This is a duplicate of T61286
Feb 10 2019
Thank you! Hopefully this will get accepted soon.
Feb 7 2019
Must enable units.