Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

  • replied
    I've been testing out UE4 for a few months now trying to validate how well it would work for a project. Really like the runtime mesh component and was testing out V3. I can't seem to get collisions to work in a packaged build. Works fine in the editor. I know you said it needs async cooking to work, is there something special I have to do to make that work?

    Thanks!

    Leave a comment:


  • replied
    Originally posted by Rama View Post

    Thank you for doing that duke22

    I couldn't get this to compile though, I got a ton of errors about things not being 16-bit aligned (need use const & for those parameters)


    I also tried the absolute latest on git, and could not get it to compile in 4.17 due to the unity build issues as well as other errors even after I attempted the unity build fixes myself.

    Thank you so much for this plugin Koderz I can't wait to try update 3 when it will compile for 4.17+

    Thanks again!



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

    Leave a comment:


  • replied
    Originally posted by Rama View Post

    Thank you so much for this plugin Koderz I can't wait to try update 3 when it will compile for 4.17+
    I'm probably not using the latest release on github, but I am running V3 in UE 4.18.3.

    Leave a comment:


  • replied
    Originally posted by duke22 View Post
    Did some include fixes in V3

    You probably have unity build on which hides these errors.

    https://github.com/GeorgeR/RuntimeMe...ee/Version3Dev
    Thank you for doing that duke22

    I couldn't get this to compile though, I got a ton of errors about things not being 16-bit aligned (need use const & for those parameters)


    I also tried the absolute latest on git, and could not get it to compile in 4.17 due to the unity build issues as well as other errors even after I attempted the unity build fixes myself.

    Thank you so much for this plugin Koderz I can't wait to try update 3 when it will compile for 4.17+

    Thanks again!



    Rama

    Leave a comment:


  • replied
    Yes that's the fix for the latest 2.0.

    Leave a comment:


  • replied
    The snapshot of the last downloaded from github gives build error:
    RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): error C2228: left of '.GetSelectedObjects' must have class/struct/union
    RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): note: type is 'const IDetailsView *'
    RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): note: did you intend to use '->' instead?

    Replacing . with -> makes it buildable, but leaves doubts...

    Leave a comment:


  • replied
    Originally posted by Koderz View Post

    What did you mean by splitting out the mesh slicing? btw RMCv2s slicer is pretty broken. I'm working on its replacement and it should be up in the next day or two hopefully.
    Oh ok i'd never used it before so I didn't know it was broken, i'll leave you to the replacement then!

    Leave a comment:


  • replied
    Originally posted by duke22 View Post

    I can't say I completely understand their reasoning. The people that would use it understand the implementation might change. Anyhow, i'm probably going to split out that mesh slicing you did as a separate plugin that depends on runtimemeshcomponent as I'm going to need that pretty soon

    I really don't get their reasoning to be honest. It's not like things that are exposed on the engine API this release can't be broken next even in the uppermost layers of what people interact with. Each engine version I have to change a few things in the RMC, in 4.18 for example they changed a return reference to a pointer. I expect this type stuff, especially in the lower levels of the rendering subsystems. I had plans of upgrading the slicer to directly slice a distance field which means you still have all the distance field support for meshes you go hacking apart with the slicer. After that I was planning the utilities needed to do full runtime generation of distance fields. All of that got put on hold until either they decide to accept it (or open it up in a way they'd prefer) or I get some other things done that more people can use and then come back to it since that will take a source compile of the engine with that PR to allow it.

    What did you mean by splitting out the mesh slicing? btw RMCv2s slicer is pretty broken. I'm working on its replacement and it should be up in the next day or two hopefully.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post

    Hey, will take a look at that. Always forget about UBT hiding some stuff like that.




    Both current versions should I think but I haven’t tested it in a while.




    Currently, no it’s not. This is something I want to add but it’s not trivial and right now also isn’t possible. I tried a few months back to get Epic to accept a couple very minor engine changes that would allow it but unfortunately they rejected them. Here’s the PR if you’d like to see more info on that.
    https://github.com/EpicGames/UnrealEngine/pull/4125

    I can't say I completely understand their reasoning. The people that would use it understand the implementation might change. Anyhow, i'm probably going to split out that mesh slicing you did as a separate plugin that depends on runtimemeshcomponent as I'm going to need that pretty soon

    Leave a comment:


  • replied
    Originally posted by Koderz View Post

    Both current versions should I think but I haven’t tested it in a while.
    Hey Koderz,

    i had a quick look into the RuntimeMeshComponent.cpp and found this section
    Code:
    #if ENGINE_MAJOR_VERSION == 4 && ENGINE_MINOR_VERSION >= 13
    
    // See if we should copy UVs
    
    bool bCopyUVs = UPhysicsSettings::Get()->bSupportUVFromHitResults;
    if (bCopyUVs)
    {
    CollisionData->UVs.AddZeroed(1); // only one UV channel
    }
    #endif
    so my guess is that it the collision should have the neccessary UV information for a UV trace. I'm on 4.18 on MacOS, support uv from hit in project settings is enabled and working on simple static meshes.

    Whatever i do though, i can't get it to show anything else than 0,0. I tried using non overlapping UVs in 0-1 space, swapping through all sorts of collision settings on the "Add RMC" blueprint node. Do you have any idea what i could be doing wrong? Do you know if Normals/Tangents have to be setup up correctly for the UV Trace to work?

    What i am doing is creating multiple RMCs with a single mesh section each within a simple blueprint Actor.


    EDIT: Quick follow-up:
    I made a very simple setup of just a box in an empty BP Actor and Create Box Mesh

    Click image for larger version

Name:	Bildschirmfoto 2018-02-20 um 12.57.04.png
Views:	92
Size:	135.3 KB
ID:	1431619

    The Procedural Mesh component works flawlessly whereas the Runtime Mesh component doesn't return the UVs on LineTrace. Any clue what could be causing this?


    EDIT 2: The Simple Box Setup from the first edit was created inside the Construction Script.
    Doing the Geometry Creation on BeginPlay in the EvenGraph stops both, RMC and PMC from returning UVs.
    Attached Files
    Last edited by a_prototype; 02-20-2018, 08:55 AM.

    Leave a comment:


  • replied
    Originally posted by duke22 View Post
    Did some include fixes in V3

    You probably have unity build on which hides these errors.

    https://github.com/GeorgeR/RuntimeMe...ee/Version3Dev
    Hey, will take a look at that. Always forget about UBT hiding some stuff like that.


    Originally posted by a_prototype View Post
    Thanks Koderz! Still on the previous version as i can't afford anything to break right now - looking forward to give 3.0 a testrun though.

    On a different note: i couldn't find any info on this but i am wondering if the runtime mesh component supports getting UVs from Hit results? I couldn't get it to work right away.
    Both current versions should I think but I haven’t tested it in a while.


    Originally posted by duke22 View Post
    Is it possible for RMC to generate a distance field for itself?
    Currently, no it’s not. This is something I want to add but it’s not trivial and right now also isn’t possible. I tried a few months back to get Epic to accept a couple very minor engine changes that would allow it but unfortunately they rejected them. Here’s the PR if you’d like to see more info on that.
    https://github.com/EpicGames/UnrealEngine/pull/4125


    Leave a comment:


  • replied
    Is it possible for RMC to generate a distance field for itself?

    Leave a comment:


  • replied
    Thanks Koderz! Still on the previous version as i can't afford anything to break right now - looking forward to give 3.0 a testrun though.

    On a different note: i couldn't find any info on this but i am wondering if the runtime mesh component supports getting UVs from Hit results? I couldn't get it to work right away.

    Leave a comment:


  • replied
    I was able to solve my issues, I'll post here what I did wrong so others may be helped.

    Originally posted by housekiller View Post
    Another more annoying issue I'm having with v2; I'm using:
    runtimeMesh->CreateMeshSection(meshSectionInt, vertices, triangles, normals, texMap, vertexColors, tangents, false, EUpdateFrequency::Frequent);

    I run that in a loop that adds +1 to meshSectionInt every loop.

    The problem is that I end up with only 1 object, where i expect about 150 of them. Only the last object is in the runtime mesh. Any idea what I'm doing wrong here?
    I kept overwriting my variables which created the object, thus I created the last object many times over.

    Originally posted by housekiller View Post
    Edit:
    I seem to have misunderstood the inner workings, I though I could add pieces to a runtime mesh by calling createmeshsection multiple times for the same runtimemeshcomponent.

    I have an actor that wants to create multiple meshes for itsself with different materials, how is it best to create multiple URuntimeMeshComponent instances? Any example with a piece of code? Or do I need to create an actor per mesh?
    Working with sections works like a charm, my problem was that I kept creating new objects and did a CreateMeshSection for each of them.

    Originally posted by housekiller View Post
    When making an extra component during runtime I can't even get a mesh in it to show up for some reason, I can only get it to work if the component already exists when the actor is created. Any clues?
    Solved by using RegisterComponent() after creating a new object in the actor. This is how I create the empty objects;

    URuntimeMeshComponent* newComp = NewObject<URuntimeMeshComponent>(this, objectName);
    newComp->RegisterComponent();

    Leave a comment:


  • replied
    housekiller if I remember right, mesh sections are indexed. read the wiki, its explained there. if you want to manipulate or create one of the sections, you always have to specify the index you want to work at

    Leave a comment:

Working...
X