- User Since
- Apr 30 2013, 9:57 AM (409 w, 2 d)
Mon, Feb 15
Fri, Feb 12
Thank you for the explanation.
Hello, just for my curiosity, isn't Blender 2.92 as well as 2.93 based on Python 3.7.7? Why are you compiling for Python 10, not yet officially supported for the Blender development? I read there are plans to move to Python 3.9 but that's all I know about. I repeat it, just for my curiosity. Thank you.
Wed, Feb 10
Fri, Feb 5
Wed, Feb 3
Sorry, but version 2.90.1 has reached end-of-life and the currently supported version is 2.91.2. Please, download the latter and verify if the issue is still there: https://www.blender.org/download/
Feb 2 2021
Hi Paul, I simply verified that your issue was replicable with and without your sample files. At this point it's better to leave this into the good hands of the developers for further investigations.
Feb 1 2021
Jan 27 2021
Thanks for the report, but this add-on is not developed by Blender, please report the bug to the original author.
Jan 20 2021
How is it that the versioning has switched directly to 2.91.2? This version numbering is both in the file names (https://download.blender.org/release/Blender2.91/) and in Blender itself (as shown in the splash screen). Probably, this was intentional but, just in case, I let you notice it. Thanks.
Dec 21 2020
I confirm that after applying the above mentioned correction, changing from dummy.select to dummy.select_get(), the add-on works perfectly in Blender versions 2.83.10, 2.91.0 and 2.92.0(alpha). Thank you.
Dec 16 2020
This is not a bug. Some zipped add-ons are not properly set for direct installation from the zip file. If the add-on is just a single xxxx.py file, it should be packed singularly. In the contrary, if it is made of more that a single python script, these should be placed inside a dedicated folder, and the main script should be named
(with two underscores before and after init).
If you check the content of the zip file you attached, the "singular file script" is placed inside a folder but there is no "init__.py" and Blender don't know how to handle it after you install it. You have two solutions: 1) extract the single xxxx.py file somewhere, then run the installation procedure in Blender, choosing this single python script; 2) go to your add-ons folder and look for the CircularArray-master directory that has been created when you installed the add-on; inside it you will find the CircularArray.py script, rename it to init__.py. These steps should solve your problem.
Dec 10 2020
Dec 3 2020
This is perfectly normal and not a bug. You have to add both a Domain and a Smoke Emitter object. If you want to test the smoke effect you can use the Quick Effects option available from the Object menu, after adding and selecting the smoke emitter object in your scene.
Nov 30 2020
Oct 30 2020
Oct 29 2020
So, is this really a "bug"? Anyway, I do agree with you that a check for validation, and a proper warning message displayed to the user, would be a more user friendly behaviour for the add-on.
The issue is that you shouldn't change topology of the mesh deleting single vertices. If you, instead, delete an entire row of vertices, it works when you click on Landscape Eroder. This applies to all current versions: 2.83.8, 2.90.1, 2.91.0, and 2.92.0.
Hello. Here on
Please, write a proper bug report explaining what's wrong, provide required information, and step by step instruction on how to reproduce the problem, to the developers. Please, watch this video instructions by Pablo Vazquez: https://www.youtube.com/watch?v=JTD0OJq_rF4
Oct 27 2020
Oct 18 2020
Jul 31 2020
Possibly because if that path is pointing to a different drive than the one where Blender is installed, you cannot use relative paths but only absolute.
Jul 23 2020
Jul 10 2020
Wow! "Bug" fixed in 14 minutes. You're amazing. Grazie!
Jul 3 2020
Jun 23 2020
Jun 21 2020
Jun 19 2020
Jun 18 2020
The above behaviour happens also on Windows 10, and I can confirm that the second time you try to activate the add-on the \matlib folder is created again and everything go on smoothly.
When the add-on is activated in the Preferences, and if you haven't previously set a path in the add-on's preferences, a new folder will be created inside the Blender's root installation directory, named \matlib, and new libraries will be added there. That might be a reason for the user not being able to create a new library, because probably he has no rights to do it. The user should try to set a path for the materials folder outside of the Windows programs directory and check if he has rights to write inside it. The following is a screenshot from my portable 2.83LTS version where as soon as I activated the add-on the folder \matlib was created and new libraries are stored there.
I was reviewing this bug ticket and noticed that:
Jun 17 2020
I confirm the above mentioned behaviour in 2.90 here on
Jun 16 2020
Yes @Leroy (Leroy), the last images I published were taken from the 3D Viewport, not a render.
I did a clean install (portable) of version 2.83.0 stable, vanilla, no external add-ons (just in case they might interfere), and I confirm that here the issue raises in the 3D Viewport with Standard (formerly, sRGB) setup for Color Management's View Transform, as per screenshots below:
Please check that Filmic is set correctly in the Color Management section of the Render Properties. To me they appear to work fine both in Eevee and Cycles, both in 2.82a and 2.83.0. I can get your second image's result only if I set the Color Management to sRGB. Hope this helps.
Jun 14 2020
I can confirm the issue.
Jun 4 2020
Jun 3 2020
May 27 2020
Apr 14 2020
I've tested Blender 2.82a official release on Windows 10 64bit (portable version), which is installed out of the Windows control on a separate hard disk drive, and I've been able to create a new library (see the new .blend file inside the add-on's folder in the screenshot below), to add/remove materials, categories and assign categories to materials. So, might your problem be caused by insufficient user rights on the Blender installation folder (and therefore the add-ons folders)? Try to use a portable version and unpack it outside of the Windows Programs directory.
Mar 14 2020
Feb 7 2020
Feb 3 2020
Nov 27 2019
Nov 12 2019
Nov 6 2019
Please follow the submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Sep 26 2019
Here on :
Sep 12 2019
Sep 6 2019
Great! Thank you. ?
Sep 5 2019
This issue seems related to T67111. Perhaps they could be merged.
Aug 1 2019
So, this is not a bug therefore this ticket could be closed.
Jul 23 2019
Hi @Brendon Murphy (meta-androcto), I went through the samples_scene.py, trying to fix the errors and commented the original lines, and now it seems to work in the latest RC2. Here is the modified script, hope it helps.
Jul 22 2019
Thank you Federico for testing it on Windows too. So it's confirmed. Do you think it can be fixed? This is a crucial add-on but in this state it's not only useless but also dangerous if your are not aware of how it messes up with the paths in the edited linked file.
Jul 19 2019
This seems an easy thing to fix, replacing the scene.render.layers with scene.render.views as follows:
Jul 17 2019
Unfortunately, with such scenario, it seems that even with the previous version 2.79b, when you edit the linked object using the Edit Linked Object add-on (ver. 0.8.1), and then return to the start file, it doesn't apply the correct relative path to the just edited file breaking links to external assets.
I can confirm the above issue on a daily build of version 2.80 (Hash: 65168825e0b0) on my laptop (Win10 64bit, GeForce 1070). The add-on seems to loose the correct relative path to the linked material, after editing the linked object, apart from other minor issues (see below):
Jul 12 2019
Tested on my laptop (Win 10 Pro 64bit, Nvidia GTX 1070) with the RC1 (but the issue below was there even before the release candidate) and, despite the add-on activates and works apparently, the following is the error message in the console just after add-on activation and continuously running on the console:
Jul 11 2019
I tested that scene file on my laptop and it renders fine. The memory consumption is about 20GB of RAM and 10GB of VRAM during the scene's rendering with tiles at 64x64, on a Windows 10 Pro 64bit OS, with Nvidia GeForce GTX 1070 (8GB VRAM), and Blender 2.80 (Hash: 12ceea04344a, 10/07/2019).
Jun 30 2019
May 22 2019
I've just tested the same exact build on my Win10 notebook and I am not able to reproduce that problem.
Apr 10 2019
Yes, in fact it can be found inside ..\2.79\python\lib\site-packages\requests\packages but you cannot import directly the urllib3 module. Instead it can be imported as a variable:
Feb 14 2019
Nov 30 2018
Jul 3 2018
Jun 20 2018
After further research I found this article: Preventing Cycles Crash after CUDA timeout
I started experiencing such an issue after I updated one week ago my Win10 Pro 64bit OS from Build 1511 to 1803 on an ASUS G752VS notebook (NVIDIA GeForce 1070), and then I updated the Nvidia Graphics drivers to the latest version. Reinstalling the graphics drivers (398.11) with a clean install didn't fix the issue. The error appears randomly when switching the 3D View to Rendered mode; closing and restarting blender and re-opening the same .blend project file sometimes it allows the GPU to render without errors.
The Blender version is 2.79b 64bit official portable release; the same issue appears on the latest buildbot releases 2.79.4.
The following are screenshots of the issue appearing after switching the 3D View to Rendered mode inboth Blender 2.79b and 2.79.4:
In the latter screenshot I first did a full render successfully then I tried to switch the 3D View to Rendered and the error was triggered. Hope this helps.
Jun 2 2018
Did you try to run Blender with its default settings? If that way it works, then you might try enabling one add-on at a time to discover which one could be the cause of the issue. You may also run Blender in debug mode and watch the Blender's console messages for clues. The last warning message is easy to fix in the preferences.
Feb 1 2018
I confirm that the source of the issue is in the Clip Start value, which was set at 1mm. I will take it in consideration for the future, and from my side you can close this ticket and better spend developers' valuable time. Thank you for addressing me to the source of the problem.
Dec 6 2017
Ooops, you're perfectly right, sorry. I will pay more attention in the future. Lesson learned. Thanks. :-)
Dec 5 2017
Sybren, I simply replied to the questions, perhaps in a little too much verbose way. Anyway, the currently available developmental 64bit versions (hash: 1802d14) both experimental (VC14) and not-experimental work fine. Thanks.
Sybren, I usually download the development builds from the official repository (https://builder.blender.org/download/) and only Experimental Build Branch by VS 2015 (Windows Vista/7/8/10) version. I do not install Blender and instead I create a close controlled environment for each portable version I use.
Nov 27 2017
Nov 11 2017
Here on Win10 64bit + Blender 2.79.1 (Hash: a466d7a) 64bit portable the Amaranth Toolset add-on is working fine. Thank you for the fix.
Nov 9 2017
I can confirm the same issue here on Win10Pro 64bit and Blender 2.79 official portable 64bit.
Oct 30 2017
The information about this add-on on the Wiki page https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Paint/Palettes is outdated and still referencing version 0.9 and Blender 2.58 while current version is 0.9.2 and Blender 2.63. Thank you.
Oct 27 2017
As per the R(0°) formula the "sqr" term should stand for or should be read as "to the power of 2" or "squared" not as "square root of":
Sep 20 2017
I can confirm that in 2.79 official release 64bit that's is the behaviour. In Edit Mode you cannot hide the object currently being edited but you can hide other objects in the scene while you're in Edit Mode. It was the same in 2.78 and previous versions.
Sep 6 2017
Gotcha! Thank you very much Brecht.
Sorry, I missed those changes because that is the release notes for 2.8, but what about 2.79 (https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Cycles)? Will these options still be available? Thanks.
Aug 30 2017
Perhaps the "issue" raised by the user is due to the Glossy Indirect pass which if the Filter Glossy parameter is set higher that 1 will blur the glossy reflections, giving the impression that they are missing. Here are some examples and the .blend file created for this tests.
Aug 29 2017
Here on Win10 Pro 64bit (build 1511) portable, and Blender 2.79RC2, the reflections work correctly with zero roughness as you can see below:
Jul 27 2017
Thanks for your efforts. From several years I use this script named Link_Sky_to_Sun_Lamp.py by Oscurart and Greg Zaal: https://www.dropbox.com/s/wap2jimkud5dntv/link_sky_with_sun.py
Jun 21 2017
Thank you Bastien for the clue about where the issue might be coming from. Regards.
Jun 16 2017
May 25 2017
Hello. I did some tests and found that it got broken with the 2.7x series while it was working with previous 2.6x versions. Hope it helps.
Apr 12 2017
Hi Andrea, the hair rendering settings have been moved inside the Geometry options in the Render panel: