❀ DoN's Dynamic Mesh Effects ❀

Our Characters are using a lot of runtime morphs on them, so possibly that could be causing something, since I believe our last build was either 4.21 or 4.22… so that update in 4.22 might have caused it… I will get back to you after modifying the .h file and am done recompiling with the results…
Also I believe I used to use UV1, however in this version we’ve been testing using UV0, although our models do have a second UV layer.
Thanks again for helping out… The flesh destruction was a fun feature of our demo back during announcement, it would be a shame to lose out on it, n have to go back to using limited count sphere masks.

Edit: (Sorry but, I cant seem to understand what to modify about the line you mentioned. Can you elaborate kindly?)
~thanks again.

Here is the vid post from the old build…
https://forums.unrealengine.com/unre…19#post1655419

I can post a demonstration on the lag in the
4.25 version soon

For quicker investigation it would be ideal we could compare like with like. I’d really like to know about the comparison between your previous results and current, but ideally with the same material layout and workflow. If it’s not too much of a hassle I suggest providing test results of your previous engine version, but with your latest material setup incorporated into it.

That will provide testing parity and prove conclusively whether we are dealing with a version to version degradation or a need for workflow optimization / finetuning.

Alternatively if you can just modify the 4.25 sample project to mirror your setup and reproduce the issue there, do send that over to the support mail and I will be able to investigate the issue more easily.

  1. If you haven’t done so already, copy the plugin over from the Engine/Marketplace/Plugins/DonMeshPainting folder over to your Project/Plugins folder (create a Plugins dir if necessary)
  2. Open the file DonMeshPainterGlobalActor.h in the Visual Studio solution for your project
  3. Search for DON_BUGFIX_FOR_MORPH_TARGETS_POSCAPTURE_ENABLED and set the flag from 0 (current value) to 1.
  4. Recompile and test your usecase.

Let me know!

  • Venu

Thanks for the explanation. It was declared in the cpp not h file… I switched it on, and tried again, I think it worked. There’s still a little bit of performance drop but that seems related to the heavy materials we’re lerping… I’ll run some more tests, but this is playable now. Thank you.

I’ll work on the other things you’ve mentioned to see if I can get it smooth like the previous version we had going… might just be the higher res textures and material count.

@ thelazylion - That is great to hear! :slight_smile:

Ideally this flag should be turned on by default (to support morph targets), but it was disabled during a recent migration to mitigate suspected stability issues. So do be on the look out for any odd bugs emanating from this.

Further optimization ideas:

  1. Be sure to lower the texture resolution for the eyes and other tiny body parts. Personally I’d leave out the Eyes entirely if possible but if you really need to depict damage there try using a very low resolution render target template for such materials.

  2. If you are using decals try switching to the default circular brush instead; I believe you are already using damage textures so you will still have fair amount of visual control. The rendering cost of decals v/s default brush is exactly the same, but the painting cost of the decal workflow is significantly greater so for fast paced gameplay scenarios I’d avoid decals if possible.

  3. Try combining materials with similar shaders into a single material slot if this is feasible. Apart from texture memory (/resolution) the overhead of creating and maintaining render targets per material also contributes to the per stroke cost so you can save on that with lesser materials.

Thanks for the info, will work on adjusting…
As for the hitch though, after some testing, turns out it’s still there. Still unplayable…
I will try to port our assets from the previous build and do some testing, and also porting the current ones into the sample build to see whats going on…
Will update further.

Sure.

Another thing worth trying is to recompile your blueprints - ones that use the paint nodes and possibly any related ones like character blueprints too. I actually remember seeing something very similar to what you described in the sample project; it was apparently resolved by recompiling various blueprints one by one and I haven’t seen the issue manifest again since.

Appreciate your patience on this issue.

  • Venu

After some more testing and checking with the older model. There old char model had multiple materials too, but spread out amongst modular clothing. Body And head separated, both get 1 material each. Shirt, jeans, jacket, shoes all have their own single material as their own separate models… also a skeleton mesh underneath, 7 materials being painted total, but in a loop with paint stroke from model to model.

Current model is merged, but with less materials total, 4-> head, body, arms, legs. But combined as a singular model. And produces lag spike per stroke.
​​​​​​ Not sure why it’s such a performance difference when doing multiple paint strokes separately, than doing one that covers multiple materials…

Seems there needs to be a way to spread the out the stroke between materials or something… like over the span of 0.125 seconds or something. I’m not really cpp savvy. But I’m not sure if we can merge materials further without losing out on high quality modularity with our models. We were at 13, but now at 4-5 but the spike is still too noticable.

i use ue4 4.25.3 i have this warnings anyone no how to fix. i tested with a clean project :frowning:

LogClass: Warning: FDonPaintStroke::WorldLocation is not initialized properly
LogClass: Warning: FDonPaintStroke::BrushSizeWS is not initialized properly
LogClass: Warning: FDonPaintStroke::BrushDecalRotation is not initialized properly
LogClass: Warning: FDonPaintStroke::BrushColor is not initialized properly
LogClass: Warning: FDonPaintStroke::FaceIndex is not initialized properly
LogClass: Warning: BoolProperty FDonPaintStroke::bEraseMode is not initialized properly
LogClass: Warning: ObjectProperty FDonPaintStrokeParameters::BrushDecalTexture is not initialized properly
LogClass: Warning: ObjectProperty FDonPaintStrokeParameters::BrushRenderMaterial is not initialized properly
LogClass: Display: 8 Uninitialized script stuct members found
LogAutomationTest: Warning: FDonPaintStroke::WorldLocation is not initialized properly
LogAutomationTest: Warning: FDonPaintStroke::BrushSizeWS is not initialized properly
LogAutomationTest: Warning: FDonPaintStroke::BrushDecalRotation is not initialized properly
LogAutomationTest: Warning: FDonPaintStroke::BrushColor is not initialized properly
LogAutomationTest: Warning: FDonPaintStroke::FaceIndex is not initialized properly
LogAutomationTest: Warning: BoolProperty FDonPaintStroke::bEraseMode is not initialized properly
LogAutomationTest: Warning: ObjectProperty FDonPaintStrokeParameters::BrushDecalTexture is not initialized properly
LogAutomationTest: Warning: ObjectProperty FDonPaintStrokeParameters::BrushRenderMaterial is not initialized properly

If there is any way for me to compare these two myself that would be really helpful in debugging. Even a basic sample project mirroring your setup is more than sufficient, however if you’re pressed for time you can also send any relevant screenshots of your setup (material setup and Paint Stroke BP setup) over to the support mail and that will help me get started as well.

This is an excellent idea, thank you!

It should be possible to distribute the workload across materials, across game time. Will look into this for the next update. Completely async would be great, but I’m not sure that is feasible.

Aside from this proposed improvement though, I’m still interested in investigating the two setups you mentioned above, so if you could provide any further details as requested above that would be useful too.

These warnings should be benign (not affecting any functionality), however I do understand your concern about the output logs getting polluted with these verbose lines.

Will investigate this further, thanks for the headsup.

If you’re experiencing any loss of functionality though do get back, because that should be completely unrelated to these messages and may be a different issue altogether.

  • Venu

I will work on a sample project containing both model types to send around this weekend. Hopefully that’ll help with things on your end. Should I just send the link to your support email listed on the market page? Also good to hear that maybe the strokes per mat could be spread out a bit… Hopefully that could work as a quick fix.

Thanks for again for helping out. I’ll send over the project as soon as I had time…

It’s great too see you back VSZ, this topic was very silent for a long time!

I haven’t started to use this plugin yet but I have some questions. Is there anyone using pathfinding plugin in open world environments? How is the performance? Will we see more updates upcoming days? Thanks!

Thanks thelazylion, let me know!

There is a valuable optimization that can be performed to limit painting activity to only materials that are present in the active HitResult. This has two issues though:-

  1. For larger brush strokes only a single material will be selected depending on the hit location. This could cause splatter effects to skip a nearby material simply because they were not directly “hit” by the trace query.
  2. Characters do not support the “Get Material From Face Index” lookup, so users will need to setup physical materials (corresponding to each rendering material) that the plugin can hopefully use to infer which materials to skip for a stroke.

I would prioritize this above async stroke relay as this is slightly easier to implement and could be a quick win for many plugin users and common scenarios.

Thanks @Emrehan! Sounds like you’re alluding to my pathfinding plugin rather than this one. I’m afraid I currently do not have the bandwidth to maintain that plugin. As that plugin is rather old now (nearly 5 years now!) there is already a vast amount of information on the relevant threads answering many common questions including the one you mentioned, I hope that will suffice for users investigating that plugin. Appreciate your understanding :slight_smile:

Hey VSZ! So glad to see you are back!

I tried using the plugin a while back before you had made many of these optimizations and bug fixes, so I am happy to re-introduce it to my project again. I have question though, which perhaps may be rather fundamental but yet I still need some help or clarification on this:

As I understand it, the physics asset must be close to the skeletal mesh itself, or else the paint won’t apply properly, or at all.

My characters have physics assets that are reasonably close to their meshes, but they are made using primitives like cylinders and boxes. So is only possible to get these pieces generally close to the shape of the character. Some places will always be closer, some farther away. They will almost never be perfectly aligned with the mesh, of course.

As a result, of course, I’m only able to paint on some of my character. (We are doing small strokes for bullet holes) Certain areas do not receive a paint stroke at all, some areas need the brush to be much bigger, and some areas work perfectly. I have looked at my physics asset and I cannot find a rhyme or reason to which areas get the paint stroke in accordance with the physics asset. Some areas where it protrudes greatly get a paint stroke. Some areas where the physics asset hides inside the mesh also get a paint stroke. And some areas where it is close to the mesh do not get paint strokes, though usually it does. But seemingly not always. Anyway in all, it seems I can get about 60-70% of my character to receive paint strokes.

I have also tried creating a new physics asset where its mesh hulls are generated from the skeletal mesh itself. This results in a much more accurate physics asset (just like the one in your demo level) but even this still only gets me partial coverage on the character when painting on him. (I also worry that using this high density physics asset could hurt my game’s performance). Some places where it looks like the physics asset is very close to the mesh can result in no paint stroke. Seems sort of random, but also seems consistent, which feels like an important detail to add.

I should add that we have characters using modular clothing meshes. So the clothes, while they do sit close to the character mesh, are looser-fitting in other areas. (They are NOT cloth physics assets though!) Clothes of course, typically do not have their own physics assets, so we have to direct the paint stroke to the clothing components to draw holes in them, but it also doesn’t work everywhere.

Is there a way I can force the paint stroke to happen even 100% of the time if it is not perfectly accurate to the location of my shot? The visual feedback is more important than the accuracy in my case.

Thank you!!

UPDATE EDIT: I have remade my physics asset once more, with more careful use of certain types of shapes and it is much closer to my character’s shape while saving on polygons. I still can’t paint exactly everywhere but it is much better now.

Also, is there a way to paint to more than one component at once? Can one paint stroke be applied to both my character and his clothing?

@cpenny20

  1. **Painting multiple components
    I’**d like to address this one first as it is far more doable.

You’ll need to perform a manual Overlap query at the site of your hit location and collect the components of interest within a suitable radius.

You can then pass each component in turn to the paint stroke node. Seam / overlap issues may occur depending on the size of the paint stroke and overall effect on both components.

  1. Cloth & Paint
    It sounds like you have applied the mesh paint nodes on the Cloth materials rather than the underlying mesh, correct? Painting on cloth is not supported if you cannot provide a matching phyx collision representation that moves along with the cloth. I have not worked with cloth assets much myself, but I can explain what you are seeing.

The behaviors you described are expected as there is no way to reconcile the fluctuating pixel positions of the swaying cloth asset from the actual hit location.

The plugin determines whether to paint a pixel (i.e. UV location) by comparing the positions of the pixel being sampled with the hit location using brush size (distance) as tolerance. This means there is a “minimum viable brush size” for any mesh compnent whose physx representation deviates from its visual (pixel) representation. This explains why you are able to paint after increasing the brush size.

As increasing the brush size will not be feasible in many cases here are some alternative ideas:
a) Sync the meshes prior to each paint - This is probably more feasible for customization screens rather than for fast gameplay scenarios, but if you manage to sync the cloth asset to the mesh (i.e. the “rest pose” of the cloth without any forces acting on it) then painting will be consistent for that stroke (deviation of cloth pixels from mesh surface still need to be accounted for via added brush size) and once painted the effect will stick onto the cloth without any issues in subsequent animation. Obviously not sure how easily you could achieve this for a gameplay scenario.

b) Matching UV Layouts for Cloth and Underlying mesh - This requires a new feature to be implemented to work, but the idea is that if you can create the UV layout for your cloth that matches the underlying mesh (i.e. vertices that occupy the same surface also occupy the same UV locations), then it may be possible to target only the underlying mesh for painting (with the assumption that physx will match reasonably well) but then pipe the paint node of the body mesh to the cloth mesh. As the UVs match (as described earlier) the cloth can receive the alpha mask of the body and use it for any custom effects. Of course if the cloth is swaying very wildly then there will be a slight mismatch, but I think this shouldn’t be an issue given the speed with which cloth assets usually undulate.

The piping feature I alluded to above (sharing the mask of another material) is not currently available so that would need to be built out as well for this to work.

~

Hope this helps!

  • Venu

Thanks for your reply, it was helpful and I think I’ve got a good setup going now.

I have two more questions for you when you have time.

1.) I noticed there are parameters for an irregular shape in the ellipse equation in the M_PaintBrush_Regular material. Am I correct in assuming this means there is a possibility to use an elongated circular shape as my brush? I made an instance of the material and changed the settings related to the brush, and while I could get it to change its appearance in the material editor, it didn’t seem to paint any differently on my character. Any idea how I might achieve this effect, if it’s possible to do?

2.) Is there some simple way to dilate the brush strokes to avoid artifacts at the edges of the UV islands? It’s not the end of the world, but when I paint along a UV seam, there is a noticeable gap right along the seam. I understand this is just a limitation, but curious if there’s some way to force it to paint beyond the UV seam even if it risks other visual artifacts.

Hey @cpenny20, my apologies for the late reply on this.

  1. Yes, custom brushes are fully supported and the “render brush” parameter of the Paint Stroke nodes should be used to supply your custom brushes (this is preferred to changing the default brushes, but should have no impact on functionality).

Currently the ellipse brush picks its x and y scale from the render target template. You should double check that you have disconnected the pins where the plugin reads these (as float parameters) and supply your own values there. This should work.

  1. Only decals should be affected by seams for this plugin. The default brushes (circle/ellipse/etc) should be free of seams and artifacts of any kind. If this is not the case it would be useful to have some screenshots of the overall setup to begin investigation on this.

Any reason uv1 mesh paint wouldn’t work even though we duplicated the uv0 layer already and reimported… The skmesh preview shows the body with two uvs.

Unsure of the issue.

Mesh paint uv0 works. But uv1 doesn’t…
​​​​​​on multiple projects with multiple meshes on 4.25
I attached a screenshot of the model, back on an older project, this same model was used for mesh painting and worked quite well on a build under 4.23

Is this just my machine or are other experiencing this issue with 4.25?
Thanks in advanced for any info…

(lemme know where to send it, but I can link a game project with the model in it if needed, or just link the fbx directly.)

Hello,

I bought this package and used it on 4.25,
Please update it to 4.26 asap otherwise I can’t upgrade my project on it.

Thanks in advance.

4.26 update has been submitted and should be up soon :slight_smile: