It all depends on how you build your baker, virtually any desired combination should be possible with the right setup.
Recommend looking up the “Unwrap UVs for Render Node” and playing around with an orthographic scene capture so you get an idea of the technique.
No such worries, you’re in complete control of the effects and what channels they influence.
You’re in control because what the users paint is always just a mask not the effect. The advantage of this is that you can read the mask and blend in virtually anything you like - be it peeling off damage textures beneath (for impact damage), or for painting just one diffuse channel (paint app usecase like yours) even multiple channels (diffuse/normal/what-not) for those who need it.
[/QUOTE]
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.
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?
#include "DonMeshPaintingHelper.h"
Throws errors saying that it can’t find that file.
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!
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.
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
It will only work if I use the Blueprints. Packaging for HTML5 with that line gives the following error:
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
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
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?
Find the plugin inside <Your4.17Engine>/Plugins/Marketplace/DonMeshPainting
Move that folder to your own project’s “Plugins” directory (Create a new “Plugins” directory if you don’t already have one)
Delete the Binaries and Intermediate folders inside the DonMeshPainting plugin.
Right click on your uproject file and choose “Generate Project Files”. This will register the plugin with your project.
–
Open the file DonMeshPainting.uplugin and inside “WhitelistPlatforms” try adding “HTML5” to the array (this part is only a guess, never tried it myself).
Repeat step 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.
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!
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.-
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.
@DanimalsOnParade [HR][/HR]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.
[HR][/HR]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.
[HR][/HR]
Let me know!
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:
https://i.imgur.com/wkF0VVr.jpg
Windows
Support UV from Hit Results ON
Trace Complex ON
UV0
Painting works. No bleeding. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting works. Paint bleeds to opposite side.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Trace Complex OFF
UV0
Painting works. No bleeding. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting works. Paint bleeds to opposite side.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Support UV from Hit Result OFF
Trace Complex ON
UV0
Painting works. Paint bleeds to opposite side. Brush same size as UV1.
Decals and text stamp perfectly except where the distance between the outside and inside walls is too small and it stamps on the other side instead of the side I click on.
UV1
Painting works. Paint bleeds to opposite side.
Decals and text stamp on the inside wall of the helmet when I click anywhere on the outside.
Trace Complex OFF
UV0
Painting works. Paint bleeds to opposite side. Brush same size as UV1.
Decals and text stamp perfectly except where the distance between the outside and inside walls is too small and it stamps on the other side instead of the side I click on.
UV1
Painting works. Paint bleeds to opposite side.
Decals and text stamp on the inside wall of the helmet when I click anywhere on the outside.
HTML5
Support UV from Hit Result ON
Trace Complex ON
UV0
Painting works. No bleeding. Brush is 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting does not work.
Decals stamp but not where I click.
Text stamping only works on a small portion of the mesh and is slightly off from where I click (same as UV0).
Trace Complex OFF
UV0
Painting works. No bleeding. Brush is 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting does not work.
Decals stamp but not where I click.
Text stamping only works on a small portion of the mesh and is slightly off from where I click (same as UV0).
Support UV from Hit Result OFF
Trace Complex ON
UV0
Painting only paints in a straight weird line, not where I click.
Decals and text stamp only on a tiny part of the mesh and not where I click.
UV1
Painting does not work.
Decals and text stamp not where I click.
Trace Complex OFF
UV0
Painting only paints in a straight weird line, not where I click.
Decals and text stamp not where I click.
UV1
Painting does not work.
Decals and text stamp not where I click.
Helmet with one side:
https://i.imgur.com/rlOiVk2.jpg
Windows
Support UV from Hit Result ON
Trace Complex ON
UV0
Painting works. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting works.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Trace Complex OFF
UV0
Painting works. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting works.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Support UV from Hit Result OFF
Trace Complex ON
UV0
Painting works. Brush same size as UV1.
Decal and text stamping work perfectly.
UV1
Painting works.
Decal and text stamping work perfectly.
Trace Complex OFF
UV0
Painting works. Brush same size as UV1.
Decal and text stamping work perfeclty.
UV1
Painting works.
Decal and text stamping work perfectly.
HTML5
Support UV from Hit Result ON
Trace Complex ON
UV0
Painting works. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting does not work.
Decals stamp not where I click.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Trace Complex OFF
UV0
Painting works. Brush 5x the size of UV1.
Decal stamping works perfectly.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
UV1
Painting does not work.
Decals stamp not where I click.
Text stamping only works on a small portion of the mesh and is slightly off from where I click.
Support UV from Hit Result OFF
Trace Complex ON
UV0
Painting does not work.
Decals and text stamp not where I click.
UV1
Painting does not work.
Decals and text stamp not where I click.
Trace Complex OFF
UV0
Painting does not work.
Decals and text stamp not where I click.
UV1
Painting does not work.
Decals and text stamp not where I click.
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.
For testing this you need to invoke “CaptureScene” on the scene capture component and see whether a texture/RT is generated. Doesn’t matter where your camera is facing, we’re interested in knowing whether scene captures work in HTML5 at all; compilation is not the issue here btw.
For your other query I'll get back to you - that's a lot of information to process :)
Thanks for the detailed report! Let’s track HTML5 feasibility separately to allow for focus on the core issues first.
Questions:-
Are you using the latest 4.17 version? That has some changes to the way UV0, UV1 nodes work for static meshes.
Do you have a screenshot of both your UV0 and UV1 channels? (think you included UV1 only)
Clarifications:-
* **Brush size difference** for static meshes on UV0 ("fast path") is expected. This is a typical limitation of collision UV projection.
* **"Splashing" effect** between inner/outer faces happens in UV1 (seamless workflow) because it uses a world-distance based brush that indiscriminately paints any pixels that satisfy the distance criterion (brush size). This makes it great for seamless painting, but to make it work for a two-sided helmet we'd need some mechanism that uses the "Impact Normal" of your Hit Result and compares that with the "Pixel normals" of the helmet to filter out the inner or outer faces by a tolerance factor. This will have to be investigated as a separate feature.
* There's no point turning off "Support UV from Hit Result" if you're using UV0 with a static mesh. I'm surprised that even worked. The 4.17 version blocks users from even trying that. Similarly, "TraceComplex" only matters when Support UVs is on, you don't need to bother about it if it isn't.
Issues observed:-
#1 - Text projection via Fast path for static meshes:
A) Try the 4.17 version, I’ll try to reproduce this locally as well.
#2 - Two-sided helmet decal/text projection:
A) Need to see both your UV0 and UV1 to get a better picture. Shelled meshes haven’t been tested much so it may be possible we’re running into an edge case. UVs will help verify.
Yes I am using 4.17. I immediately switched over (started a new project too) when the plugin update was released.
Here’s UV0 for the double sided helmet:
http://i.imgur.com/Ye37qiZ.jpg
UV1 from double sided helmet (automatically computed by UE4 when I imported the mesh):
http://i.imgur.com/ss5NO5n.jpg
UV0 for single sided helmet:
http://i.imgur.com/KlVTIpi.jpg
UV1 for single sided helmet (automatically computed by UE4 when I imported the mesh):
http://i.imgur.com/QxZ8KQk.jpg
It’s weird that Support UV from Hit Result being ON makes the text stamping not work. Getting text stamping to work with Support UV from Hit Result ON would be ideal because then I might be able to get it to work on HTML5 too!
Major Bugfix Available(Text stamping & Static Meshes)
An issue with text stamping for static meshes has been identified, fix is available in this post.
**Scope: **This bug affects only the “fast-path” (Collision UVs) which @DanimalsOnParade explains why you had text projection issues when “Support Collision UVs” was turned on.
Patch Instructions:
Migrate the plugin to your project folder (see this post for details, you only need Steps 1-4)
Open the file <YourProject>/Plugins/DonMeshPainting/Source/DonMeshPainting/Private/DonMeshPaintingHelper.cpp
Go to Line 54 and replace that entire line with the following snippet: FDonPaintStroke stroke = FDonPaintStroke(Hit.ImpactPoint, 1.f, 0.f, Color, Hit.FaceIndex, strokeParams, Text, Style);
Build your project from Visual Studio, the plugin will be recompiled along with it and now carries the fix! [HR][/HR]
I can’t submit these changes to the marketplace yet as Epic has still not officially processed my previous updates from August (thankfully they added the 4.17 files, but none of the accompanying changes and no response to the ticket either!). Besides, the 20-30 day wait time for processing an update is too long IMO for important bugfixes like this.
If you are a plugin user who isn’t familiar with modifying plugins from Visual Studio, just drop a support email (link) for assistance with installing this patch.
I’d also sent new images for the marketplace gallery that I was really keen on seeing out there!
