Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

  • replied
    Thank you Koderz for your awesome work!

    Is it possible to add support for different rendering modes (wire and point) in runtime? It would be super-awesome for an upcoming project, and maybe for others too.

    Leave a comment:


  • replied
    Very anxiously awaiting the 4.19 update. <3

    Leave a comment:


  • replied
    Which Engine version and plugin version is recommended right now for a new project? Which is most stable and performant?

    Leave a comment:


  • replied
    Any updates on the 4.19 fixes? Holding off on updating a project til this is done

    Leave a comment:


  • replied
    Hi there, I must be doing something wrong, I tried to create a custom vertex type like this:
    DECLARE_RUNTIME_MESH_VERTEX(TexArrayVert, true, true, false, false, 3, ERuntimeMeshVertexTangentBasisType:efault, ERuntimeMeshVertexUVType:efault)

    Then I fill each of these:
    TArray<int32> Triangles;
    TArray<TexArrayVert> testVertices;

    And call this:
    RuntimeMesh->CreateMeshSection<TexArrayVert, int32>(0, testVertices, Triangles, true, EUpdateFrequency::Infrequent, ESectionUpdateFlags::None);

    RuntimeMesh is declared as:
    UPROPERTY(EditAnywhere)
    URuntimeMeshComponent* RuntimeMesh;

    So when I try to load a level (int the editor) with an actor having this CreateMeshSection call in the OnConstruction it crashes out D3D11Util.cpp line 233:
    UE_LOG(LogD3D11RHI, Fatal,TEXT("%s failed \n at %s:%u \n with error %s"),ANSI_TO_TCHAR(Code),ANSI_TO_TCHAR(Filename),Line,*ErrorString);
    Code = Direct3DDevice->CreateInputLayout( InVertexDeclaration && InVertexDeclaration->VertexElements.Num() ? InVertexDeclaration->VertexElements.GetData() : &NullInputElement, InVertexDeclaration ? InVertexDeclaration->VertexElements.Num() : 0, &InVertexShader->Code[ InVertexShader->Offset ], VertexShaderCode.GetActualShaderCodeSize() - InVertexShader->Offset, InputLayout.GetInitReference() )
    Filename = D:\UnrealGitHub\UnrealEngine\Engine\Source\Runtime\Windows\D3D11RHI\Private\D3D11Shaders.cpp
    Line = 257
    ErrorString = E_INVALIDARG

    So this would lead me to think that something is wrong with the setup of the vertex declaration that the DECLARE_RUNTIME_MESH_VERTEX is creating or I'm just completly doing this wrong

    Leave a comment:


  • replied
    Yeah thanks Koderz, love ya work

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    For those of you wondering if I'm going to support 4.19... Yes, but unfortunately it might be a little bit, due to some non-trivial changes in the engine. For more information see here...

    https://github.com/Koderz/RuntimeMes...nent/issues/87
    Thank you for the update Koderz, if there's anything I can do to help let me know!



    Rama

    Leave a comment:


  • replied
    For those of you wondering if I'm going to support 4.19... Yes, but unfortunately it might be a little bit, due to some non-trivial changes in the engine. For more information see here...

    https://github.com/Koderz/RuntimeMes...nent/issues/87

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    So the best solution would be to pretty much rely entirely on the meshbuilder from this point forward and deprecate out all the old API but not sure that's what I want to do. Will have to investigate this more once I have some more time.
    Thank you for letting me know Koderz, and thank you again for your work on the RMC



    Rama

    Leave a comment:


  • replied
    Originally posted by Koderz View Post


    As a warning, this isn't going to be an easy fix, and may require a drastic structural change in how the RMC works. It appears the StaticMesh Rendering now uses 4 independent buffers, {Position}, {Normal/Tangent}, {UVs}, {Color} and each has an associated SRV with their datatype. Since the position/tangents/uvs/colors don't share a datatype I think it might be required to keep them in separate buffers now. This isn't exactly hard to support, and it'd be nearly invisible for anyone using the blueprint API, or the MeshBuilder, but that'd be the end of single/dual/triple buffers and it'd just become a quad buffer full time, so if you set the mesh data with the single array of FRuntimeMeshVertexSimple it'd end up having to split it, so that'd slow that function down a bit, same with dual buffer, same with triple. So the best solution would be to pretty much rely entirely on the meshbuilder from this point forward and deprecate out all the old API but not sure that's what I want to do. Will have to investigate this more once I have some more time.
    Nuts, I'm trying to get a packaged build working of 4.17 with RMC 2 with using light propagation volume, the packaged build doesn't work in 4.17. (This issue: https://issues.unrealengine.com/issue/UE-49205).

    It got fixed for 4.19 but then I can't use RMC, I'm thinking to reproduce the change in 4.17 made to make LPV work, but I've never edited or compiled the engine before, anyone who can deduct what files I'd need to change?

    Edit: I'm trying to just comment out the assert that makes it fail, no idea what it'll do though.
    -> This resulted in the packaged build being able to run, but lpv didn't work. Guess I'm waiting for 4.19 then.

    When opening my project I get a message stating that I need to rebuild the RMC plugin, after agreeing it rebuilds the entire engine, how do I prevent that behaviour?
    Last edited by housekiller; 03-13-2018, 11:33 AM.

    Leave a comment:


  • replied
    Originally posted by Rama View Post
    4.19 of Pre Version 3 or after Version 3?

    Anyone have a working version of RMC for 4.19, possibly even pre-version 3?

    I tried to do the update but I am getting a crash on attempt to access the tangent data:

    Code:
    void FLocalVertexFactoryShaderParameters::SetMesh(FRHICommandList& RHICmdList, FShader* Shader, const FVertexFactory* VertexFactory, const FSceneView& View, const FMeshBatchElement& BatchElement, uint32 DataFlags) const
    {
    SetSRVParameter(RHICmdList, VS, VertexFetch_PackedTangentsBufferParameter, LocalVertexFactory->GetTangentsSRV());
    I presume I have to indicate somehow when tangent data is not present

    Someone made an issue related to this:
    https://github.com/Koderz/RuntimeMes...nent/issues/87

    I know Koderz mentioned making a 4.19 branch, I was hoping to not pressure him and see if we could figure it out while waiting



    Rama

    As a warning, this isn't going to be an easy fix, and may require a drastic structural change in how the RMC works. It appears the StaticMesh Rendering now uses 4 independent buffers, {Position}, {Normal/Tangent}, {UVs}, {Color} and each has an associated SRV with their datatype. Since the position/tangents/uvs/colors don't share a datatype I think it might be required to keep them in separate buffers now. This isn't exactly hard to support, and it'd be nearly invisible for anyone using the blueprint API, or the MeshBuilder, but that'd be the end of single/dual/triple buffers and it'd just become a quad buffer full time, so if you set the mesh data with the single array of FRuntimeMeshVertexSimple it'd end up having to split it, so that'd slow that function down a bit, same with dual buffer, same with triple. So the best solution would be to pretty much rely entirely on the meshbuilder from this point forward and deprecate out all the old API but not sure that's what I want to do. Will have to investigate this more once I have some more time.

    Leave a comment:


  • replied
    4.19 of Pre Version 3 or after Version 3?

    Anyone have a working version of RMC for 4.19, possibly even pre-version 3?

    I tried to do the update but I am getting a crash on attempt to access the tangent data:

    Code:
    void FLocalVertexFactoryShaderParameters::SetMesh(FRHICommandList& RHICmdList, FShader* Shader, const FVertexFactory* VertexFactory, const FSceneView& View, const FMeshBatchElement& BatchElement, uint32 DataFlags) const
    {
    SetSRVParameter(RHICmdList, VS, VertexFetch_PackedTangentsBufferParameter, LocalVertexFactory->GetTangentsSRV());
    I presume I have to indicate somehow when tangent data is not present

    Someone made an issue related to this:
    https://github.com/Koderz/RuntimeMes...nent/issues/87

    I know Koderz mentioned making a 4.19 branch, I was hoping to not pressure him and see if we could figure it out while waiting



    Rama
    Last edited by Rama; 03-13-2018, 02:04 AM.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post

    Hey Rama,

    I've applied those unity build fixes duke22 did several commits back. Granted I haven't tested it again since I added a couple things, but I'll check that later if I have some time.

    Right now v3 should run fine on 4.17 and 4.18. I have a local branch for 4.19 since some RHI stuff changed but that should show up on GH soonish. As far as I know it will compile fine for windows/linux/html5. I don't have the ability to test mobile/console so can't guarantee those. What platform/compiler are you using that's complaining about 16-bit alignment? If you can send me the error output I'll gladly take a look.
    Hi there! Thank you for the reply Koderz

    Sorry for the confusion, I was compiling the RMC plugin using the Clang workflow that is used to compile plugins for Marketplace distribution, and I had to modify the build.cs of the RMC modules to negate the -iwyu flag that the UE4 CLang batch file defaults to:

    Code:
    //Add to build cs's
    PCHUsage = PCHUsageMode.UseSharedPCHs;
    CLang auto-build workflow for UE4 Plugins:

    !!! Make sure to run this batch file inside of an empty folder called PluginStaging, the batch file nukes anything in its path !!!
    Code:
    "C:\Program Files\Epic Games\UE_4.18\Engine\Build\BatchFiles\RunUAT.bat" BuildPlugin -Plugin="E:\YOURPROJECTPATH\Plugins\RuntimeMeshComponent\RuntimeMeshComponent.uplugin" -Package="%CD%\RMC18" -Rocket
    I use this workflow for all my plugins to generate all binaries for a plugin for all platforms I want to support, I was initially told about this tool by Marketplace staff when code plugins first became a thing.

    whitelisting so the batch tool works:

    Code:
    //.uplugin
     "Modules": [
        {
          "Name": "RuntimeMeshComponent",
          "Type": "Runtime",
          "LoadingPhase": "Default",
                "WhitelistPlatforms" :
                [
                    "Win64",
                    "Win32"
                ]
        },
    If I compile RMC as part of my project it works fine

    ~~~

    formal parameter with requested alignment of 16 won't be aligned

    Originally posted by Koderz View Post
    What platform/compiler are you using that's complaining about 16-bit alignment? If you can send me the error output I'll gladly take a look.
    Regarding the 16-bit alignment, I still get those errors when compiling for Win32 using the Clang workflow for plugins, and it errors out on the following:

     
    Spoiler



    Solution:

    The easy solution is to just make sure these parameters become const &

    So here's an example from RuntimeMeshBuilder

    Code:
    FORCEINLINE static void WriteNormalTangentPackedRGBA16N(int32 Index, FVector4 Value, TArray<uint8>* Data, int32 Stride, int32 Offset)
        {
            return Write<FPackedRGBA16N>(Index, Value, Data, Stride, Offset);
        }
    becomes

    Code:
    FORCEINLINE static void WriteNormalTangentPackedRGBA16N(int32 Index, const FVector4& Value, TArray<uint8>* Data, int32 Stride, int32 Offset)
        {
            return Write<FPackedRGBA16N>(Index, Value, Data, Stride, Offset);
        }

    Why It's Important

    The reason this bit alignment matters as far as I know is if anyone is using the RMC plugin on consoles like XBox or shipping win32 builds

    Epic's Ben Marsh explains here:
    https://answers.unrealengine.com/que...ign16-won.html



    Thank you again for the RMC, and thank you for the new version of the RMC you are making, URuntimeMesh for multiple components = awesome!!!



    Rama
    Last edited by Rama; 03-11-2018, 02:46 PM.

    Leave a comment:


  • replied
    Originally posted by alfiare View Post
    Think I got it, though it was a little fun to find. I was calling SetCollisionUseAsyncCooking(true) right after I created the RMC (NewObject<URuntimeMeshComponent>()) figuring I would set it there to be sure. For some reason that doesn't seem to work and the underlying bUserAsyncCooking was getting set from the post load. Seems to work fine if I call SetCollisionUseAsyncCooking(true) right before I call CreateMeshSection.

    Thanks so much for this plugin, I'm coming from Unity and all the infrastructure I had built there around doing this very thing, unreal looks much more promising.
    Yeah there's some usability improvements I want to do to a couple of those things. I don't like the part where I had to move those settings down into URuntimeMesh but that's a side-effect of trying to separate mesh data from the component so multiple components could share it. Glad you got it to work. Not quite sure why that'd be changed in postload, where was that happening? I'm going to try to push a PR to Epic this weekend to solve that issue but that's still likely to take weeks to months to get into a released version of the engine. When I do that though I'll push the PR into my GitHub fork of the engine for anyone willing to compile the engine themselves.

    I might actually force async cook on known engine versions that are broken for synchronous cook. I actually have an idea on a way to get around it, but it's far from ideal and tricky to setup but I might still do it for the interim.

    Btw: Welcome to UE4! I gave up on Unity for this type stuff a long time ago simply because I couldn't make it do what I wanted!

    Leave a comment:


  • replied
    Think I got it, though it was a little fun to find. I was calling SetCollisionUseAsyncCooking(true) right after I created the RMC (NewObject<URuntimeMeshComponent>()) figuring I would set it there to be sure. For some reason that doesn't seem to work and the underlying bUserAsyncCooking was getting set from the post load. Seems to work fine if I call SetCollisionUseAsyncCooking(true) right before I call CreateMeshSection.

    Thanks so much for this plugin, I'm coming from Unity and all the infrastructure I had built there around doing this very thing, unreal looks much more promising.

    Leave a comment:

Working...
X