NinthDesertDude

Ah yeah, I noticed that just after publishing earlier today. Sometimes I forget to increment the version number. I'll probably increment it shortly, but I won't bump the thread again for it. (It's still the newer one right now, whether the version is lying to you or not 😛) (Also, thanks @toe_head2001for pointing out the versions are tied to Visual Studio 2022. It was recent enough that I wasn't up-to-date, and it was that simple.)

Version 3.1 released This is a minor update that comes out of @BobGrey's comments. Thanks. Smoothing: Jagged is no longer treated as a fast/lower resolution draw mode, but as a mode that guarantees aliasing by forcing every pixel to be fully opaque or transparent (well, as opaque as the brush transparency setting if that's in use). Either way, hard edges as they should be. It will make any brush in use hard-edged. Note that brushes that are mostly transparent will probably end up fully transparent while drawing, but then most of those are dedicated to painterly styles, not pixel art styles anyway. Basically, I wanted Jagged smoothing to serve pixel art better. No other way, unfortunately. Plugins like this can only access the active layer, so until that changes, we're stuck with clipboard copy tricks at best

can't you run the intensive code in a BackgroundWorker or fiddle around with Tasks?

@BobGrey This was it. That's because brushes of 1000+ pixels in width or height get resized on being loaded to a max of 1000 pixels, since that's the largest size brush you can draw with at the moment in the plugin. So the problem is that the resize logic when loading a brush, if it's large, doesn't account for jaggedness on resize and just applies antialiasing. That's a bug, thanks for identifying. Meanwhile, reduce the width by 8 pixels so it's 999 total and it will work (tested).

Can you share the test image you used as a brush? Then I could iron out what's wrong or fix it in the program if it's a problem One thing that comes to mind is if the brush is large or loaded from a photoshop .abr file, it might be getting resized when it first loads. Sharing the pic will let me know for sure. Thanks for the feedback.

Worked for me last night. Open paint.net, press Ctrl+A and delete. Switch to the pencil tool, draw anything. Crop. Save. Open DynamicDraw, click Add Brush Images. Locate the saved file wherever you put it. It will be free of antialiasing as long as smoothing mode is jagged (which is default). Rotation will not be free of antialiasing at the moment. This is true. I'm not sure what you're getting at; maybe you're thinking pressure = hard edge? It wouldn't be the case if so.

If it was, paint.net's DLLs are not up-to-date with 6.0.3 yet, because the complaint is regarding PaintDotNet.Effects and PaintDotNet.Core

Thoughts for speed... 1. Parallelize the for loops in your pre-render if you can. It's worth tracking two copies of xx/yy and each intermediate variable you defined outside the for-loops, if that's necessary to make it work. Speed will definitely improve if it's at all possible. 2. func_v gets called all the time. If replacing the trig functions with dummy code like return v; or return v + 1; gives you a useful speed boost, you should look into building a dynamic table of values, because that means the trig functions are bottlenecking your speed somewhat. The table works like this: when func_v is called, if the input is a key in the table, retrieve its value. If not, perform the computation and store the result using the input as the key and result as the value. What this does is allow repetitive input to skip the computation, since you can just retrieve the previously-calculated answer. To make this possible, you'll want to start passing in xx % 2pi and yy % 2pi so that the domain is always within 0 to 2pi, or you'll hardly see repetition in the domain (modulo doesn't actually work with floats like 2pi, but you can try other ways of keeping them to the smallest factor that produces the same results in func_v). If that's not enough, you can hazard rounding the input values when you first get them to 3 or 2 decimal points -- this will make it an imperfect calculation, but probably the results won't be too different that it won't matter. You can experiment with this fuzziness if it helps you get the program faster. But please verify that the trig calls are really a slowdown to speed first.

I'm having some trouble re-compiling the plugin to test changes today...it looks like there is a live issue upstream from Microsoft borking over the dependency version of System.Windows.Forms, causing it to complain about inconsistent targeting between version 6.0.0 and 6.0.2. There are two listed solutions and neither of them work for me. I'm going to turn off automatic updates for paint.net and start backing up entire copies of it; there's been 3 different times in the last year that something important broke and blocked my workflow with DynamicDraw.

Please read the highly detailed instructions: https://github.com/NinthDesertDude/Dynamic-Draw/wiki/How-to-Use-Dynamic-Draw They are comprehensive, and definitely English-first, so that should answer all future questions you have.

He fixed it already (bottom of the same comment he wrote) I'm testing to see what handles aliasing correctly. Size change, yes. Canvas rotation, yes. Actual brush rotation, no Note that all the default brushes are antialiased. You can make a very quick black brush on a transparent canvas and import that, then you should be good to go at least for regular drawing with pressure sensitivity (if it works for you anyway). I might update this in a second to fix rotation w/ aliasing so that it rotates aliased, if it doesn't look too awful. Hang tight

Can't combine those pics in any simple way to get back the image data of light passing through the cloth w/o bracelets, because that's not in either image. It must be manually faked in. Or just retake the shot If you fake it in, it's mostly going to be clone stamp you use. Blurring and light adjustments could crop up

Fixed it just now if you remove the existing version and then download it again from the same place.

Any plugin in paint.net has limitations for what it does with brushes, and there's only 2 that use brushes. They open on an external canvas, don't support layers or much of the other things photoshop is good for, and I'd honestly recommend just going back to get it to work in Photoshop. If you have trouble with the .ABR brush files given, it's either a simple installation issue or the ABR files are bad. Photoshop has gone through a lot of versions and they might be too old. But Photoshop has such a huge economy around it you should be able to find plenty of free crack and crackle brushes online. Here's some photoshop help for installing brushes https://www.howtogeek.com/663111/how-to-install-brushes-in-photoshop/, hope that works.

Null54 merged the code to load photoshop brushes directly into dynamic draw, so no need to convert them. Handling is limited because of the No need for a plugin to load photoshop brushes directly into dynamic draw. Null54 added the code that handles loading them. It's limited since the photoshop brush file format isn't posted & all support that exists today is just cobbled together by guesses from smarter people than me. I think that picture is hand-done, the way it follows contours and preserves focus areas with large spacing. No other way but to recreate it manually. I'll make another post if I can figure out a way to recreate it with some voronoi textures and a bit of hand-work. Still a lot of work in any program, I'm guessing

k.

User color is taken only on the first time running the plugin. All subsequent runs use the color that was last set from the previous time the plugin ran. Color management / palette work is high on the list of things to improve. 1. Yep, agreed. It's silly. The plugin was much more experimental when I wrote the feature than it should be anymore. Shifting should also be set between a range. On the list to do. 2. Depends on which thing is shifting, all of those are intentional, but when shifting is rewritten, you'll be able to set the edge behavior. Thanks for the feedback

Oh, some kind of uncaught error with the wintab interface. I'll take a look later, thanks

Ah, cool. Opened a github issue

I found a few especially useful filters here, so thanks for making this plugin. It would be nice if it didn't recalculate the plugin when panning the image, right-clicking things in the list, opening after having used the plugin once before, or left-clicking the same filter in the list that's already selected. Basically, if the filter was only run when altering settings or switching filters.

When I paste images from the clipboard to paint.net, I usually get up to 3 pastes before it starts giving me an access denied error. I haven't been installing anything lately so I'm not sure it's an environment issue, but I wouldn't be surprised if nobody else repros this. The images I'm pasting are about monitor size 1920x1080 or so, nothing small or huge. Here's the exception:

Is the WintabDN.dll file present in the DynamicDraw folder?

the colorspace information is probably in the metadata if it's not sRGB, so could this have been a bug in paint.net for a less-used format? It might be useful to know for sure. And know what the format was to see if: - that format is supported by paint.net - the issue reproduces with that format because in that case this could be a useful repro we can't usually see. Just my 2 cents

Third the request. This is the bullet I can't bite on my own with Dynamic Draw. Being able to read the layers so I can make a quick merged copy would remove so much jankiness. ...I don't suppose writing to other layers will happen (that would be asking for the moon, since effects run against a single layer) but if it could...that would really remove the last barrier

I'm not sure what this means. Is it something I can fix?