This question was created in reference to: [ProceduralMesh can’t output to the [Content removed]
Hey! I’ve been trying to generate a top down mask from some dynamic meshes created through PCG, but couldn’t figure out why it doesn’t work. I’m pretty sure I’ve setted up things properly; I tried both running a post process function that does the setup work, but also tried to run an in editor callable function after the generation. In both scenarios, the Static Draw Path doesn’t seem to feedback with the RVT info. I copied all my materials to regular static meshes to make sure that the RVT setup was correct and indeed a basic static mesh actor / component does work. I’m wondering if I might be missing something really obvious or not. I also looked at GitHub recent CLs related to those things (BaseDynamicMesh, etc…) without luck.
Any clue could b
[Attachment Removed]
Hello,
Thank you for reaching out.
I’ve been assigned this issue, and we will be looking into drawing the generated meshes in RVTs for you.
Can you please send us a minimal test project that demonstrates your setup?
The guide for test projects:
[Content removed]
[Attachment Removed]
Hello Stephen!
So I booted an empty 5.7 project (we are ourselves on 5.6, but custom build of the engine) and for some reasons, I managed to make it work, but with the dynamic draw path? I thought only the static draw path had access to the RVT? There is seemingly something weird going on. My setup is pretty simple: the PCG graph spawns a dynamic mesh from a static mesh, then the BPA_ runs a post process function that setup all that is needed for the RVT to work (adding the proper target, draw path). I also used custom prim data as an example with regular static meshes to double check my setup is working properly with the mask4 pin.
[Image Removed]
[Attachment Removed]
I zipped the upper-mentionned project from 5.7, I’ll try to repro the same setup in 5.6 too, maybe I’m missing a cherry pick from 5.7 to make it work, but again, I wonder now, why does the dynamic path works? Clearly there is some misconception somewhere. Thank you!
[Attachment Removed]
Ok so I finally found the CL from 5.7 that fixes the issue. I’ll try to integrate it myself as we don’t intent to further change our engine version. Ty! For anyone else stumbling onto this topic, here is the fix: https://github.com/EpicGames/UnrealEngine/commit/49d6b15df034ccc2e6298a9a59d138ef9b7608ad
[Attachment Removed]
Hello Stephen, thank you for the quick response. I’ve attempted to migrate the data, but because we use our own custom engine build solution, the migration seems to fail systematically. I’ll see if I can remake the setup in a bespoke project. In the meantime, hopefully some of your team member might have a clue what is going on. Thank you again!
[Attachment Removed]
Hello,
Thank you for posting the CL you found.
Concerning the Static Draw not drawing into the RVTs, the issue is with the order of operations in your blueprint function.
Unlike dynamic draws, static draws are cached, and do not update every frame. With how your blueprint function “SetupDynMeshData” is built, it implicitly triggers this update before assigning the RVTs to the Primitive.
The function “Set Draw Path” will call “UBaseDynamicMeshComponent::OnRenderingStateChanged(…)”, which marks the render state dirty (the FPrimitiveSceneProxy needing to be recreated).
The functions you use after (setting the RVTs, Custom Primitive Data, and the Draw In Main Pass) do not trigger this. Only “Set Custom Primitive Data” updates render data, and it uses a more efficient path that does not require the FPrimitiveSceneProxy to be recreated.
Moving the “Set Draw Path” to the end of the function call resolved the issue in our tests.
Please let us know if this helps.
[Attachment Removed]