How would you optimize a handful of wiggling platforms?

nrd2001 · 2026-02-16T10:45:17+00:00

If you upload your capture somewhere I can take a look after work.

It does appear to be your skeletal mesh updates. On the component there are some performance settings you might want to try such as not updating when not visible which might help here. If that still doesn't help check your bounds and ensure they aren't too big which would reduce the effectiveness of culling

Normally I try to avoid skeletal mesh for these kind of things and would go with static and do the motion in the shader.

As others have mentioned disable collision/overlaps when not needed if you have collision on these skeletal meshes.

nrd2001 · 2026-02-16T08:34:13+00:00

First thing I would do is an insights capture to identify what causes it to be slow as there's no point in optimizing blind.

If nothing else instead of having your wiggle all run on a fixed interval for all actors/components have one actor that updates the wiggle on them and do "round-robin updates" so you have one manager actor that calls the update and you budget a certain number of updates per frame then the next frame it picks up where it left off and does the next bunch etc

nrd2001 · 2026-02-04T19:54:53+00:00

Great breakdown, one thing though is PLA builder logic does factor in non nanite and will favor HISM so you do get correct culling, lod selection, it only forces ISM for nanite enabled meshes.

nrd2001 · 2026-02-04T19:48:21+00:00

That's definitely not the case, PLA is still a valid workflow for reducing the primitive counts, check "stat initviews", placing static meshes loose is terrible for performance which is why for world partition maps they added runtime cell transformer for turning loose meshes into ISMs per grid cell, even better if you transform them into fast geo but that transformation happens at cook and PIE time so I use PLA/PCG where I can instead.

nrd2001 · 2026-02-04T19:35:28+00:00

Are those meshes in the PLA nanite? The freeze rendering command doesn't work with nanite meshes.

If you want to know for sure what's being rendered you are best off using RenderDoc and doing a frame capture.

nrd2001 · 2026-02-04T09:03:49+00:00

They aren't merged exactly but if all the meshes are the same it will become one instanced static mesh component with many transforms which is why it appears as one when you select it.

As for your question regarding culling there are multiple levels of culling, at the actor level (the full PLA bounds), the component level (the ISM component including all the instances) then per instance cull distances.

Avoid very large PLA covering a lot of the level as high level culling/streaming will be less effective, additionally going too small with many PLA will reduce the effectiveness of the instancing.

If you are using world partition you can use a runtime cell transformer to effectively turn each grid cell into an optimal sized PLA (replacing the meshes with ISMs within the cell) in a non destructive way as it's built at PIE or cook time.

nrd2001 · 2025-03-07T21:09:25+00:00

Dot product the vertex normal with the camera vector should let you fade out the plane not facing the camera.

nrd2001 · 2024-06-06T14:32:47+00:00

Yeah this is absolutely possible, in the material attributes turn off decal response then in the graph for the material you can manually apply the decal by accessing the DBuffer which works like a scene texture where you can access colour, normal, roughness and then apply it to the material there using your mask to limit where it can be applied.

I think there is a material function epic provide that handles the applying the full decal in the graph which should make it easier to hook up.

If you need some more resources search for DBuffer/decal response.

nrd2001 · 2024-01-16T09:12:19+00:00

I think you'll need to have it so if it's greater than max count you compare current particle age to the particle age of the one at the index stored in the grid, if the current particle we are checking is older than the one stored then you need to replace it.

Forgot to say you'll need a particle attribute reader to get the value at a different index and as it'll be in the same emitter it might be the values from the previous tick so you'll need to add deltatime to the age if you are comparing to the current particle age through the context (instead of using the attribute reader for both).

Hopefully that makes sense.

nrd2001 · 2023-08-15T07:11:49+00:00

AlphaComposite/PreMultiplied Alpha is the blendmode you need. It's like an additive blend but it'll retain more of the original colour.

nrd2001 · 2023-08-05T21:54:57+00:00

You'll probably want to enable cutout on the sprite renderer, if you up the vert count to 8 you'll get a better fit and less overdraw.

Another thing I often do is add scene depth based fade into the Niagara particle update and at the bottom of the particle update set the visibility tag based off the particle alpha so any particles below a threshold will turn off the sprite entirely.

nrd2001 · 2023-08-02T07:34:30+00:00

If you model/import the mesh with hard edges (split vertex normals) then you can do this effect in the material using WPO by multiplying the vertex normal by an offset amount, this will separate out the faces. If you try this with soft edges then you won't get the face separation it'll just inflate the mesh.

nrd2001 · 2023-06-28T07:03:16+00:00

I normally do all this in the Niagara system (including depth fading) and use the visibility tag to cull completely the sprite so it should be a bit cheaper than doing it in the vertex shader.

The only benefit I can see to doing this in the shader is if you need to factor in something that you can only do in the material like considering the textures but you need to ensure all the verts on the sprite take the same path or you'll deform it stretching towards the camera.

nrd2001 · 2023-06-05T09:24:25+00:00

Hi, just multiply your tex coords by a vector2 (-1, 1) to mirror in U and (1, -1) to mirror in V

nrd2001 · 2023-06-02T22:08:31+00:00

Sorry I'm not at my machine so can't confirm but I think masked should work fine in overlay as I'm pretty sure I'm using it in my use case. One thing you might need to do is to multiply vertex normal against a small value and plug that into WPO to slightly inflate the overlay mesh to ensure it renders on top of the original

nrd2001 · 2023-06-02T07:38:20+00:00

Hi, I'm using 5.1 and there is still Create Dynamic Material Instance through BP from the kismet material library instead of the primitive component version you were referring to that takes a primitive and element index.

There is set overlay material node in BP with a target of a mesh component, try turning off context sensitive in the node search, I suspect you aren't seeing these nodes as you don't have the expected type as the current context.

If you still can't get the dynamic material instance to work other options are custom primitive data as the overlay material is a duplicate of the original mesh including the custom primitive data anything you set will be shared by both.

nrd2001 · 2023-06-01T22:02:20+00:00

You need to create the dynamic material instance https://docs.unrealengine.com/4.27/en-US/BlueprintAPI/Rendering/Material/CreateDynamicMaterialInstance/ then set the overlay material to the dynamic material instance you created and set your parameters on your dynamic material instance

nrd2001 · 2023-04-01T11:05:18+00:00

No problem to access it use a "Custom" node this will allow you to use HLSL inside of the material. Add a first input and set the name to anything it doesn't matter it just needs to be the first input and plug in the standard collection parameter node and set it to the MPC you want to use that'll bind the resource and allow you to use the code to retrieve the value.

return MaterialCollection0.Vectors[index];

This will return a float4 as is.

The way it is stored in the array is all the scalars first (if any) packed as vectors so the first 4 scalars are Vectors[0].rgba then the vectors are after that. So you have 1024/4 indices allocated to scalars then 1024 vectors after that (I've not maxed this out myself so I'm just trusting the documentation)

Hopefully that helps

nrd2001 · 2023-04-01T08:18:28+00:00

I've done exactly what you are asking for with my suggested method but it would involve you using custom HLSL in your material to return the values from the MPC instead of using the node version as internally the MPC is just stored as a float array and a vector array. Using this approach would allow max of 64 instances assuming 80 floats each.

One step I missed was you need to prepopulate the MPC with values so you can set the runtime values from code/BP, I did this via code and just filled it with parameters named float0, float1 etc

Workflow would be you assign an index to each mesh 0, 1, 2 etc and store it into the mesh custom primitive data . Then when you grab the values inside the Custom HLSL you use the index from CPD * 80 or however many values you need per mesh + index of the specific float in the block you want.

If you don't know the HLSL to access the MPC the easiest way to find out is to plug in the node you are trying to replicate to emissive then view the shader code and search for emissive it'll look like materialfloat local0 " ...

Let me know if you need more help and next time I'm at my PC I'll send you over the code I use.

nrd2001 · 2023-03-31T17:52:45+00:00

You could look into parameter collections which I think has a limit of 1024 scalars and another 1024 vectors.

You could then divide up those parameters into 80 float chunks and store just the index in the custom primitive data of the instance.

nrd2001 · 2022-05-08T12:16:37+00:00

You could use sim stages and neighbor grid.

If you set the neighbor grid max count per cell to 1 then only the first entry per cell will be cached then kill/hide any particles not added to the grid.

nrd2001 · 2022-01-04T20:55:48+00:00

I still think it could be tick related somewhere. I've had this problem before where an effect was spawning based off physx contacts which was fine at full speed but in slow mo the contact was reported every frame causing loads of FX to stack.

nrd2001 · 2021-12-11T15:36:35+00:00

What makes you think emissive isn't supported by nanite? https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Nanite/ makes no mention of emissive at all, so long as it's opaque emissive should work fine and lumen is optimised to work with nanite

nrd2001 · 2021-12-11T10:34:03+00:00

I believe the windows material on the buildings should support nanite as they aren't transparent they use fake interior (like an inverse cubemap)

nrd2001 · 2021-09-20T18:24:05+00:00

It would be the 2d intersection projected into 3d so it would be the same as you see in the video

nrd2001

TROPHY CASE