Managing fonts on Linux it's a nightmare... you are a life saver! I mean it! thanks D:

Hi
Updated
This Ctrl + RMB conflict with other software in my laptop.
When I close those software. Stroke/Curve work fine.

Hi
I can not use this Stroke/ Curve in Blender 2.92
When I hold Ctrl + RMB, not thing happen.

In T71403#1129659, @Peter (peter_hutsul) wrote:

You can find solution here
https://blender.stackexchange.com/questions/198544/how-to-texture-paint-individual-pixels

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
https://blender.stackexchange.com/questions/198544/how-to-texture-paint-individual-pixels

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!

@Cam (Ortho_Cam)
No, drawing at a radius of 1 with constant falloff and no anti-aliasing will leave you with dots that look like this:

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.

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.

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.

In T71403#837239, @Pablo Dobarro (pablodp606) wrote:

The current implementation is correct. A 1px radius is 2px diameter, so it paints two pixels at the same time.

But why 2.79 is drawing 1 pixel with 1px radius brush then?

Any news on this?

@Martin Capitanio (capnm)
Also, is there way to donate to you? This addon is very useful, not gonna lie.

@Martin Capitanio (capnm)

https://github.com/capnm/b8RollViewport

Link is dead. Can you up it, or should I?
Addon still work with latest builds.

This is fixed if one uses the new Exact mode. commit rB9e09b5c418c0

In T62011#979313, @Salem F (SalemF) wrote:

...or even make it works immediately after enable it without need for any shortcut .

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

@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.

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.

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 :(

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?

In T62011#932853, @Ankit Meel (ankitm) wrote:

@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.

In T62011#932842, @Mahmoud Elhosary (elhosary89) wrote:

Not working bro, still same

@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

@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.

In T62422#931563, @Sebastian Parborg (zeddb) wrote:

@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.

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.

In T62011#930231, @Mahmoud Elhosary (elhosary89) wrote:

In T62011#930007, @Rasheed mh (alfanak) wrote:

In T62011#929944, @Rasheed mh (alfanak) wrote:

I mean the same font file you are using, from your computer

Never mind, i think i found what i was looking for.
The font missing the isolated shape of every glyph, which is weird.
It's easy to fix this but i don't know if i can do this here since this task is closed.

In T62011#929944, @Rasheed mh (alfanak) wrote:

I mean the same font file you are using, from your computer

In T62011#929944, @Rasheed mh (alfanak) wrote:

I mean the same font file you are using, from your computer