Trying a socket based setup for running #GeometryNode from engine. Main bottleneck atm is creating static mesh assets which is needed for instancing. I wonder if there are any ways to instance dynamic/proc mesh in the engine :?

nope. A while back I did a variation of dynamicmesh that supported instancing (and generally less memory & faster build), but then the engine substantially changed how instanced rendering worked and my implementation was completely broken :(

That sucks :( I guess will have to implement something custom then ^^'

does reconstructing the mesh from the geoNode to ProceduralMeshCom do the job? i used it for my MobileTerrainTools and it was pretty fast (as long as Unreal doesnt try to generate mesh cards/mesh field cards all the time)

@ArcaneForge3D Proc/Dynamic mesh is fine, but if you have high instance count + dense meshes the memory usage will be an issue!

@GameDevMicah dude. What a fcking amazing creepy fck is this?! 🤩🤩🔥🔥🔥🔥

Nope… but there did or are adding skeletal instanced meshes… I personally use location scrap each frame to render Niagara particles as nanite (pre 5.7) so you could send segment locations to an ism easily and update it each frame. Batch updates are super fast. Esp if you…

No, it has to be a generic setup. Any kind of mesh data, not exclusive to segments etc. ISM/Nanite/Niagara needs static mesh, creating that is slow (not good enough for interactive workflows)

Huh? If you can extract each segment location of the arm, up to 100,000 instances can update each frame with no real impact… they already do this with the “automatic dynamic instancing” in-engine at runtime to unify alike meshes to isms for batch rendering - it’s well engineered

I am not just rendering segments here, any kind of instancde mesh...

It’s hard to see out of movement, but bricks and tiles, like why your tower is made of, could easily be a kit bash set of bricks and tiles you place and reuse on the building. That building would be 10-20k bricks and tiles(each) so like 40-50k instances of bricks and tiles…

..you can have up to 16,000,000 instances in a level, so you can runtime each frame, gpu randomly distribute 40-50k static mesh placements to build that building and batch update to isms without cost. As long as collisions are off completely…

But if you think there is a significant creative advantage to generating each brick as a unique mesh and never reusing it in the building. Then you’re right, you can’t instance that. I think that’s a wasted bit of complexity myself. 40k unique bricks will look the same as 40.

And if you need collisions, mesh distance fields is fast and I think cheaper if you can pole from that instead. But you can also leave collision on for the building (more static placement than the climber) and still scrape the climbers instances to render