❀ DoN's Dynamic Mesh Effects ❀

[VSZ]

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!
❤

[medRoom_dev]

Did anyone found a solution to the MorphTarget Flick in UE4.18? I still have that problem

[VSZ]

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!

[Themap666]

Great work and really impressive plugin VSZ! Can this be used to create a system that works kinda like Wolfensteins plasma cutter (https://youtu.be/Mp9K3RxMCsc?t=279) ?

[VSZ]

Great work and really impressive plugin VSZ! Can this be used to create a system that works kinda like Wolfensteins plasma cutter (https://youtu.be/Mp9K3RxMCsc?t=279) ?

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
1) 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.
2) 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.
3) 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

[VSZ]

Did anyone found a solution to the MorphTarget Flick in UE4.18? I still have that problem

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!

[VSZ]

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

[VSZ]

❀ 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!

Marketplace Purchase Link

[rennsix]

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.

In July, ilI'be working to implement your plugin with HTC Vive Pro. Will share results when able.

[VSZ]

In July, ilI'be working to implement your plugin with HTC Vive Pro. Will share results when able.

Thank you

[VSZ]

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.



Additional usecases like runtime landscape painting for marking trails, etc are also planned!

Anyway, hope you enjoyed this!

[VSZ]

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") 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

[SimBa2014]

Hi [MENTION=14603]VSZ[/MENTION],

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"?

[mechanicalsnowman]

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!

[VSZ]

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
1) 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.
2) 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).
3) 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 Tom 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.