Announcement

Collapse
No announcement yet.

❀ DoN's Dynamic Mesh Effects ❀

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by 6gg Studios View Post
    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?
    Hi 6gg Studios,

    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:
    1. Create an empty C++ project which you will use as your workspace.
    2. Inside the new project's root folder, create a "Plugins" directory
    3. Copy the Mesh Painting plugin from <Your4.XYEngineFolder>/Engine/Plugins/Marketplace/DonMeshPainting into your Project's new Plugins directory.
    4. Delete the Binaries and Intermediate folders inside DonMeshPainting for a fresh start.
    5. 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:
    http://www.drunkonnectar.com/dynamic...ial-instances/

    Have a nice day

    Leave a comment:


  • replied
    And ah... at the risk of being clingy...

    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?

    Leave a comment:


  • replied
    Originally posted by 6gg Studios View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by VSZ View Post

    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...

    Glad to hear you are enjoying the plugin!
    Thanks for letting me know, save me some hunting time.

    Leave a comment:


  • replied
    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.

    Originally posted by 6gg Studios View Post
    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.
    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...

    Glad to hear you are enjoying the plugin!

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Sad news:
    Epic will not fix morph targets in 4.22

    They updated the bug report.
    https://issues.unrealengine.com/issue/UE-54099
    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).

    Leave a comment:


  • replied
    Originally posted by IntervideoFilm View Post
    Hey VSZ, thanks for the effort!
    Would it be possible for you to implement this into the actual plugin?
    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.

    Originally posted by IntervideoFilm View Post
    Another thing: Is there a way to access the render target texture that is being written for my character?
    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.

    Leave a comment:


  • replied
    Another thing: Is there a way to access the render target texture that is being written for my character?

    Leave a comment:


  • replied
    Hey VSZ, 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!

    Leave a comment:


  • replied
    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:
    Code:
    UFUNCTION(BlueprintPure, Category = "Don Mesh Painting", meta = (WorldContext = "WorldContextObject"))
    UMaterialInstanceDynamic* GetCachedRenderMaterial(UObject* WorldContextObject, class UMaterialInterface* RenderMaterial);
    2) Implement this function in DonMeshPaintingHelper.cpp as follows:
    Code:
    UMaterialInstanceDynamic* UDonMeshPaintingHelper::GetCachedRenderMaterial(UObject* WorldContextObject, class UMaterialInterface* RenderMaterial)
    {
        auto globalPainter = GetGlobalManager(WorldContextObject);
        if (!globalPainter)
            return nullptr;
    
        return globalPainter->GetCachedRenderMaterial(RenderMaterial);
    }
    3) 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.
    Last edited by VSZ; 01-23-2019, 12:59 PM.

    Leave a comment:


  • replied
    Hey VSZ


    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.

    Click image for larger version  Name:	square.jpg Views:	1 Size:	13.5 KB ID:	1575621

    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.

    Click image for larger version  Name:	square2.jpg Views:	4 Size:	95.1 KB ID:	1575618

    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:

    Click image for larger version  Name:	square3.JPG Views:	2 Size:	57.4 KB ID:	1575620

    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!

    Leave a comment:


  • replied
    Originally posted by IntervideoFilm View Post
    Hi VSZ

    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.
    Last edited by VSZ; 01-20-2019, 03:55 PM.

    Leave a comment:


  • replied
    Hi VSZ

    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.

    Leave a comment:

Working...
X