Announcement

Collapse
No announcement yet.

❀ DoN's Dynamic Mesh Effects ❀

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

  • replied
    I did some extensive testing of the different settings and between the Windows and HTML5 platforms and with two versions of the same model. I'm using a basic helmet model that originally had two sides with a thin separation between them. I noticed some bleeding from painting from one side to the other and some of the decal/stamping being applied to the inside when I clicked on the outside. I duplicated the mesh and deleted the inside polygons for further testing.



    Helmet with two sides:
     
    Spoiler



    Helmet with one side:
     
    Spoiler




    Originally posted by VSZ View Post
    @DanimalsOnParade

    Question 2. (HTML5)
    (For other readers - please note that HTML5 is not currently supported. This discussion is more of a feasibility study at this point; Of course I would love to support as many platforms as possible, where feasible)

    Going by your description your test subject sounds like a static mesh using the fast-path (Collision UVs). That would explain the brush-size discrepancy as brush size is fully UV-island dependent in the fast-path.

    It sounds like Lightmap projection (seamless workflow) is not working in HTML5.

    The most obvious suspect here is the Scene Capture component used to capture position UVs. If you can do a quick test with any Scene Capture in HTML5 we can confirm that theory straight away.

    I added a SceneCaptureComponent2D to my helmet but I don't know what else to do with it. It compiled fine and I saw no errors in the log in the HTML5 build.
    Last edited by DanimalsOnParade; 09-05-2017, 10:38 PM.

    Leave a comment:


  • replied
    @DanimalsOnParade
    Question 1. (Text-stamping)
    For static meshes, first thing to check is whether you are using the "fast-path" (Collision UVs) or the regular( lightmap-UV) path.

    Go to Project->Phyiscs Settings->Support UV from Hit Results.

    Now if this setting is true, you are using the fast-path; if so, ensure that your "Trace Complex" is set to true for your line-trace/sweep when you are generating your HitResult. This step is only necessary for static meshes leveraging the fast-path.

    If it's not, then you are using standard Lightmap projection and in that case, we need to understand why the projection logic is failing. If you are using the UV1 node, check whether you have supplied a proper UV1 channel.

    Question 2. (HTML5)
    (For other readers - please note that HTML5 is not currently supported. This discussion is more of a feasibility study at this point; Of course I would love to support as many platforms as possible, where feasible)

    Going by your description your test subject sounds like a static mesh using the fast-path (Collision UVs). That would explain the brush-size discrepancy as brush size is fully UV-island dependent in the fast-path.

    It sounds like Lightmap projection (seamless workflow) is not working in HTML5.

    The most obvious suspect here is the Scene Capture component used to capture position UVs. If you can do a quick test with any Scene Capture in HTML5 we can confirm that theory straight away.


    Let me know!

    Leave a comment:


  • replied
    I'm having some trouble getting the UMG Text Tattooing feature to work correctly with my simple static mesh of a basic helmet in my Windows game. Painting and decal stamping work perfectly. Text tattooing only stamps the text on part of the model regardless if I use a FHitResult or use a socket. I'm attaching some images so maybe you can help me figure out what I'm doing wrong. I'm using the Mesh UV1 workflow. UV0 has the same issue.

    Material. Painting is on Layer 0, decal stamping is on Layer 1, and text tattooing is on Layer 2. They lead into the BaseColor. I'm only using solid red for my text color.-

    Click image for larger version  Name:	material.png Views:	2 Size:	103.9 KB ID:	1348185

    Blueprint code-

    Click image for larger version  Name:	blueprint.png Views:	2 Size:	130.8 KB ID:	1348186

    Render target of running game with text "Hello!" stamped as much as I can on the static mesh. I think the RT would match up with the uvs which doesn't seem to be the case.

    Click image for larger version  Name:	render_target.png Views:	1 Size:	48.8 KB ID:	1348187

    UV1 from the static mesh. The seam is on the edge so that the outside and inside are separate solid pieces-

    Click image for larger version  Name:	uvs.png Views:	1 Size:	546.7 KB ID:	1348188

    I hope you can help, thanks!
    Last edited by DanimalsOnParade; 09-03-2017, 08:51 PM.

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    Try this:

    1. Find the plugin inside <Your4.17Engine>/Plugins/Marketplace/DonMeshPainting
    2. Move that folder to your own project's "Plugins" directory (Create a new "Plugins" directory if you don't already have one)
    3. Delete the Binaries and Intermediate folders inside the DonMeshPainting plugin.
    4. Open the file DonMeshPainting.uplugin and inside "WhitelistPlatforms" try adding "HTML5" to the array (this part is only a guess, never tried it myself).
    4. Open Visual Studio and compile your project again. It should now compile the plugin afresh.

    Assuming your HTML5 issue was indeed related to compilation then this might help.
    Got it to work! Thank you sir!

    Moving the plugin into the Unreal Project Plugins folder from the Engine Plugins folder allowed me to compile the plugin into *.bc. However, I had to stay with the Blueprint method (delegate from C++). If I include the DonMeshPaintingHelper.h, it still throws the error saying it can't find the *.generated.h file. But that's fine, I can live with the C++ Delegate to Blueprint way of calling the plugin.

    Don_Mesh_Paint_UV1 won't work at all in HTML5. However, Don_Mesh_Paint_UV0 does work! But it's UV coordinates are flipped in the HTML5 build. That's simple to fix. I'm not sure why Don_Mesh_Paint_UV1 won't work but I think it may use too many render targets. It's something related to the render targets anyway.

    Don_Mesh_Paint_UV0's brush size seems to be about 5x bigger than Don_Mesh_Paint_UV1. Is that just because of differences in the UV0 and UV1 channels? The UV islands are a bit smaller on the automatically computed UV1 map.

    I'm looking forward to the undo infinite stroke history update!

    Leave a comment:


  • replied
    Try this:

    1. Find the plugin inside <Your4.17Engine>/Plugins/Marketplace/DonMeshPainting
    2. Move that folder to your own project's "Plugins" directory (Create a new "Plugins" directory if you don't already have one)
    3. Delete the Binaries and Intermediate folders inside the DonMeshPainting plugin.
    4. Right click on your uproject file and choose "Generate Project Files". This will register the plugin with your project.
    --
    5. Open the file DonMeshPainting.uplugin and inside "WhitelistPlatforms" try adding "HTML5" to the array (this part is only a guess, never tried it myself).
    6. Repeat step 4.
    7. Open Visual Studio and compile your project again. It should now compile the plugin afresh.

    Assuming your HTML5 issue was indeed related to compilation then this might help.
    Last edited by VSZ; 09-08-2017, 09:22 AM.

    Leave a comment:


  • replied
    Some observations -

    I can't package the project for HTML5 if I have

    Code:
    PublicDependencyModuleNames.AddRange(new string[] { "DonMeshPainting" });
    It will only work if I use the Blueprints. Packaging for HTML5 with that line gives the following error:

    Code:
    UATHelper: Packaging (HTML5): UnrealBuildTool: ERROR:root:C:\Program Files\Epic Games\UE_4.17\Engine\Plugins\Marketplace\DonMeshPainting\Binaries\HTML5\UE4-DonMeshPainting.bc: No such file or directory ("C:\Program Files\Epic Games\UE_4.17\Engine\Plugins\Marketplace\DonMeshPainting\Binaries\HTML5\UE4-DonMeshPainting.bc" was expected to be an input file, based on the commandline arguments provided)
    I guess it's looking for the plugin to be compiled beforehand which I don't have.

    If I include DonMeshPaintingHelper.h in addition to PublicDependencyModuleNames I get this error

    Code:
    UATHelper: Packaging (HTML5): UnrealBuildTool:   C:\Program Files\Epic Games\UE_4.17\Engine\Plugins\Marketplace\DonMeshPainting\Source\DonMeshPainting\Classes\DonMeshPaintingDefinitions.h(8,10): error: 'DonMeshPaintingDefinitions.generated.h' file not found
    UATHelper: Packaging (HTML5): UnrealBuildTool: ../Plugins/Marketplace/DonMeshPainting/Source/DonMeshPainting/Classes/DonMeshPaintingDefinitions.h:8:10: fatal error: 'DonMeshPaintingDefinitions.generated.h' file not found
    UATHelper: Packaging (HTML5): UnrealBuildTool: #include "DonMeshPaintingDefinitions.generated.h"
    UATHelper: Packaging (HTML5): UnrealBuildTool:          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    UATHelper: Packaging (HTML5): UnrealBuildTool: 1 error generated.
    UATHelper: Packaging (HTML5): UnrealBuildTool: ERROR:root:compiler frontend failed to generate LLVM bitcode, halting

    When using just the Blueprints which doesn't need that PublicDependencyModuleNames line or DonMeshPaintingHelper.h, it packages for HTML5 just fine but the log from running it says

    Code:
    LogStreaming: Error: Couldn't find file for package /Script/DonMeshPainting requested by async loading code. NameToLoad: /Script/DonMeshPainting
    [2017.09.01-19.17.15:518][ 0]LogStreaming: Error: Couldn't find file for package /Script/DonMeshPainting requested by async loading code. NameToLoad: /Script/DonMeshPainting
    This leads me to believe that I need the compiled plugin regardless of using Blueprints or C++ for an HTML5 build. Did you provide the Win64/Win32 binaries of the plugin or was that something that we compiled when we installed the plugin? Any idea on how I could compile the plugin for HTML5?

    Leave a comment:


  • replied
    Originally posted by VSZ View Post

    Does HTML5 support Render Targets in Unreal? That's really the only dependency I can think of.

    The plugin doesn't impose any rendering limitations on you as it is effectively a "runtime mask generator" that doesn't know/care about what shader model the target materials will use. I've listed only Windows as that's the only platform the marketplace version of the plugin has been tested on. For my project (which uses an older code base from which this plugin was made!) I'm running it it on Linux as well.

    PS: Check the logs as well, there may be a tell-tale clue in there


    According to the 4.16 release notes, it should -

    UE 4.16 also adds support for WebGL 2.0 which is based on OpenGL ES 3.0 and provides more optimal rendering performance, increased visual fidelity, and support for more rendering features, including:
    • Most features of UE4's high-end mobile feature level
    • Instanced Geometry Drawing for particles and foliage
    • Support for Multiple Render Targets (MRTs)
    • Texture features such as 3D or volume textures, 2D array textures, and no more non-power-of-two texture restrictions
    https://docs.unrealengine.com/latest...aseNotes/4_16/

    I'll do some more digging to see if I can find out how to get a log from the HTML5 platform. I'll report back if I can find anything!

    Leave a comment:


  • replied
    Originally posted by DanimalsOnParade View Post
    I know you only support Windows, but do you have an idea if it's possible to make the plugin work with Feature Level ES 3.0?
    Does HTML5 support Render Targets in Unreal? That's really the only dependency I can think of.

    The plugin doesn't impose any rendering limitations on you as it is effectively a "runtime mask generator" that doesn't know/care about what shader model the target materials will use. I've listed only Windows as that's the only platform the marketplace version of the plugin has been tested on. For my project (which uses an older code base from which this plugin was made!) I'm running it it on Linux as well.

    PS: Check the logs as well, there may be a tell-tale clue in there

    Leave a comment:


  • replied
    Originally posted by VSZ View Post
    @DanimalsOnParade
    You just need to include the plugin's module as a dependency in your project's build.cs file (eg: YourProject.Build.cs)

    Like so:
    Code:
    // Your engine dependencies (example)
    PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine"});
    
    // Your plugin dependencies:
    PublicDependencyModuleNames.AddRange(new string[] { "DonMeshPainting"});
    After that you will be able to use the headers simply as:
    Code:
    #include "DonMeshPaintingHelper.h"
    That header should be sufficient for an end-user to access the API.

    Any other questions, let me know!
    That seems to have worked, thanks! I also got it to work with using a delegate in C++ to call an event in Blueprint.

    I know you only support Windows, but do you have an idea if it's possible to make the plugin work with Feature Level ES 3.0? I've got an idea for a nice "companion app" with painting in an HTML5 game that would hook into the existing backend for the full game. My little test project compiles and packages for HTML5 just fine but no paint is applied to the model when testing in a browser (Chrome and Firefox). Testing in the editor and win64 builds work / paint just fine.

    WebGL 2.0 is supposed to be on feature parity with OpenGL ES 3.0. There's not a Preview Level for ES3.0 in the Editor yet, but testing on ES3.1 works perfectly whereas ES2.0 fails. Not sure if that helps but the disconnect is somewhere between OpenGL ES 3.0 and 3.1.

    I would love to be able to add this companion app, but I understand if you can't get it to work since you only support Windows.

    Leave a comment:


  • replied
    @DanimalsOnParade
    You just need to include the plugin's module as a dependency in your project's build.cs file (eg: YourProject.Build.cs)

    Like so:
    Code:
    // Your engine dependencies (example)
    PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine"});
    
    // Your plugin dependencies:
    PublicDependencyModuleNames.AddRange(new string[] { "DonMeshPainting"});
    After that you will be able to use the headers simply as:
    Code:
    #include "DonMeshPaintingHelper.h"
    That header should be sufficient for an end-user to access the API.

    Any other questions, let me know!
    Last edited by VSZ; 08-31-2017, 01:53 AM.

    Leave a comment:


  • replied
    I picked up the 4.16 version from the Marketplace so that I can test while I wait for 4.17 but I'm having trouble figuring out how to use the C++ API. What exactly should I #include in my C++ files?

    Code:
    #include "DonMeshPaintingHelper.h"
    Throws errors saying that it can't find that file.

    Code:
    #include "../Plugins/Marketplace/DonMeshPainting/Source/DonMeshPainting/Classes/DonMeshPaintingHelper.h"
    Throws an error saying it can't find the DonMeshPaintingHelper.generated.h.

    I have access to the Blueprint nodes so I think it's installed and enabled correctly. Sorry if I just blindly missed some important piece on the Knowledge Base about installation / C++ setup!

    Leave a comment:


  • replied
    Hey, I've seen other sellers report anywhere between 2-3 weeks for their updates to be processed (mine was sent on 20th of August).

    For this plugin I sent them three updates in all (4.17, 4.16, 4.15) so there's probably more testing work for them here than the other updates too.,,

    In any case I"ll reach out to them in while I'd also sent new images for the marketplace gallery that I was really keen on seeing out there!

    Leave a comment:


  • replied
    Any updates on the 4.17 update?

    Leave a comment:


  • replied
    Awesome, thanks for the tips! Still waiting... Epic please!

    Leave a comment:


  • replied
    Btw, since you mentioned decals/text I'm assuming you've read the known limitations kb page on them already. To quickly recap:
    • Seamless projection of decals/text is only supported for planar world-space/local-space painting.
    • For 3D mesh-space projection, only circular brush strokes are seamless; decal/text projection is entirely UV island dependent, making careful UV1 (lightmap) preparation a must.
    Now most gampeplay situations can get around that, but for a free-mode paint app like yours, this is a very important limitation to be aware of because yours users can presumably paint anywhere.

    Well worth noting!

    Leave a comment:

Working...
X