❀ DoN's Dynamic Mesh Effects ❀

[VSZ]

Unlike the sample project painting a lava material, that happens after the Render Targets so we couldn't have unlimited dynamic textures. If I'm wrong and this is already possible, please correct me!!

Yes, for blending in an unlimited number of texture as you describe we'd need a setup where the BP paint node takes in a texture parameter per-stroke for the render brush to apply.

Right now there's some features requested by other users off the forums to consider too, so will have to prioritize these and see how many features can actually make it into the next build. Will post a summary of that down the line!

[DanimalsOnParade]

Right now there's some features requested by other users off the forums to consider too, so will have to prioritize these and see how many features can actually make it into the next build. Will post a summary of that down the line!

That's fair! I have my fingers crossed at least for having the second opaque RenderTarget added in with the capability to paint directly to it for things like an eraser brush to paint erase decals and text per layer.

[Crushy]

Just a quick suggestion, have you considered releasing an executable for the sample projects? I'm currently debating if I should get your plugin or continue working on my own approach for performance reasons. I imagine others would also enjoy the convenience of just fiddling themselves and see what the plugin is capable of doing.

[DanimalsOnParade]

How would I go about adding one of the paint layers into a brush material used by the paint functions? I'm trying to do some creative masking based on something created on another paint layer.

I duplicated the existing paint brush material and added the Don_Mesh_Paint_UV0_Layer7 node to it, but that node doesn't seem to update based on what's actually added to that render target (I can confirm that the render target is changing by painting it out onto a mesh). I get the feeling that instead I need to pass the render target in as a Texture Object Parameter in DonMeshPainterComponent with the rest of the "common parameters", but I don't know how to get a reference to that render target in that bit of DonMeshPainterComponent.

Visual example - Same paint brush material except I inserted a render target into it at the end:


Any ideas?

[VSZ]

^ @DanimalsOnParade - This is somewhat related to your recent feature request. Layer nodes can't be used inside the render brush because of context: layers reside inside a dynamic material on a per-mesh basis, while a render brush is a standalone utility material (used to render a stroke).

It is possible to magically wire a layer node in a render brush to the actual layers of the mesh being painted, but can you clarify the need for this?

With this setup there are complications (eg: you might be painting on Layer 2 but unwittingly use a render brush which also tries reading from Layer 2, etc) making it a slightly messy thing to support as as formal feature!

[VSZ]

@Crushy - Here you go Packaged Sample Project.

I've turned the "smooth frame rate" setting off so you get a better idea of things.

The sample project is divided into four sections with a ton of examples in each section, so be sure to check out as many as you can!

[DanimalsOnParade]

It is possible to magically wire a layer node in a render brush to the actual layers of the mesh being painted, but can you clarify the need for this?

I'm trying to implement a paint mask like you would find in ZBrush. By that I mean, I paint a normal paint brush on a special render target. Anything on this render target blocks any of the normal painting or decal stamping from putting color in that location. For example, if I cover my entire model with the masking paint except for a small star, then when I stamp a huge decal in that area, only the area of the star that isn't masked receives the color from the stamped decal. I hope that makes sense. Since the masking paint only needs to be one color, I can alternate between black and white colors (ignoring the render target's alpha channel) and be able to erase the masking paint. This doesn't replace erasing decals or text though, that's a still needed feature. This just allows for a non-destructive way of creating shapes and lines that can be painted or stamped on. It's not easy to make a straight line on a curved convex model with a mouse, so being able to paint and erase with a mask can help create that perfect shape .

I have everything working except for the part where the normal paint brush that basic paint and decals use read from the masked render target to not apply paint in masked areas (shown in the screenshot in my previous post).

With this setup there are complications (eg: you might be painting on Layer 2 but unwittingly use a render brush which also tries reading from Layer 2, etc) making it a slightly messy thing to support as as formal feature!

In my example, masking paint is hardcoded to Layer 7 with its own special brush separate from basic painting, decal stamping, and text stamping. This masking brush will never need to read from Layer 7, only render to it. All the other layers use a different render brush that will read from Layer 7 but never render to it. So assuming I can magically wire Layer 7 only into the brush that reads from it but not the other brush that writes to it, I should be okay.

[SaOk]

Is it possible to clear placed decals away from selected character and other objects? Having character pool so would need reset ther possible wound decals.

[VSZ]

@DanimalsOnParade -Would it be preferable to have a pre-canned set of texture masks in the render brush that you can switch between using your own logic? If you need fully paintable masks defined at runtime I'd need to expose a new parameter "Mask Layer To Read" or something to that effect so that the plugin knows which layer to route to the render brush, maybe a new node for that too. I'll add this to the stack of feature requests, it's piling up a bit now though

@SaOk - Hey, to confirm your requirement - you have a character with wound decals painted and need to reset the wounds at some point? (maybe when they're healed?) If you need this urgently you can mail me (link) for follow up - it's only a couple of lines of code to reset all paint for an actor so it's easy to add this.

Btw if you have a large pool of characters, each one will acquire separate would textures with no additional effort on your part. Unlimited number of actors (even dynamically spawned ones) are supported.

[DanimalsOnParade]

If you need fully paintable masks defined at runtime I'd need to expose a new parameter "Mask Layer To Read" or something to that effect so that the plugin knows which layer to route to the render brush, maybe a new node for that too. I'll add this to the stack of feature requests, it's piling up a bit now though

Yes, sir. I'd need fully paintable masks. If you expose this new parameter, could you make it a TArray< layers > to make it future proof for any number of layers? I can't think of an application for more than one layer off the top of my head, but if the amount of extra work is minimal (presumably just a for loop through the TArray), it might not be a bad idea to save more work down the road if someone else needs more than one.

Thanks!

[DanimalsOnParade]

Is there a way to setup the render targets on specified layers on an Actor without first using one of the paint methods? I have code that exports all the render targets as PNGs and now I want to load them back in. The render targets on an Actor are only created when that specific layer is painted to but I need those render targets created without first painting to them so I can load my exported PNGs back into them.

It looks like I might be able to do this by manually calling UDonMeshPainterComponent::SetupPaintingPrerequisites() on each layer, but I would have to create a dummy FDonPaintStroke for each one. I don't know if trying to do that would break anything else.

Any suggestions on how to do this?

[VSZ]

@DanimalsOnParade - To clarify: You're not using the in-built save system to export these because you want to edit the images in an external application or something like that?

If so, I was going to suggest using the LoadMeshPaintFromBytes function by.preparing a FDonMeshPaintSaveData structure, but you'll need to understand the internals of that structure well for that. The brute-force option is to call SetupPaintingPrerequisites like you mentioned.

You'll need to use dummy strokes with either approach (should be safe), but the first option will also take care of loading your PNGs onto the correct render targets for you, Maybe try the manual approach first and if you run into issues dive into Load function...

[DanimalsOnParade]

@DanimalsOnParade - To clarify: You're not using the in-built save system to export these because you want to edit the images in an external application or something like that?

From my testing, the built-in save system of saving the strokes has an unbounded size to it. If the user is painting and just clicks in the same spot 20 times, each click adds more strokes (bytes) to the list even though the end result, the render target, doesn't change at all. This doesn't work for me where I'm uploading character customizations to a server. The users can and will be painting over the same locations as many times as they want. Saving the render targets as PNGs gives me a bounded file size and in some cases smaller file sizes than the in-built system of saving the strokes. The PNGs only store what's on the render targets, regardless of how many strokes the user made. The downside to the PNG approach is that if you add the undo system, I wouldn't be able to undo any strokes after loading from a PNG, but that is an acceptable tradeoff. If undoing gets added, it can be a per-editing session type thing. I think that's how Photoshop handles undo also - once you save and close a PSD, you can no longer undo any of the history when loading that PSD back up.

If so, I was going to suggest using the LoadMeshPaintFromBytes function by.preparing a FDonMeshPaintSaveData structure, but you'll need to understand the internals of that structure well for that. The brute-force option is to call SetupPaintingPrerequisites like you mentioned.

You'll need to use dummy strokes with either approach (should be safe), but the first option will also take care of loading your PNGs onto the correct render targets for you, Maybe try the manual approach first and if you run into issues dive into Load function...

Okay thanks! I'll try the manual approach since I already have it loading into the correct render targets, as long as those render targets are created first by painting / stamping decals on the model. I'll report back if I run into any trouble setting up the dummy stroke or anything else.

[DanimalsOnParade]

To follow up, I got it working! I did have to make UDonMeshPainterComponent::SetupPaintingPrerequisites_AutoUv() a public function though as it was private originally. Any chance that you could make that function (probably all 3 of them for consistency) public in the next update?

[VSZ]

To follow up, I got it working! I did have to make UDonMeshPainterComponent::SetupPaintingPrerequisites_AutoUv() a public function though as it was private originally. Any chance that you could make that function (probably all 3 of them for consistency) public in the next update?

Glad to hear! And sorry for the super-late response, been very busy of late and just got around to this now.

So you're using DonExportPaintMasks function to save pngs directly? The SaveMeshPaintAsBytes's function takes a bNeedsBakedTexturesForSkinnedMeshes param that should simply your workflow, but right now that function will save paint strokes too (even if you asked for only baked textures).

There is significant room for optimization in how paint strokes are stored as they were originally designed for one-off gameplay events like projectile impacts/etc. With some effort, the data structures can be redesigned to significantly reduce the size for full-on painting. The bAllowDuplicateStrokes flag will help reduce the bloat in some usecases, but is not well suited for repeated painting. I have some usecases coming up in this space within the next 6 months or so, so I might take this up at some point.

PS: SetupPaintingPrerequisites_AutoUv wasn't meant to be public as its kind of an implementation detail. Using SetupPaintingPrerequisites should be equivalent other than the extraneous stroke/cell registration.