Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

  • replied
    Hi,

    I'm using the plugin through it's sources. The integration into my project works fine for about 3 months. Basically I'm using it to import user data at runtime from files (FBX, SKP, ...). I have to mention that I'm using only the C++ API.

    Since yesterday, I switched from the 4.14.3 version of the engine to the 4.15 version. Since then, when I load user data, no geometry appears on the screen. I checked on my code, everything seems fine.

    The fun fact is that I made a BP creating a RMC and fill it with a simple quad (two triangles). That worked, when I hit play, the quad appears on the screen.

    I stepped into the code, it seems that both my code and the BP I created enters the same methods ...

    Any idea on what changed in 4.15 that may cause this issue ?

    Leave a comment:


  • replied
    Originally posted by gnuchev View Post
    Hi, is there a way to import FBX objects to UE4 (and store it as a .uasset) in a runtime with this tool?
    Not really... The uasset creation tooling doesn't compile into a shipping build. You could in theory load an FBX model at runtime but you'll have to do it manually or use something like Assimp.



    Originally posted by Two-faced View Post
    Have anyone faced bug then RuntimeMeshComponent disappeared after editor reopening? It happens only with one actor. Others save their components.


    I can't say I've seen that. What version of the engine is this?

    Leave a comment:


  • replied
    Have anyone faced bug then RuntimeMeshComponent disappeared after editor reopening? It happens only with one actor. Others save their components.

    Click image for larger version

Name:	2017-03-01_23-14-04.png
Views:	1
Size:	90.8 KB
ID:	1124175

    Leave a comment:


  • replied
    Hi, is there a way to import FBX objects to UE4 (and store it as a .uasset) in a runtime with this tool?

    Leave a comment:


  • replied
    Originally posted by wilberolive View Post
    That is some great news for the plugin.

    In the meantime, is it hard to push a 4.15 update to the marketplace? Even if nothing changes other than putting the compatible version number up. I would love to upgrade my project to 4.15 but RMC is holding me back

    No, actually I thought I submitted it but apparently I never actually sent it! It's now sent so hopefully it will get updated once Epic has time to get it through their update process.

    Leave a comment:


  • replied
    That is some great news for the plugin.

    In the meantime, is it hard to push a 4.15 update to the marketplace? Even if nothing changes other than putting the compatible version number up. I would love to upgrade my project to 4.15 but RMC is holding me back

    Leave a comment:


  • replied
    Wow, very cool. Looking forward to seeing these improvements. I built a hacked lod system that I just got working. It's just 4 sets, each set containing many sub rmcs. And it switches their visibility on /off. Sharing a mesh between rmcs sound amazing.

    Leave a comment:


  • replied
    Upcoming Version 3 Details

    So recently I've been getting quite a few questions and requests from people about when/if a feature was going to be implemented in the RMC. So here's a quick breakdown on what is coming. This list is not everything I want to add, and I also can't guarantee all of this will actually be added or even when it will be done.

    First, the next version (v3) of the RMC is going to be a drastic change. It is almost a 100% overhaul of the entire plugin both to pick up a large set of new features that just don't work well with the current setup as well as to take advantage of things I've figured out about how UE4 operates internally. This means that it WILL NOT BE 100% API COMPATIBLE!! While I'll try to support upgrading to the new version as well as possible, there are some breaking changes in the design.

    The group of new features I'm focused on implementing at the same time are instancing, lod, and sharing a single mesh copy between a several RMCs much like how the static meshes work. To support those the RMC is getting restructured into a setup much like how the UStaticMesh, UStaticMeshComponent and UInstancedStaticMeshComponent work. So there will be a rough equivalent to them being URuntimeMesh, URuntimeMeshComponent, and URuntimeInstancedMeshComponent. The first two, which are needed to replicated what version 2 of the RMC can already do but in the new structure are almost complete at a functional level. They're not up to feature parity of the current RMC and likely won't be for a few weeks. Once they are at least functional I'll mirror that branch to my github repo where you're free to use it if you don't need the other features of the current RMC. I'm hoping to have all of the current features reimplemented on the new RMC within 4 weeks but I don't really know one day to the next how much time I'll really have available to work on it so it might be sooner or it might take longer. When it's complete it should offer a very nice memory improvement to anyone that has multiple copies of the same RMC as well as anyone who needs LOD.



    Now, there's a pretty long list of other things I want to do to the RMC long term which if you look at them as a whole would basically bring as much of the engines features supported by normal static meshes to any runtime generated mesh. There are things that just aren't practical to do at runtime, and those will be obviously be left out, but I hope to bring it as close to feature parity to the normal StaticMesh/ISMC/HISM and possibly even splines/skeletal meshes as is reasonably possible. So here's a starter list, in order of my own priority as to what's coming to the RMC.

    Things I definitely want to do.
    1. Mesh sharing. (Maybe you want 10 copies of the same runtime mesh that can all be moved and handled independently)
    2. Better collision support. (Lessen impact of cooking as much as possible, fully support all simple collision shapes)
    3. LOD (This one is just an obvious performance improvement that's badly needed)
    4. Thread safety of mesh data. (This would allow cross thread read/write of mesh data without worrying about the GC and letting the RMC take care of updating its internal state correctly on the respective threads for you)
    5. Dithered fade in/out of section updates
    6. Instancing (This one is another relatively obvious performance improvement for cases of needing hundreds of the same object)
    7. Distance Field support (This would make the RMC support things like DFAO, or the Distance Field Shadows, or even DFGI if Epic continues on that front at some point)
    8. Load once optimizations (Maybe you just use the RMC to load a model at runtime but never need to change it after that. There's some memory and performance related improvements the RMC could do internally in these cases)
    9. Sub-section updates (Maybe you have a 1m vertex mesh but you only need to update like 1000 of them in one area, why resync the entire mesh to the GPU?)
    10. Brand new slicer designed for the RMC (The slicer in the PMC, while useful, lacks quite a few things that I think would really help. First being simple utilities to directly slice a staticmesh or ISMC/HISMC instance or even spline/skeletal into 1-2 RMC sections without having to manually do all the conversion)
    11. Splines! (Why not be able to spline a runtime mesh?)


    Utility updates as a part of the above:
    1. Brand new mesh builder usable from both c++ and bp that removes the need to work directly with separate arrays like the PMC, and also makes it easier to create efficient meshes.
    2. Upgrade normal/tangent calculation to be able to do hard or smooth normals, and overhaul the algorithm to not be exponentially slower with larger meshes.
    3. More shape creation utilities (Sphere/Capsule/Pyramid/Cylinder etc)
    4. Mesh transformation utility for moving/rotating/scaling something to be combined within a larger mesh.



    Things I'm thinking about:
    1. Skeletal (This one I haven't really investigated but had several requests for and I can see the use for some things)
    2. Networking/Replication support. (This one is one I'd like to see support for just because it'd be an easy way for some people to get multiplayer support for their game but it can easily be 10's of MB of data which isn't exactly a good thing to try to arbitrarily sync across the network. Usually there's a better way to do this, but it's always specific to the project. For example voxel data is almost always smaller than the mesh data it creates. Or in a simpler case a position and radius is a lot less data than a high poly mesh of a sphere)



    I have more things in the works for the RMC, but I'll keep them to myself until they're further along and I'm happy with how they'll actually work before I get anyone's hopes up!

    As always, I'm open to suggestions for other features or changes to existing. Usually the best way to find me is on the UE4 Discord

    Leave a comment:


  • replied
    Originally posted by Thumper View Post
    How can I setup a Collision only section? Am I doing it right by making a normal section and then setting the visibility = false? Thanks for all the information. I'm actually getting close to showing some of what I've been doing with this extraordinary plugin.
    That is one way to do it, but depending on how you configure it when you create it there might be an unnecessary gpu resync performed internally. The best way to do that is via SetMeshCollisionSection() and then ClearMeshCollisionSection() or ClearAllMeshCollisionSections()

    You can see more about those here... https://github.com/Koderz/UE4Runtime....h#L1147-L1156

    Leave a comment:


  • replied
    How can I setup a Collision only section? Am I doing it right by making a normal section and then setting the visibility = false? Thanks for all the information. I'm actually getting close to showing some of what I've been doing with this extraordinary plugin.

    Leave a comment:


  • replied
    Well here goes another long post of replies! Haven't been watching this like I should recently but I'm both here to catch up on answers. In my next post I'll give an update on what's coming.

    Originally posted by pickersZ View Post
    I am currently having some issues with line trace. It seems the collision bounds are different from the odd shape runtimemesh. Is there a way to pass the collision shape to the runtimemesh function?
    You can specify collision shapes, either as a separate mesh, or as one or more convex shapes. Not sure I get what you're having issues with from that image.


    Originally posted by AlexJ16 View Post
    This is long shot but it's worth a try. I started a thread, and hope to get support from others like me using the RMC in the hope that we can convince Epic to give Koderz a dev grant for the work he's done on the RMC.

    I'd like to thank Koderz for the work he's done so far!

    If you use the RMC and think Epic should look into giving Koderz a dev grant, please support it here: https://forums.unrealengine.com/show...or-a-dev-grant
    Originally posted by Vertex Soup View Post
    Just stopping by to say I started to use it and it is great! Thank you very much for such a great free addition [MENTION=141752]Koderz[/MENTION]!
    Thank you both for your support! Glad it was useful to you. It would be amazing to receive a dev grant for the RMC.

    Originally posted by Zireael07 View Post
    Bug report: Trying to #require Components/SplineComponent.h in a project that has this plugin (doesn't have to be the same class that uses RMC) results in a spate of errors from VS:


    Curiously enough, I *can* work with splines and RMC in blueprints.
    Well that's a new one. Did you ever figure this out? I haven't personally tried to use both of them in the same component. Working from blueprint doesn't surprise me since that looks like an include issue within the headers.



    Originally posted by Thumper View Post
    Cool, yeah it just seemed strange is all.



    Yup. The test I mentioned above was pretty straight forward. The exact same mesh was imported into code to be added to a RMC 317 times and it was imported through the editor (FBX) and added to a HISM component in code, and then 317 instances were created. I toggled the Use comlex as simple in the editor imported Static mesh. Then when creating the RMC I did so with collision off. The performance wasn't even close. The order of performance went

    1 = HISM (Visual mesh and Complex collision) = Ran on Oculus Rift perfectly
    2 = RMC (visual mesh, no collision) and HISM (no visual mesh, but with collision) = Ran on Oculus rift, less performant than 1
    3 = RMC (visual mesh with collision) = Could barely run in editor, no need to test in Oculus Rift

    To add to the above I just looked into some other combinations and I discovered more odd behavior. I was curious if there was a difference between setting the HISM visibility to false, and setting the actor holding the HISM component Set Hidden In Game = true; I wondered if this would make the collision of the HISM go away, as you indicated it did not. But, it did further increase the performance while maintaining collision. I was getting around 26 FPS using stat FPS in the editor. With the just mentioned setup, of setting the actor hidden in game, I'm up to 35 FPS steady. The collision is still there. Crazy...
    Not quite sure I see how you set that up but the first things I would question would be this... If you have 317 different sections within an RMC or 317 different RMCs then that's not surprising since that's a large amount of draw calls. If you combined them all into one mesh then you're always drawing all of them no matter what. The HISMC has some internal culling IIRC. As for collision, after the absurd cook time it would take to process all of that on startup it should in theory run ok as I've seen maps with substantially more polys run ok in physx collision. The HISMC wouldn't need to cook anything as it would just have physx instance the same precooked mesh 317 times. So would need to know more about how you set things up before I could really answer why you're getting the performance characteristics you are.

    Originally posted by Zeblote View Post
    The slowdown from collision could be because the runtime mesh create dynamic physx actors by default, so it can't apply fancy optimizations.

    Does it run better if you force it to static after spawning? (using SetMobility method)
    By default the RMC will create mesh collision which is always static as PhysX doesn't support moving collision on polygonal meshes. For standard mesh collision it should have almost identical performance to the standard static mesh after it's cooked, but the cook times can get pretty insane for large meshes (2-20ms)

    Originally posted by Lekyaira View Post
    First off, thanks for this Koderz! This plugin has been a huge help to me.

    Now for a very newb question, I'm sure. Is there a way to get a mesh from the RMC to render in the editor, rather than only at run time?

    As ioFlow already said yeah you can get it to render in editor by creating the mesh in the construction script in bp or cpp. Some times you might have to force tick enable in viewports though IIRC.

    Originally posted by Rikard.Herlitz View Post
    Will this be updated for 4.15 with the new minimal headers etc?
    Honestly, this version I'm only kind of maintaining right now. It will be running on 4.15 soon though. Actually I've already submitted the marketplace update, so that should be up within the next week, and the github version has been updated to support it. I haven't gone through the headers to simplify them though as I'm more focused on the next version (more in my next post).


    Originally posted by edstoica View Post
    any news on LOD support?
    or are there manual ways to assign the unreal LOD system, like to draw a mesh multiple times in different resolutions?

    really need this for our current development.
    we intensly use the PMC to draw loads of meshes in VR. but in bigger worlds, all the distant meshes easily add up to 1 million+ vertices which drops fps.
    just can't handle all the vertices without LOD support...

    I'll answer the first part in my next post as to what's coming. It's definitely coming, but it's not here quite yet. As for a temporary measure, the way I've seen several people do it is just manually track it and turn visibility on/off on separate sections for each LOD. It works, but you don't get things like dithering or even the likely more efficient LOD management the engine can do for you.


    Originally posted by Thumper View Post
    I've just implemented my own LODs, but I am curious about how one could get the dither blending? Also, I saw on the marketplace page some description about collision only sections. How can I do that. Currently I just duplicate the visual mesh and then set that section to no visible.
    I think you can actually do dithered fade yourself within a material, but it means manually managing it. Again, see the next post for what's coming.

    Leave a comment:


  • replied
    I've just implemented my own LODs, but I am curious about how one could get the dither blending? Also, I saw on the marketplace page some description about collision only sections. How can I do that. Currently I just duplicate the visual mesh and then set that section to no visible.

    Leave a comment:


  • replied
    any news on LOD support?
    or are there manual ways to assign the unreal LOD system, like to draw a mesh multiple times in different resolutions?

    really need this for our current development.
    we intensly use the PMC to draw loads of meshes in VR. but in bigger worlds, all the distant meshes easily add up to 1 million+ vertices which drops fps.
    just can't handle all the vertices without LOD support...

    Leave a comment:


  • replied
    Originally posted by Lekyaira View Post
    First off, thanks for this Koderz! This plugin has been a huge help to me.

    Now for a very newb question, I'm sure. Is there a way to get a mesh from the RMC to render in the editor, rather than only at run time?
    There certainly is, just call it from the onConstruction event.

    Leave a comment:


  • replied
    Will this be updated for 4.15 with the new minimal headers etc?

    Leave a comment:

Working...
X