Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

  • replied
    Originally posted by S0rn0 View Post
    This is wonderful!

    Can I replicate this from the server to clients? I have built a dodgy system using TCP to send voxel data to clients, but if I could just replicate the mesh and have the server handle all of the heavy lifting...
    Yes you can. But you need to create your own replicate mechanism.

    Leave a comment:


  • replied
    This is wonderful!

    Can I replicate this from the server to clients? I have built a dodgy system using TCP to send voxel data to clients, but if I could just replicate the mesh and have the server handle all of the heavy lifting...

    Leave a comment:


  • replied
    Originally posted by Chariots
    Just your run-of-the-mill procedural terrain system, nothing fancy. I used to do it with by getting highly detailed geographical features as heightmaps from world machine then composing them in real time, but it had huge memory requirements so I ended up reverting to layered noise.
    I've thought about trying to import real geo data into mine, but I've got nice enough generation running through noise that I haven't feel like attempting it.

    Leave a comment:


  • replied
    [MENTION=8503]Z-enzyme[/MENTION] I think that checkbox just builds the adjacency indices needed for tessellation, which I don't think I can easily use for the normal/tangents, so the SMC probably wouldn't gain you anything. I should be able to split the normal/tangent calculation apart so that the 2 parts can be operated separately (initial adjacency calculation, or you create the info yourself) then the simpler calculator you just feed it the stored adjacency. that should help substantially in the cases where you need to recalculate normals/tangents for a specific topology that only changed positions.

    You got an interesting project there btw! I don't use blueprints much except for setting configuration and tiny little things. My system is full C++, so not sure what to tell you which making that faster in BP other than make sure to use Nativize if it works for you.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    Out of curiosity, what are you trying to do? My project that's driving this component is also sort of a terrain system.
    Terrain, well, more less... Well, Actually, more than less...



    This one is loaded from a save game. So, no, it's not actual generation speed.

    Right now I'm using 128x128 meshes, but I'd love to make it up to 256x256. It takes at least 7 seconds to build a 128x128 mesh with the system I've got now. BTW, I'm doing it in BP only as I can't code in c++.
    How I build it - maybe you know a better way.
    1: I make a array of vectors - loop a loop to create a grid. I offset the quads to form a cube, the normalize and multiply the vectors to create a sphere.
    I don't use SMC, I create a mesh from scratch. IF though I could take a 256x256x static mesh and convert it to RMC I guess it would be faster. More, when you are importing a static mesh there's a built adjacency checkbox. Isn't thet "the thing" we are talking when we say normal/tangent cook? and, if not, so, when a static mesh is tessellated then it calculates that on the fly?
    Attached Files
    Last edited by Z-enzyme; 07-24-2016, 02:19 PM.

    Leave a comment:


  • replied
    Originally posted by Chariots
    Probably not many. I see people using this component for terrain all the time, but that is just frequency illusion at work, because I'm doing terrain myself. I just wanted to throw it out there just as a neat could be done when/if needed thing
    Out of curiosity, what are you trying to do? My project that's driving this component is also sort of a terrain system.


    Originally posted by Z-enzyme View Post
    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?
    The static mesh doesn't have adjacency stored, it's just transient information needed to calculate smooth normals (and actually tessellation as well). The SMC has all of the normals/tangents/tessellation information calculated at cook time in editor so it doesn't have that information by runtime.

    You do pose an interesting question though and it's definitely possible to setup the normals/tangents calculator to use a stored adjacency. Could either do a separate helper to get the info, and you just feed that to the normal calculator each time you need to recalculate. About to start into tessellation and I know the adjacency is needed for that so might be useful for more than one thing. Actually if I'm going down that path I could even easily make it so that you could build the adjacency info yourself since for many things (like heightmap terrains which are a giant grid) it would be faster to generate that info yourself during mesh generation than to have a general purpose function find them afterwards. (I'm not saying only supporting you supplying the info, more that you have the option to if you can do it faster)

    Once you have adjacency then calculating normal/tangents should be pretty quick. What size meshes are you using? Also, if it's just a plane, why are you using SMC conversions?

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    Normal/Tangent calculation in the PMC is slow due to needing adjacency information for smooth normals.
    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?

    Leave a comment:


  • replied
    [MENTION=577]Chariots[/MENTION] 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.

    Leave a comment:


  • replied
    Originally posted by Z-enzyme View Post
    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.


    Originally posted by Chariots
    I've checked heightfield lighting system for terrain far shadows, DFAO, and heightfield GI. It is very easy to hook up to it provided you have the height information (and color info for GI, although I didn't try GI in depth). All it needs is a bool and maybe 2 functions (can't remember exactly) to get it working dynamically (it's all in runtime folders without editor defines). Only issue is the scaling settings of distance fields is a bit finicky (put off that for later), but still it works.

    Are you planning to adding specific geometry modes to the component (like terrain mode for heightfield collision, heightfield GI etc), or would you rather keep it generic? If former, would you be interested in some terrain specific contributions down the line? If latter, would you mind if I release the modifications I've made on a separate repository at some point?

    Also, thanks for releasing this!
    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.
    Last edited by Koderz; 07-24-2016, 10:22 AM.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    • Normal/Tangent Calculation (Like the PMC's current helper, but hopefully faster)
    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...

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Thanks Koderz, 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!

    Leave a comment:


  • replied
    Originally posted by Yanko Yankov View Post
    Does anybody know if this new upcoming feature would provide functionality similar to this component? If so, what would be the differences/trade-offs?

    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.
    Last edited by Koderz; 07-22-2016, 02:27 PM.

    Leave a comment:


  • replied
    Does anybody know if this new upcoming feature would provide functionality similar to this component? If so, what would be the differences/trade-offs?

    Leave a comment:


  • replied
    [MENTION=141752]Koderz[/MENTION] Thank you for this! I'll give it a chance to replace PMC ASAP on my project!

    Leave a comment:

Working...
X