I can add editor only conditions to just log an error and bail instead of assert crashing here later on tonight, that will let you in to edit it without crashing.
Worth of your other question with the octree-database, it’s not easy to stream large binary data in ue4’s networking from everything I’ve seen. If you’re around the Unreal Slackers chat you can find me, I’m working on things that might be somewhat similar to what you’re wanting.
Also, while I don’t really use BP functions for the RMC/PMC the PMC was updated not too long ago to use LinearColors in BP saying that the regular color didn’t work so I stuck with that in the RMC.
@ this is an awesome plugin! thanks for releasing it for free
I’m using it for an interactive fluid surface which needs a buffer of the previous vertex positions so this is pretty great for this sort of thing
Is there any chance you can look into tessellation? It’s probably the only missing feature I need!
I do plan to look into that here soon. IIRC from my quick research a while back it requires adjacency info in the index buffer which there’s a utility function in the engine to calculate but I think it’s currently only in editor builds. So you can probably use it right now in editor, but since we can’t link editor modules at runtime we’ll likely have to get Epic to allow it to be in packaged versions. I might look into it more in the next few days assuming I wrap up my collision work soon, which has been slow going due to 15-20 minute re-compiles of half the engine any time I breathe in the direction of a header…
@JamesG, just wanted to check that you got the stack trace and other information I sent you regarding the physx crash? Hopefully in the next couple days I’ll have a working setup for multi threaded cooking. Also as a part of the statement above, any chance we could get BuildStaticAdjacencyIndexBuffer from the MeshUtilities (assuming that really is what’s needed for that) in a way we could use it in a packaged, non-editor build? Or should I just re-implement it in the RMC, since all it’s really doing is wrapping the nvidia tessellation library?
, this is some great work! Thank you for the amazing contribution.
Quick question for you regarding materials, a friend is trying to create some procedurally generated terrain using cubes (for the moment) and is having a hard time deciding how to apply several materials for each type. I suggested a texture atlas, but she would much rather create the materials individually.
While I definitely get the desire for doing separate materials, it’s likely going to limit you rather quickly. The problem with the RMC, and well any component for this, is that to do separate materials you need separate draws. For the RMC that translates into separate sections for each material. If you have a couple materials, you’re probably OK, but if you have tens or hundreds of materials, you’re going to get very poor performance for any decent scale voxel. The problem is pretty simple if you have 100 chunks with 1 material you have 100 draw calls, if you have 2 materials you have 200 draw calls, so the count goes up very rapidly and it won’t take long at that rate to start limiting yourself by the draw call counts.
Atlasing is one way to get around it, another way is to use texture arrays. I have an open PR ( https://github.com/EpicGames/UnrealEngine/pull/2340 ) for that to the engine but have no idea if/when it would be merged. So if you want to use a source build of the engine you can find them in my repo ( UnrealEngine · GitHub ) but that would require building from source.
With either atlas or texture arrays you can use additional textures to supply the other PBR info/normals etc. The only time I split apart the mesh in my system is for things like foliage and water which need a completely different render model.
You basically said word for word what I was thinking. I will be looking into the texture arrays for sure that could be a nicer approach.
It looks like they are getting a bit of attention and a merge will be happening sooner than later.
They’re probably the best approach for block voxel, and yeah I’m glad it looks like they’re about to be merged.
That PR has been a long time coming. That PR was started by Hilmar back in October, and I cleaned it up/bugfixed it and maintained it for the past couple months so I’m happy to see them looking into it now.
Hey @: Did you download the github repo itself (either as zip or through git)? If so the RMC is a submodule that you have to update if you pulled through git, or you have to get it from the main repo and put it in the plugins folder if you just downloaded it as a zip. The other alternative is to get the release zip that should be fully working from the releases page on github.
If that card is referring to what I think it is, then it’s a completely different purpose. I believe that’s meant for actual animated objects imported from other tools, whereas the RMC (and the PMC it’s meant to replace) are meant for being able to generate meshes at runtime to do things like procedural terrain, buildings, objects, or to be able to load a mesh from a raw model file at runtime when you don’t have editor support. The RMC is just efficient enough that it can do some limited real-time vertex animation like that sine/cosine wave powered plane in my original example.
Thanks , that’s helpful! I’ve always thought of your component in the context of my particular use case, which is closer to the sine powered plane.
Your response puts things back into proper perspective for me. Also thanks for your awesome work on this project!
As a heads up to everyone currently using the RMC or thinking about using it!
First, the RMC is now on the Marketplace, and is now also downloading correctly for those of you who attempted to download it when it first went up and were unable to. The marketplace version is the same as the current released version on github (not the master branch source).
Version 2 should be out in about 2-3 weeks if all goes to plan, with some of the following either already in github, or showing up incrementally over the next couple weeks. Version 2 will, hopefully, bring the remaining tools from the PMC over including normal/tangent calculation, RMC <-> StaticMeshComponent conversions, and hopefully tessellation support. There’s also a decent chance that it will have the initial round of improvements for collision cooking. Unfortunately though as those have taken multiple engine changes, it will require a source build of the engine at least until Epic hopefully merges part/all of it back into mainline UE. So far the collision cooker can be operated in its current game thread only mode but allow for some control over the quality of the cook cycle. There’s a trade off between quality and speed of cooking, with lower quality cooked meshes being a little slower in the actual collision detection but this alone allows it to run up to ~6x faster. It should also support nearly full multithreaded cooking to move most of the work off the game thread.
This. This one currently with PMC takes the most of the time to generate a mesh. I don’t really need tangents there, just normals, is it possible to make a checkbox to skip the generation of one of the two in the Normal/Tangent Calculation helper? Just a hint…
Normal/Tangent calculation in the PMC is slow due to needing adjacency information for smooth normals. Currently the helper on the PMC does this by brute force search which means O(n^2) “efficiency.” I could definitely allow it to skip tangents, but the problem is the slow part is finding the adjacency. The only time you can get around that really is if you know each face is independent and doesn’t share vertices (think Minecraft where each face is 100% separate) then it can just walk the mesh calculating the surface normal of that triangle.
So I think the best option is to allow turning on/off smooth normals first, then possibly turn off tangents. The new one with the RMC should be quite a bit faster but I haven’t done tests with it in large meshes yet to really see how much of a difference.
I’ve never really looked into the DFAO or HFGI so not really sure what it would take. If it’s practical to setup without hindering the performance in the general case then I’m not opposed to doing it, just not sure what it takes right now. I hadn’t thought about specific modes, but I had thought about trying to support heightfield collision.
@Chariots I might look into it at some point, for now I have higher priority things like those listed above for v2. My question though would be how many people could/would really use it. The heightfield collision I might go ahead and try to do as a part of the current collision work depending what it takes to get it running.
Okay, got it, and what about the situation, where I convert a static mesh plane to RMC? Then does the adjacency information is being copied as well as I assume.
Cause, what I want to achieve is this. Got plane, RMC, offset vertices and recalculate normals as fast as possible. If the adjacency information is cached from the original static mesh plane then it wouldn’t be that heavy to calculate, right?
