This is a temporary project to help the develoment team to keep track of the backlog of reports that need to be re-triaged during the Tracker Curfew.
May 18 2021
Managing fonts on Linux it's a nightmare... you are a life saver! I mean it! thanks D:
May 7 2021
May 1 2021
This Ctrl + RMB conflict with other software in my laptop.
When I close those software. Stroke/Curve work fine.
I can not use this Stroke/ Curve in Blender 2.92
When I hold Ctrl + RMB, not thing happen.
Mar 15 2021
No, that information is false. It has been addressed already.
With that kind of brush setup, Blender will often not draw a pixel, or draw two/three at once, or draw the pixels slightly less opaque than they should be. There is no sweet spot that acts like an actual pixel perfect brush.
You can find solution here
Feb 22 2021
Hello, i want to subscribe to this issue because yeah it should definitely need to fix... with 1px radius, no AA, constant falloff brush paint chunks of 2/3/4 pixels, and for pixel art this is not good. Workaround at the moment exists, like addons, downscaling, or use external editors like Krita or Aseprite, but this should be a normal in blender too working on a single pixel, i think this issue don't need to have a low severity even if is not a breaking bug, but should gave more attention to fix in the upcoming releases, thanks dev for all the efforts!
Jan 13 2021
No, drawing at a radius of 1 with constant falloff and no anti-aliasing will leave you with dots that look like this:
On top of that, drawing is insanely laggy in Blender 2.91 for some reason. It must be some kind of regression. I didn't look into it.
So, it's currently either back to 2.80 (like the person in your video), or no pixel-perfect painting at all.
For anyone waiting, couldn't you get by painting at 2x2 pixels and scaling down by half when done? https://youtu.be/RQVAUaSUP-k?t=1075 might help too.
Jan 9 2021
Hey developers. I know there's no point in telling you this, because you're busy enough as it is, and there's already a schedule for everything -- but several months have now passed, and I feel compelled to remind you that this is not a minor issue, and there are people out there literally counting the days until you resolve it.
Fingers crossed for Blender 3.0. Blender should be the go-to software for all things low poly / PSX style. Please allow pixel artists to finally make the switch from 18-months-old Blender 2.80 to the latest release. That would be great. Best of luck.
Jan 5 2021
Nov 24 2020
Oct 14 2020
I'm also dying to see this get fixed. I am thinking about this literally every single day at work.
Had to put two game projects completely on hold because of this issue caused by Pablo Dobarro's subpixel drawing feature.
But why 2.79 is drawing 1 pixel with 1px radius brush then?
Any news on this?
Oct 10 2020
@Martin Capitanio (capnm)
Also, is there way to donate to you? This addon is very useful, not gonna lie.
Oct 9 2020
Link is dead. Can you up it, or should I?
Addon still work with latest builds.
Sep 1 2020
This is fixed if one uses the new Exact mode. commit rB9e09b5c418c0
Jul 15 2020
It's works properly at last after multiple times trying it and fail , I'm using Linux Mint 19 XFCE , and the addon uses one of the system shortcut ( Ctrl + F1 ) , I was have to disable that shortcut from my OS system setting
I wish this addon-on developers keep this on their mind , or even make it works immediately after enable it without need for any shortcut .
Jun 17 2020
@Germano Cavalcante (mano-wii) can you reopen this task as low priority? The one that it has been marked a duplicate of is fixed, but this issue persists nevertheless.
Jun 5 2020
From what I can see in the comments, this was closed because it works as intended.
Apparently the smallest possible brush diameter is currently 2px (1px radius).
D6209 seems to be a proposal to resolve this limitation.
Jun 4 2020
I guess if this wasn't resolved like it was expected, at the very least it should be re-opened so a developer can comment again. Messaging was also a bit confusing to me, with "it's working as expected" and "it will be fixed" in the same comment. To me this also seems like a regression, so shouldn't it be a high priority issue?
I was hoping that 2.83 would fix the 1px problem for us that love to paint pixel textures :(
Jun 2 2020
Size is diameter. No confusion intended.
Did this get solved?
Will we be able to paint 1px again?
And why not use size like all other artistc programs out there insted of diameter?
May 18 2020
May 16 2020
@Rasheed mh (alfanak) reading the comments of Brendon Murphy, it seems after incorporating his suggestions, you may submit it, following the guidelines at https://wiki.blender.org/wiki/Process/Addons.
If somehow that is not suitable, https://devtalk.blender.org/c/other-topics/python/6 can be used to collect feedback, and respond to the users.
Not working bro, still same
May 15 2020
@Sebastian Parborg (zeddb) okay, thank you very much for understanding.
Such option will make this kind of baking easier and can reduce artifacts in other cases.
As you can see, I`ve got proper result by adding lot of new geometry and making Donor clozed.
May 14 2020
Posted a potential fix here: https://developer.blender.org/D7733
@Joe Elliott (thegryphonrider) that setting does not limit the ray distance of the rays. It simply seems to offset the starting location of the ray in question.
@Sebastian Parborg (zeddb) Is it necessary to add a new "max ray distance" variable? There's already a "Ray Distance" variable in the Bake panel; isn't this what that's supposed to be for?
Ok, I think I can simply add a "max ray distance" variable.
I already looked at the code and it should be hard at all.
What you are suggesting (ray-length limit) could be implemented as a new feature. I wouldn't mind accepting such a patch.
In my opinion baking ray should be terminated not only by impact with Donor, but by impact with Recipient too or after passing ray-length.
Here scheme in 3d.
Any objections, that it shouldn`t?
@Dalai Felinto (dfelinto) I'll try to bake it properly or imitate proper bake.
if it works as intended, the algorytm is not full by design.
It have only elevation of ray-start above surface, but do not have ray length from elevation point to surface, that shouldn` be infinite anyway.
Hi @Andy Davies (metalliandy) could you lend me a hand here? I think baking is working as expected in this case, but I could hear your 2 cents on it.