YES!!! Thank youuuuuuu!!!
Hi, sorry for the confusion - I think you misunderstood my previous message. The decal size issue I mentioned is a completely different issue that was affecting other plugin users (see that post for details). That fix will not help your issue in any way at all.
Yours is probably a setup issue of some kind, so I still need the sample project I asked for so I can fix it for you and update the tutorials if deemed necessary.
Please let me know when you’ve sent the sample project over or if you need more information on what is to be sent.
Ahn ok i tell you when i send you project
Thank you. Here’s a few other things you can also try while you’re preparing the test project.
- Try using a decal texture from the demo project instead of yours, to rule out issues with the decal texture.
- See if replacing your material with one from the demo project works to rule out issues with your material (you can pick the character material from the 2nd example for decals)
(…or replace the demo project’s material with your own) - Import the demo character into your project and see if your decal setup works on that model…
The test project will be useful to quickly diagnose the issue though.
❀ ~ 4.21 Update Submitted ~ ❀
Update has been submitted along with the critical bugfix for decal size mentioned in this post.
@cpenny20, [USER=“1019567”]Rita Shinenen[/USER] - Let me know if the inconsistent decal size issue you reported earlier works to your expectations now 
**~~~ ❀ 60% Discount | Marketplace Sale! ❀ ~~~
**(Purchase Link](DoN's Dynamic Mesh Effects in Code Plugins - UE Marketplace))
Just a reminder that the plugin is 60% off for the Unreal Marketplace sale.
The plugin has a wide and ever-growing range of functionality that is well-suited to practically any project made in Unreal Engine.
At $28, this is probably the lowest price the plugin is going to ever have, so check it out!
Hi, The bug with decal on the player it’s fixed?
I never heard back from you with the requested information (I have quoted your post above).
What you describe hasn’t been reported by anyone else before, that is why further information in the form of a sample project was requested from you.
I’m not sure what this hypothetical bug even is at this point so no action can be taken to work on it 
Ok thank you
After all these years now it’s obvious Epic will not (re-)fix the morph targets bug.
(Morph targets are resetting to zero when using mesh paint. See Unreal Engine Issues and Bug Tracker (UE-54099) )
Has anyone found a workaround?
(Except for downgrading to UE 4.16)
Still cannot use this excellent module since all my models are using a lot of morph targets.
Thanks for any help.
For reference this post has historical details on this morph target issue.
Yes, if anyone has found a workaround for that issue please do make it known!
@Der.Dominic - I’m still hopeful that Epic will fix it for 4.22.
The bug was marked “Not Fix” until recently but after it was pointed out that Ryan Brucks’ popular mesh painting video also relies on the same technique, they seem to have reopened it (that’s judging by the chronology of events at least :)).
Rewriting the plugin itself to workaround the issue may or may not be feasible. There are some options on the table (ranging from a duplicate skeletal mesh for capturing positions to a simpler relative bone space based painting discussed earlier in this thread) but the dev effort involved is significant considering we’re in an advanced lifestage of the plugin’s development cycle.
If the pose of your skeletal mesh doesn’t change often and/or if accuracy isn’t that big of an issue, you may be able to capture the skeletal mesh’s positions only once (this is what triggers the morph issue) and use that as a reference pose for all subsequent painting. Won’t work for most usecases though.
Hopefully Epic will have fixed this in 4.22, we’ll see.
Hi
in our project we have a character that we need to stamp many 5x3cm squares onto. They need to be really precise in size and shouldn’t scale up/down. Can this be not dependent on UV with this plugin? Or are perfect UVs needed? Cheers.
Hi! If you’re stamping decal textures then the results are indeed fully UV dependent (so size and seams will entirely depend on UV islands).
However the plugin supports seamless / UV independent skeletal painting as long as you use a **procedural brush. **A procedural brush is a set of material nodes in the plugin’s render brush (which can be overriden). The default brush is a circle (sphere mask), but *if *you can define a procedural brush that paints a 5x3 square then it might work. On top of this a “damage texture” can be masked to provide the final look.
Inside the render brush you will be provided the world space paint location and skinned position of the pixel currently being rendered. You will need to use those inputs (and handle any brush rotation on your own) to project the square onto the character, with your own material node logic.
Again, the above is purely theory; whether such a procedural brush can actually be implemented is something I’m not entirely sure of at first glance.
Hey
thanks for the input. I went ahead and did some experimentation. With a pretty dense convex hull collision and a custom render brush I’m pretty close to what I wanted.
There is still some deformation around edges, but it’s okay for now (the jpg is strong).
I wanted to experiment with the RotateAboutAxis material node and adjust Square_Axis and Square_Rotation depending on where I’m clicking.
The problem I’m having tho is that everytime I plug a dynamic material instance in to the “Brush Render Material” input of the Paint Stroke node my character will be completely colored on the first click:
What’s up with that? It works if I make a DMI in the content browser. But if I do it at runtime and plug it in, the character is fully covered instantly.
Cheers!
The plugin creates its own DMI for the render brush, so this may simply be contention between the DMI instance you first passed and the one the plugin created.
An elegant way to address this would be to allow the plugin to always create the DMI first and use that via the **GetCachedRenderMaterial **function.
You’ll need to expose this function to Blueprints though:
*1) *Open DonMeshPaintingHelper.h and add the following lines near the bottom of the class:
UFUNCTION(BlueprintPure, Category = "Don Mesh Painting", meta = (WorldContext = "WorldContextObject"))
UMaterialInstanceDynamic* GetCachedRenderMaterial(UObject* WorldContextObject, class UMaterialInterface* RenderMaterial);
- Implement this function in DonMeshPaintingHelper.cpp as follows:
UMaterialInstanceDynamic* UDonMeshPaintingHelper::GetCachedRenderMaterial(UObject* WorldContextObject, class UMaterialInterface* RenderMaterial)
{
auto globalPainter = GetGlobalManager(WorldContextObject);
if (!globalPainter)
return nullptr;
return globalPainter->GetCachedRenderMaterial(RenderMaterial);
}
- The function is now available via Blueprints. Search for “Get Cached Render Material”, pass your parent render brush and use the result as your DMI for manipulating whatever parameters you need to.
Note: I have not tested the code above, it was written spontaneously You will need some familiarity with C++/Visual Studio to implement and compile the above.
Hope this helps.
Hey , thanks for the effort!
Would it be possible for you to implement this into the actual plugin? I could imagine other people also wanting to modify the DMI during runtime. You could also add a square procedural brush based on the image I posted.
Cheers!
Another thing: Is there a way to access the render target texture that is being written for my character?
Sure, but for a formal update you’ll need to wait till the next engine version.
If you need it sooner I suggest you make the changes above locally, it should be easy to incorporate without doing any coding yourself.
Any material with a Don uv node has a texture parameter which you can read to access the render target, as long as you know its exact name.
To know the name for each uv node just double-click on the node and keep expanding it further till you find a texture parameter with a name that looks something like DonPaintLayer_MeshGeneric_UV1_0 (for example). That is the parameter name you’ll need to query on your character’s material(s). Every material with a Don UV node creates its own render target.
Sad news:
Epic will not fix morph targets in 4.22
They updated the bug report.
[TABLE]
Target Fix 4.23
Has anyone had any new ideas?
How do you get around it in your projects?
As far as I know now this is a very old bug which had been fixed but reappeared in UE 4.17. Thanks for any help.
We are currently trying to downgrade to 4.16 (though it has A LOT of downsides).
Hey VSZ! I was curious is there a way to disable the debug messages on the plugin? I have it setup on the materials I want, and not on the ones I do not. Unfortunately since they are on the same mesh, its not an option to disable collision on it. (I am using it to just paint blood everywhere, and neat meaty scars on character meshes) and since I do not have the nodes in those materials its spawning off the layer isn’t setup for the material message. I know this, and just want to to turn off debug messages. I tried dropping a couple empty node in the materials just to kill the messages but this uses more resources and tries to process the paint strokes anyway causing lag. So, I was hoping you had built in some way to disable the messages from within the editor. I checked the c++ and I didn’t see anything, well other than the message in question.
Thanks ahead of time! I am enjoying your plugin.