@Der.Dominic Thanks for the headsup. I’ve sent an informal request to an epic staff separately in addition to bumping the answerhub thread for more details.
For the next engine update I will do a quick poc to see if an alternate system of some sort is feasible at all. Not entirely sure at the moment.
Hey. You can turn the property bDisplayLogWarningsOnScreen to false for this. You will find this in DonMeshPainterComponent.h
This is not exposed to the editor yet, so you’ll need to modify the code and rebuild via Visual Studio…
Hey, sorry to bother you again but, seems rebuilding a plugin in the launcher version of the engine is not really doable. There seems to be no way to rebuild the plugin after making the changes and I don’t intend on using an engine built from source on this. I tried the hackish way of putting it directly into the game folder and putting it back, and also deleting the intermediate and binary folders to try to trigger it to auto rebuild while it was still in the engine folders. But it needs to be rebuilt manually which I don’t think is allowed in launcher version of engine? I mean used to all the time on projects I used to run on compiled from source, but doesn’t seem doable in the launcher version.
Any solutions to be had? Anyway you could expose that variable by default to the editor maybe? Seems the sort of thing that should be toggled on and off, especially since printing eats resources when you are using your editor tools to optimize. I was also wondering, does it trying to interact with materials that aren’t setup eat up gamethread? Kind of a side question out of left field lol… sorry… figured while I was here.
Any solutions though would be welcomed, I haven’t tried the UAT batch tool but others who have tried it who had the same issue with other stuff said it didn’t work. Thanks.
Okay so, seems the answer is to create a blank c++ project, then put the plugin files in its plugin folder, change the needed code… then delete the intermediate and binaries and start up the blank c++ project, (making sure the plugin has been stripped from the associated engine as well, the plugin code should only be in the c++ project as of now) then add the plugin back into the engine.
So, I am good now. Thanks! But curiously, I still wonder… What goes on inside of the plugin when it tries to paint on a surface that isnt setup? i mean besides the warning (resolved) but, it seems to slow it down some still and it makes me wonder is there something in the code that can be changed to make it just ignore things that don’t have a layer node setup in the material, i guess the question is… does it already just ignore it? or is it trying to interact with it more than necessary than it is just to see if it is setup to receive? Is there anything there that could be removed, since it doesn’t seem it was meant to run with materials not setup for it (ie, my mesh that had materials that collision couldn’t be shut off but did not want the paint nodes in the material)
That was probably all clear as mud, but if you understood… great. If not, my main reason is dealt with… so I am happy. My gore effects are just heaps better with this plugin resource wise and looks **** good.
UATHelper: Packaging (Windows (64-bit)): ERROR: System.IO.DirectoryNotFoundException: Could not find a part of the path ‘X:\Program Files\Epic Games\UE_4.21\Engine\Plugins\Marketplace\DonMeshPainting\Intermediate\Build\Win64\UE4\Development\DonMeshPainting\DonMeshPainting.precompiled’.
That file isn’t in the installation to the engine or the sample project… so where might one find this file, and any others that are necessary for packaging a project with this plugin?
Marketplace plugins cannot be modified in the engine folder itself, for modifications to function properly they need to be migrated over to your project folder as follows:
Instructions:
Create an empty C++ project which you will use as your workspace.
Inside the new project’s root folder, create a “Plugins” directory
Copy the Mesh Painting plugin from <Your4.XYEngineFolder>/Engine/Plugins/Marketplace/DonMeshPainting into your Project’s new Plugins directory.
Delete the Binaries and Intermediate folders inside DonMeshPainting for a fresh start.
Open your new project from Visual Studio and compile your project to test. The plugin should now be compiled afresh along with it.
~
For your other question about an apparent perf overhead for unused materials:
Ideally this should not be the case as the plugin will only 1) iterate through all your materials 2) find out which ones have the matching layer parameter setup by querying the material and 3) ignore such materials with a warning. I will double-check for the next engine update whether there is anything more to this.
However there is one scenario worth checking: If you have a parent material function with a paint node and have child material instances that shouldn’t really be participating in any paint effects, then those child materials will definitely double/triple your cost unless you manually disable them.
See this knowledge base article for how to disable such child materials from receiving paint:
I have found a workaround for anyone who still has troubles with the UE4 bug causing flickering morph targets after calling “DON Mesh Paint” node:
Create a copy of the mesh you are painting on and set it to invisible. This is your dummy. It has to be the exact same mesh. Material can be anything.
After your “DON Mesh Paint” node place a second node and paint on your dummy.
That’s it. I found this by accident. Miraculously only the last one of same meshes gets the bug and since it is not visible the bug is too. Mind you of course you are causing double the impact on performance so maybe you could also use these tips from master Venu himself:
For minimizing impact in short-term:
Reduce the resolution of the positions texture generated for the dummy mesh. Currently this is hardcoded in DonMeshPainterGlobalActor.h (DefaultPositionsTextureSizeX, DefaultPositionsTextureSizeY). If you can somehow parametrize it for the dummy mesh you can dramatically reduce performance overhead.
Reduce the resolution of the paint render target for the dummy mesh’s materials (not sure whether using different materials than the actual mesh will negate the workaround though…)
hello, is it possible to remove paint decals, or move decals?
i’m very interested however i didn’t see you mention anywhere if i could remove the decals i apply from your node.
it’s really important for me to add and remove decals or move them.
For Removing decals: The eraser functionality can be used to remove decals, however do note that this is not a logical “Remove” operation; Erasing simply scrubs the pixels painted around a given location. If you want to easily remove an entire decal via logical mapping (i.e. “please remove the entire decal I painted approximately around this location”) then you’ll need to use your own logic to support that. A simple technique to achieve this would be to maintain a custom list of all painted decal locations (and their brush size) and erase all decals that are sufficiently close to the brush location from which you desire to remove decals.
For Moving decals: This could work by erasing the previous decal and placing a new one each time the cursor position moves sufficiently. As you’re only moving one decal at a time, you just need to memorize the last painted decal location (and its brush size) and erase from there the next time. The performance cost of this will vary depending on your target mesh type and UV method (a.k.a painting workflow; see this kb article for more).
Hey there, thanks for this great plugin, works beautifully to create dynamic gore on our characters. only issue we’re facing is that we’re using a single skeletal mesh, with multiple material slots, (1 for head, 1 for body)… and the paint node only applies paint strokes to the first material slot, and not the second, however in your demo, the template basic skeletal mesh with wings seems to activate the paint strokes on all materials rather than just the first of the hit component.
Can i ask the procedure for applying the paint stroke to the multiple material slots of the same mesh?
Thanks again for your time, really appreciate this plugin, cant wait to post some results once complete.
You just need to make sure that *every *material of that skeletal mesh has a Don UV material node connected to it.
The sample project uses a master material for the skeletal mesh which all the material slots derive from, so it only adds the node once. I’m assuming your material slots are all independent, so each and every one needs to add the correct Don UV node inside of them. Paint will automatically be routed to all material slots that carry a matching Don UV node for the active layer being painted.
If you’re already set this up and it is still not working, screenshot snippets of your material would help!
And yes, do feel free to share your creations on this thread!
Thanks for the prompt reply, I attached some screen caps of the issue and the mat functions…
Made a mat function that just converts the input mat using height lerps driven from DonUV1 into a flesh damage mat for the output. Both head and body mat’s have this function applied the same way… but only the head mat receives the paint node stroke. Tested using the same mat from the head on the body mat slot, with no results.
Head material receives the node stroke, while body does not. Head is mat slot 0, and body is mat slot 01…
Please try removing the Don UV nodes from the material function and move them directly into the material, passing the alpha(/rgb) as material function input(s) instead. I can’t recall immediately why that would be an issue, but seems like the most obvious thing to check.
It is also possible that you have accidentally disabled a paint layer in a child material instance (as described in this kb article), but that’s quite a long shot and I doubt that’s the issue here.
I ended up moving the entire function out into the material just to be sure, along with the don uv node, however still the same result.
It’s definitely detecting the don node however, as switching out the material with something that doesn’t contain a Don Node, the print screen error stating the node is missing from material pops up. Meaning it’s detecting the node and but just not applying, or it is applying, but the results are not visible, I’ll tinker with my UV’s and see if it’s something to do with that.
Also the Mat instance layer wasn’t disabled when I checked.
Thanks again for your time, Let me know if you think of anything else…
Problem solved thanks for your help, the issue was with the UV placement, Had to redo UV’s for the body, as they were in the wrong spot for the don node.
Static mesh says Collision UVs support is not enabled. However Support UV From Hit Results is on. Trace complex for the mesh is on. The mesh_space_UV1 does spawn the decal, but in random places. Planar (xy) does not do a thing at all. It works ok on static meshes that I found in the engine, but not on the any imported ones, whether I set it to simple, complex or use complex as simple collision.
The scale of the projected decal is random and sometimes covers half or even the entire mesh. It works fine on a skeletal mesh, on skeletal mesh that is being moved, on skeletal mesh that is playing an animation. The scale glitch occurs an animated character with the same mesh (hit result is with the mesh and not with the character capsule) and on a mesh that is simulating physics! (no overlapping UVs on channel1)
ue4.20.3
For #1 - You mentioned trying Planar, is this a simple floor mesh? If yes, I’d focus on getting a “Don Local Space” node to work instead of using any Collision UVs at all. Local Space will provide better visuals and performance for your usecase. If you are reusing a Wall mesh as a Floor you’ll need to use the correct planar node for that. Eg: XZ or YZ (instead of XY) for any wall meshes you have rotated to behave as floor meshes. The Local Space axis is what matters here (unless you’re using a world space node).
Specifically for Collision UVs - Can you look at the HitResult and see what the FaceIndex value is? If it is -1 it means that the collision UV support has not been setup properly, somewhere. Did you restart the editor after checking “Support UV from Hit Results” and can you also double check that “Trace Complex” was enabled for your Trace? I’d also check the UV0 channel to see if all faces are laid out uniquely.
For #2 -
Can you clarify this further please, the scenario is not entirely clear.
Are *only *physics simulating meshes / ragdolls experiencing this issue? If yes, does the issue also occur when the simulation has come to a complete halt (or only while it is moving)?
It is possible that the refresh rate (used for baking pos texture) may be too slow for your usecase. If you open the file DonMeshPainterComponent.cpp and search for the function *UDonMeshPainterComponent::IsPositionsTextureStale *you can modify the statement that reads *timeElapsedSinceLastPositionRefresh > 0.1f, *
Try changing the value above from 0.1f to something like 0.01f (as an experiment) to see if that helps (this will have an impact on performance, so be sure to revert back after testing). To try this suggestion you’ll have to modify the code in Visual Studio and recompile. See this post for instructions on setting up the plugin with your project.
For this usecase, consider using damage textures (peeled away by alpha mask) instead of decals as that approach offers much better performance and control over visuals as well. For example you can reveal damage for different body parts using a premade damage texture.
thanks for your help, the issue was with the UV placement, Had to redo UV’s for the body, as they were in the wrong spot for the don node.