Is there an ETA on 4.19 support?
I was planning to make some improvements (save size optimization, minor bugfixes, etc) before submitting. I’d like to allow for 2 weeks more as each update cycle is a valuable opportunity to add to the product 
@RodenHirata - I’ve been thinking about your Sequencer usecase again and just wanted to confirm whether you’re baking your sequence out and including it as a cutscene or if you’re playing the sequence as-is. If it’s the latter, isn’t it possible to just call the Paint Stroke node via a blueprint callback / collision event at the appropriate time and let it do its thing? If you are playing the entire sequence in-game the wall should be able to acquire the decal from the character (to quote your example) as long as you can supply the correct hitresult (iirc collision events should still work while the sequence is playing). If you’re rendering your sequence out, then yes, editor-time usage and subsequent load back can be very helpful. Let me know what you think!
Linux support coming for 4.19 update!
Among the other improvements coming to the plugin for the 4.19 update, Linux support is also planned.
ETA for submitting the update is around 2 weeks as mentioned in the previous post. Appreciate your patience in waiting for it! 
Hi Don,
Thanks for your thoughts again on this! It’s very kind of you. I am indeed rendering the whole movie out, as I need to edit it slightly with video edit software before use on the web, etc. I haven’t had a chance to test your pack with the sequencer, but I know Sequencer sometimes has problems rendering certain things. However, Sequencer has received a lot of improvements recently, especially in 4.19, and is being used more - so I think its a good thing if you can support it more somehow I must find some time to check your asset…
Ah in that case you do need formal editor-time/sequencer support.
One user managed to get editor-time functionality working with the plugin by dropping the “Don Mesh Painter Actor Global Actor” manually into the level (this is usually auto-spawned) and was apparently able to use invoke the paint nodes after that (via construction script/blutility/etc). I will try to see if I can add formal editor support for the 4.19 update. Sequencer support will probably need separate investigation though you may wish to try it out anyway…
4.19 Update Submitted (New Features!)
Cloth Support!
Now Paint effects over cloth-driven mesh-sections too! Results are fully dependent on the physx collision body associated with the cloth though, so if you’re having issues with accuracy remember that the plugin needs a HitResult with an accurate hit location. As HitResults are derived only via physx collision bodies, you’ll need to supply a collision body that approximates the shape of your cloth one way or another. Also if the cloth is animating wildly expect painting accuracy to be off because the cloth’s vertices will be displaced too far away from the relevant collision body for the plugin to successfully project your effects onto it. Once painted though, the cloth can animate in any way and your masks/effects will be projected correctly.
Linux Support!
Linux support has been added for the plugin! By extension Mac should work too, but hasn’t been officially tested.
Save Size Optimization
Text data per stroke is now selectively serialized resulting in reduction of file size for usecases that don’t need text. There is a lot more room for optimization, especially for free-painting usecases, that will be investigated at a later point in time.
Projectile Portal Example Improved
The default “portal travel” duration of the “Don Smart Projectile Component” provided with the plugin has been optimized to better suit the example project. The projectiles now bounce off the floor correctly after passing through a mesh hole painted by players. Users should modify the PortalTravelDuration variable of their projectiles to suit the needs of their usecase/project.
~
This update has been submitted to the marketplace and will hopefully be approved soon.
Thanks again to everyone for your patronage of the plugin!
Did anyone found a solution to the MorphTarget Flick in UE4.18? I still have that problem 
Hi, I gather from your AnswerHub post that you encountered this issue independently (not using the plugin)?
Anyway, according to UE-54099 the Target Fix is 4.20, so I’m hopeful that a fix will make it in soon.
In the meantime please upvote the JIRA ticket if you haven’t already so Epic knows that multiple users/usecases are affected by this bug!
Great work and really impressive plugin VSZ! Can this be used to create a system that works kinda like Wolfensteins plasma cutter (The Weapons of Wolfenstein: The New Order - YouTube) ?
Is the plasma-cutter from the video you linked a free-form cutter (so players can draw random shapes with it) or is it constrained to pre-determined shapes depending on the surface being cut?
If the shape is pre-determined, you can certainly use the plugin to
- First paint the shape along an outline you have setup individually for each type of mesh. Opacity mask may be used for the outline if desired.
- Blast the hole with a chosen decal texture, spawn a new mesh for the severed part (again, pre-determined for each type) and simulate physics on the fallen part.
- Collision setup: If your shapes are pre-determined you don’t even need to use the plugin’s pixel collision API (which supports only circular collision holes atm). You can instead prepare two separate meshes (open/closed) for each surface type and just switch between those after an outlined has been carved through and leverage UE4’s native collision for everything.
~
Now if you want free-form cutting of shapes on a surface (and separating those from the original surface), some additional development is needed which is not prioritized yet.
My game’s caterpillars need free-form carving though (for severing leaves that having been cut all the way across or in an island shape) so I will be looking into this eventually, no timelines yet!
PS: Appreciate the kind words
FYI, it looks like Epic has closed UE-54099 as “Wont’ Fix”.
As your usecase is also affected by this, I suggest you add your voice to this answer hub thread. I have asked Epic staff for rationale as to why it was closed, but it will be really useful if you petition for your independent usecase as well so Epic is aware that multiple users/usercases are affected and that this regression (this is actually a bug they fixed in a previous engine version) is well worth fixing!
Question for Customers using this plugin with VR
I received a question on the product page about whether this plugin is VR friendly.
The plugin hasn’t been tested for VR, but I was curious to know if existing plugin users have any data to share on this.
Thank you for your input
❀ **Summer Sale **❀ **50%discount **❀
Just a reminder that the plugin is available at **50% off **for a limited time.
Nearly every game/project will benefit from the plugin’s rich functionality so do take the time to check it out!
In July, ilI’be working to implement your plugin with HTC Vive Pro. Will share results when able.
Thank you
**Project Usecase 1: **Player Created “Silk Nests”(using this plugin)
Just wanted to share a usecase from my project that I thought plugin users would find interesting.
In the video below, players build “silk nests” of their own using custom shapes/sizes; a flattened, non-uniformly scaled mesh is used as a base, over which they “paint” silk in successive layers. Eventually the “flattened” section is raised up (via WPO masking) to provide the illusion of a 3-dimensional construction.
I prefer this to a free-form voxel building solution as it is easier to define the rules of exactly what constitutes a successful construction plus for many surfaces (like silk) I don’t think voxels could properly represent the surface or believably depict the construction technique (i.e. specific to my usecase of a spider spinning and pushing silk).
**Project Usecase 2: **Free-Form surface decimation “Leaf Munching”
The usecase below is the original purpose for which this plugin was made!
Creatures of varying sizes (including 1mm!) are allowed to chew holes of arbitrary sizes on a surface like a leaf. Unique Decal textures are used for each creature to leave a unique mouth imprint on a surface.
The plugin’s collision API is used to determine which areas have been eaten up and which ones haven’t. It is also possible to prevent players from walking over holes using the same collision API if desired.
http://www.drunkonnectar.com/wp-content/uploads/2018/01/New-Browsing-Patterns.jpg
Additional usecases like runtime landscape painting for marking trails, etc are also planned!
Anyway, hope you enjoyed this!
I received a report about multiplayer issues due to the timing of replication global painter, components, etc.
The user has kindly shared a patch, but before incorporating it I’d like to ask whether any other plugin users have faced any issues with multiplayer at all.
The regular multiplayer flow (“Server is the Painter”](http://www.drunkonnectar.com/dynamic-mesh-effects-unreal-engine/kb/multiplayer-considerations/)) is QA tested with each release via the editor (including dedicated server mode) so I’m not entirely sure how the reported issue manifested in the first place.
Appreciate any input on your experiences
Hi ,
Thank about your plugin!
I have ships game and I am trying to use “Fly To” node in BehaviorTree.
The BT Task is to “ChasePlayer”, and after executing the BehaviorTree the ships also going sideways or reversing when avoiding a collision,
but because of the fact that ships can navigate in one direction (Y-axis movement), it seems unrealistic.
My question is: how can I limit the ship movement to one direction (Y-axis movement)?
Should I use BluePrint DonNavigation’s functions instead of BehaviorTree with “Fly To”?
Hey VSZ,
I’m researching skeletal mesh painting. I’ve looked into a few ways of doing this, and have a couple implementations going, but I was curious about how your own implementation works and how precise it is.
The most precise way I’ve found is the Ryan Bruck’s method where dilated UVs are stored into an RT, but the problem with it is that it requires a SceneCapture to take a snapshot every frame that there’s a paint stroke. It does allow small radii though and very precise hits, and paints across UV seams with no problems.
I was wondering if your paint system uses this or a modified / cheaper version, because I’d like to get the performance cost down as much as possible. The other method I’ve read about, where SceneCaptures aren’t running per hit, but rather hits get the nearest bone and calculate the ref pose to work out the correct hit location on an animated mesh, seems like it would be more performant but less precise, since painting on polygons which have influence of two or more bones (which is obviously super common for organic charas) would not be able to correctly work out the exact hit location?
So in short, does your mesh paint system alleviate the performance cost of the SceneCapture per hit method, or the precision issue with the bone / ref pose calculation? Assuming my concerns about the latter method are correct anyhow, that is just conjecture on my part but I can’t work out how it does it otherwise.
Thanks and keep up the awesome work!
For skeletal mesh painting, currently Ryan’s method is used. Performance is optimized via a combination of
- Caching and throttling of scene captures, so instead of capturing the positions every single stroke, they’re throttled to reasonable intervals which each usecase can customize (currently hardcoded, but can be easily parameterized to any desired level). For most usecases this yields acceptable results while significantly boosting frame rates.
- Rendering the “positions texture” at a lower resolution than the actual “paint texture” so the end result still looks high quality and the positions texture is still quick to render. Obviously this compromises accuracy to some degree, but honestly at 512x512 (the plugin’s default for positions) I’m yet to see any accuracy issue that would significantly impair most usecases (except maybe intricate detail-work under a character’s eyes, etc, but that kind of stuff is always going to cost performance).
- The other advantage of using the plugin here is that it requires no prior setup/editor-time baking for each character. Everything is dynamically managed, on the fly / on demand. End users just need to use one blueprint node making it trivial to utilize for projects at any stage of maturity. Saving and Loading support is also provided out-of-the-box.
I have the FPS counter on throughout the plugin’s video overview so you can get a sense of the performance attained (on a gtx970 gpu)
The Ref pose bone method (presumably you’re referring to Looman’s excellent article on this subject!?) is something I’ve been excited about supporting in this plugin, although I too share your concern about accuracy for organic shapes/skin deformation; it sounds perfect for many typical gameplay scenarios though. Another issue I have with this is support for dynamic / on-the-fly character setup instead of editor-time texture baking. I would need an extra frame to revert a character to its ref pose at runtime (or deploy a proxy skeletal actor reserved for this purpose or other such stratagem). Saving & Loading would be more efficient with this technique though, so there’s that benefit to consider.
Hope that helps!
~
@SimBa2014 - Locomotion is driven entirely by your own pawn via its AddMovementInput logic, the plugin does not participate in any locomotion as it would clearly be different for different pawns.
You need to rely on your pawn’s native movement logic or implement your own by overriding the AddMovementInput_Custom function provided in the DonNavigator interface.This is a question I’ve frequently addressed on the plugin’s thread pages so you will find a lot more information about this by searching those forum threads.