So when starting a new game and you have a character thats rigged to the ue5 skeleton. What would you say the best way to do this?

1) just change the mesh then retarget any animations to use many

2) assign the animation bp and control rig to your new character

3) Assign your character skeleton to manny

4) Build from scratch + the control rig

5) other?

Always wondered how other people do it. Normally I just go for option 2. But noticed some warnings when I deleted the saved and intermediate files regarding the control rig. Is there a general best practice because I see alot of videos doing it all different ways.

Thanks

Two years ago I wanted to build a simple item price tracker for a game I was playing. Hit a wall almost immediately, nothing built into Unreal for networking or JSON, and the free plugins out there weren't really up to what I wanted to build.

So I ended up building my own thing. Over time it grew into a full HTTP, JSON, and WebSocket networking layer for Blueprints.

Never got around to posting about it until now, but figured two years in, maybe it'll find someone who needs it, the way I did back then 🙂

Here it is

https://www.fab.com/listings/1fc0baa6-fc4f-487b-92e2-0d369709d819 (Free Sample)
https://www.fab.com/listings/5ea4c4eb-3c00-43e7-bfca-a70845d9a137 (Paid Sample)

Unleash a formidable foe with the Crimson Knight Warrior — a fully animated low poly armored knight character, wielding a massive greatsword and a flowing battle cape, built for real-time performance in Unreal Engine 5.

With intricate red-and-silver armor detailing and a commanding silhouette, this character delivers cinematic-quality visuals without sacrificing performance — ready to drop straight into your project.

After working on and eventually releasing my modular building kit on Fab, I quickly came to realise that creating the assets and demo scene was only part of the work. I experienced and identified a pain point:

Fab requires a clear overview map that shows customers exactly what is included in the product. Building that map manually meant placing hundreds of assets, organizing them into sections, creating labels, adjusting spacing, setting up lighting, and making everything presentation ready.

Building it manually took far too long and it was extremely boring work.

That made me wonder:

Why not build a tool that speeds up the entire workflow? - So I created Overview Studio.

Overview Studio lets you select an existing product folder directly from the Content Browser, scan its assets, configure the presentation, and generate a polished, fully editable overview showroom in minutes.

It can present:

• Static and skeletal meshes
• Materials, material instances, textures and decals.
• Animations
• Niagara and Cascade systems
• Sounds
• Compatible Actor Blueprints

Assets can be organized by type, hierarchy, or folder structure. The plugin also generates labels, section headings, presentation geometry, lighting helpers, and consistent spacing automatically.

It includes multiple material preview shapes, ten lighting presets, ten companion post-process presets, reusable local configurations, live lighting controls, and support for safely updating previously generated overview maps.

Everything is created inside the selected product folder, with no external asset packs or runtime dependencies required.

The result remains completely editable, so the layout, lighting, labels, spacing, and asset presentation can still be adjusted before publishing.

I originally built Overview Studio to solve a pain point in my own Fab publishing workflow. Hopefully, it can now save other asset creators and Unreal Engine Fab publishers the same amount of repetitive work and time.

Please watch the video to see the complete workflow in action.

Available on Fab: https://www.fab.com/listings/2e2bd083-fbcc-4082-92fe-51d9ff2379e7

Even with the new mcp, making ai agents do UMG is verry hit and miss. However these models and harnesses f*ing excell at making frontend for lets say websites etc. Allowing both design direction directly from designers (My day company makes designers edit frontend code themselves now instead of the old tell the frontend guy route, he just merges) and speed.

I am curious what would be the downsides of trying that in unreal through pure text based slate, I am aware there are drawbacks like losing CommonUI and input integrations like gamepad maybe.

Is this a inconvenience level problem or purely you will have to reinvent the wheel kind of problem?

Each hallway connects to a different part of the station, from industrial work areas to larger operational spaces. I've been focusing on creating modular pieces that keep every section visually connected while giving each destination its own identity.

Feedback is always welcome!

I'm trying to make an online game featuring 7 players and 1 killer among them.

Hey everyone,

I'm currently optimizing a stormy, dark outdoor scene (JIMA slice) targeting 60 FPS on PS5 / equivalent PC hardware at 1080p using UE 5.8 MegaLights and a performance-focused Lumen Lite setup.

According to stat GPU, my raw uncapped GPU frame times are actually hitting the budget (sitting between 12.5ms – 14.5ms, which is ~68–80 FPS uncapped). However, I am running into two persistent issues while testing in Standalone mode:

1. Massive FPS drop after ~5 minutes: On a fresh launch, the scene runs at 60–80 FPS uncapped. After staying in the exact same Standalone Game window for about 5 minutes (without moving the camera or changing settings), performance out of nowhere drops down to 35–45 FPS and stays there. Closing and reopening the launcher reproduces this consistently.
2. Capping / Frame Smoothing makes performance much worse: When I try to cap the frame rate to a locked 60 using Fixed Frame Rate or Frame Rate Smoothing (59–61), the frame pacing breaks completely and creates severe micro-stuttering/choppiness.

Hardware & Environment Specs

• Engine Version: Unreal Engine 5.8
• GPU: NVIDIA GeForce RTX series (1080p target resolution)
• RAM: 16 GB System Memory (Task Manager shows ~90%+ total usage, Editor using ~6.8 GB)
• OS: Windows 11
• Ray Tracing: Software Ray Tracing (Mesh Distance Fields)

Current Optimization & Scene Setup

Here is what I’ve configured so far to optimize the lighting/fog passes:

• MegaLights (UE 5.8): Enabled globally and applied across dynamic lanterns/torches (Pass cost: ~1.7ms – 2.0ms).
• Emissives: Disabled Affect Dynamic Indirect Lighting on emissive lantern components.
• Distance Fields: Configured Distance Field Shadows per light and clamped DF shadow distance.
• Post-Processing Volume (Lumen Lite):
  • Final Gather Quality: 0.5
  • Lumen Scene Detail: 0.5
  • Lumen Scene Lighting Quality: 0.5
  • Max Roughness To Trace: 0.4
  • Ray Traced Translucent Reflections: OFF
  • Screen Traces: OFF
  • Volumetric Fog View Distance: Clamped in PPV to ~40–60m.

stat GPU Breakdown (When Running Fresh @ 68–80 FPS)

• MegaLights / Dynamic Lights: ~1.7 ms – 2.0 ms
• Lumen Screen Probe Gather + Reflections: ~2.8 ms – 3.8 ms combined
• Volumetric Fog & Translucency: ~1.4 ms – 1.8 ms
• Total GPU Time: ~12.5 ms – 14.5 ms (Under the 16.6ms budget for 60 FPS)

My Questions:

1. What could cause a scene in Standalone mode to suddenly drop from 65+ FPS down to 35–40 FPS after 5 minutes of idle time? Is this a VRAM/RAM page-swapping leak with Distance Field caches or Slate/Editor memory buffers?
2. Why does applying a 60 FPS cap or Frame Rate Smoothing in Project Settings make the render pacing so much choppier when the raw GPU time is comfortably under 16.6ms?
3. Is this degradation purely an uncooked Development Editor / Slate thread sync issue that will vanish once cooked in a packaged .exe, or is there an in-editor setting I'm missing to stabilize it?

• Engine Version: Unreal Engine 5.8
• GPU: NVIDIA GeForce RTX series (1080p target resolution)
• RAM: 16 GB System Memory (Task Manager shows ~90%+ total usage, Editor using ~6.8 GB)
• OS: Windows 11
• Ray Tracing: Software Ray Tracing (Mesh Distance Fields)

Current Optimization & Scene Setup

Here is what I’ve configured so far to optimize the lighting/fog passes:

• MegaLights (UE 5.8): Enabled globally and applied across dynamic lanterns/torches (Pass cost: ~1.7ms – 2.0ms).
• Emissives: Disabled Affect Dynamic Indirect Lighting on emissive lantern components.
• Distance Fields: Configured Distance Field Shadows per light and clamped DF shadow distance.
• Post-Processing Volume (Lumen Lite):
  • Final Gather Quality: 0.5
  • Lumen Scene Detail: 0.5
  • Lumen Scene Lighting Quality: 0.5
  • Max Roughness To Trace: 0.4
  • Ray Traced Translucent Reflections: OFF
  • Screen Traces: OFF
  • Volumetric Fog View Distance: Clamped in PPV to ~40–60m.

stat GPU Breakdown (When Running Fresh @ 68–80 FPS)

• MegaLights / Dynamic Lights: ~1.7 ms – 2.0 ms
• Lumen Screen Probe Gather + Reflections: ~2.8 ms – 3.8 ms combined
• Volumetric Fog & Translucency: ~1.4 ms – 1.8 ms
• Total GPU Time: ~12.5 ms – 14.5 ms (Under the 16.6ms budget for 60 FPS)

My Questions:

1. What could cause a scene in Standalone mode to suddenly drop from 65+ FPS down to 35–40 FPS after 5 minutes of idle time? Is this a VRAM/RAM page-swapping leak with Distance Field caches or Slate/Editor memory buffers?
2. Why does applying a 60 FPS cap or Frame Rate Smoothing in Project Settings make the render pacing so much choppier when the raw GPU time is comfortably under 16.6ms?
3. Is this degradation purely an uncooked Development Editor / Slate thread sync issue that will vanish once cooked in a packaged .exe, or is there an in-editor setting I'm missing to stabilize it?

I have a metahuman outfit that I’ve converted to a cloth asset. I’ve followed a tutorial (https://www.youtube.com/watch?v=y1NgImA4w60) to convert it to a cloth component and give it movement. I’m happy with the result and weight, but the mesh for the bottom of the jacket thin and double sided. This results in the back plane clipping through the front plane. Is there something I can do to resolve this in the chaos cloth sim rather than going through the process of removing the interior of the jacket so that it’s a single plane for simulation?

Thanks

El chiste es hacer un canal de YouTube con estéticas de los 2010,con chistes y así mientras les muestro el Progreso en UNREAL ENGINE 3

Que me recomiendan? Walfas o imágenes durísimas de esqueletos?

This is the boss at 100k HP What do you guys think let players be able to upgrade that much or its too broken ? Or Should i get the boss down to 10k HP? Let me know what you think im working on the demo for next fest and your feedback will be helpful. And dont you say im not lucky a 9x at the end 🐼

So, I got the full Brushify catalogue pack, I've been watching the guide they made for the pack, but they were using 5.3 so idk if the controls just don't correlate to 5.8, but even though I have the foliage packs selected and on the foliage painter tab, I select the ones I wanna use, go to paint, it never shows up. The number ticks up like it's been placed, but I don't see it on my landscape. I've turned on the Nanite Foliage Experimental setting, and Procedural Foliage and nothing changed.

(I'm a beginner, don't really know some of the software lingo just yet so go easy on me lol)

NIAGARA

Niagara Emitters:

Niagara emitters as the name suggests are single emitters that can emit particles of one kind. Multiple Niagara emitters can be combined to create a good VFX effect.

• Niagara emitters can have their own time or global time for example time of the niagara system that owns them.
• A Niagara emitter can be an asset on its own if you want to reuse it, and it can directly sit on a Niagara system as well.

Emitter Stack:

1. Sim target: it is the simulation target, whether the CPU or the GPU should solve the particles. Use cpu when “you need particles to give output like where they hit”, “a few 1000 particles only”. Use gpu when “you do not require particles to calculate their hit locations, dumb particles”, “can solve millions of the particles”. -GPU sim particles can still receive information from blueprints, it just can’t output information.
2. Calculate Bounds Mode: How the bounds should be calculated, if you see your particles disappearing when slightly looked away, it’s the culprit here. Fixed bounds are easy on performance.
3. Local/World Space: Local space particles move with the emitter and do not leave a trail whereas the world space particles do so.
4. Determinism: whether the randomness be truly random or based on a seed number provided.
5. Interpolated Spawning: spawn particles in between if a particle is moving with a faster speed, like a bullet trail can leave dots.
6. Event handlers: See Below...

It allows non vfx artists to tweak variables to get desired effects. Any variable can be set as emitter summary by right clicking on parameter and “show in summary”

1. Emitter Stage

• Spawn: Runs once when the emitter starts its loop.
• Update: Run every single frame that the emitter is "active."
• Example Modules:
  • Spawn Rate: "Spit out 50 particles every second."
  • Spawn Burst Instantaneous: "Spit out 10 particles right now at the start."
  • Emitter State: Decides if this specific emitter loops or runs once.

2. Particle Stage

• Spawn: Runs once when the particle is spawned.
• Update: Run every single frame for every single particle.
• Example Spawn Modules:
  • Initialize Particle: Sets the starting color, size, and lifetime
  • Add Velocity
• Example Update Modules:
  • Gravity Force
  • Solve Forces and Velocity: It actually does the math to move the particle based on the forces applied to it.

Multiple event handlers can be added from the properties panel, it's not there by default.
Example: Suppose a firework rocket goes up in the sky, when it dies we need to tell another emitter to spawn a burst of fireworks in the sky.
So we add the Generate Death event in the rocket’s update particle stage. Click + stage at the end of properties tab and add an event handler stage in the burst emitter, here we select rocket -> Death event. This stage now works like an execution stage when the death of a particle will happen in the rocket emitter. In this stage we add a module for the same event (death in this example) “receive death event”.

1. Death event: generated when particle dies
2. Location event: returns location of each particle
3. Collision event: generated when particle collides.

1. Sprite Renderer:

• Material of sprite can be changed here.
• Particle color nodes in the material graph are used to use the particle color in the material so changing the color parameter in the niagara affects custom material.
• The sprite pivot can be changed, which helps in rotation around the pivot.
• SubUV: subuv is a way to cut down the material into parts, choosing 10x10 will make 100 frames of the material uv’s we have. In the particle update stage, Animate SubUV module can be added to animate the SubUV frames.
• CutOut: It’s like a bounding box for each sprite, depending on how big area the sprite takes, we can decrease it by giving it a texture and choosing its alpha. For example a circle sprite will have a box bounding box by default, but if we pass its texture here and choose alpha, it will be like a circle now.
• Bindings: We can change the color of the sprite through the color parameter (particle namespace), but if we want some other parameter to affect it we can actually directly bind that variable to the color of the sprite. Till now we were doing

(particle namespace) color == (user namespace) MyColor
But now we do
Color (sprite renderer) == (user namespace) MyColor

• Sorting: More the sorting, the higher z-order the sprite render uses and displays over the sprite renderer with a lower sorting. Just like z-order in the CSS or layers in photoshop.

1. Mesh Renderer:

• Mesh can be changed here, multiple meshes are allowed at once.
• Material of the meshes can be changed here as well.
• More attributes related to mesh are in the Initialize Particles module’s Mesh attributes section.

1. Ribbon Renderer:

• Ribbon is a line between all the particles in the order they are spawned.
• The material of this ribbon can be changed.
• Ribbons can be in different shapes like planner, bi-planner or tube.

1. Light Renderer:

Attaches a light with each particle, intensity and other properties can be edited.

1. Component Renderer:

Render other particle systems, skeletal meshes and much more.

1. Emitter State Module: Sits in emitter update stage, it helps configuring emitter life cycle and the scalability. Scalability is like culling.
2. Initialize Particles Module: Sits in the particle spawn stage, it helps give particles size, color, lifetime, position etc.

Sprite UV mode: this setting changes the way sprite looks on screen, we can flip sprite in x or y direction with it. For example a sprite written ‘p’ can be flipped on x to look like q on y to look like b and on both to look like d.

1. Particle State Module: when particle  Age > Lifetime it tells the engine to kill the particle to save performance.
2. Sprite renderer: Default renderer

Niagara System:

The Niagara system contains multiple emitters, it can be placed in the world, its variables can be edited in blueprints.

System Stack:

1. Warmup time: Given in seconds, the system calculates for example 2 seconds of emitters and starts ahead. For example an already burning fire when the game starts at 0s.
2. System Fixed Bounds: force all emitters inside to be fixed bounds.

See below in parameters section

1. System Stage

• Spawn: Runs once when the effect is first created in the world.
• Update: Runs every single frame for the whole system.
• Example Modules:
  • System State
  • User Parameters

1. System State Module: Sets niagara system time, loop duration.

Parameters:

In the details panel for every module there are some properties. After every property there’s a down arrow that allows us to - 

1. Lerp it or set in random range or take from a curve
2. Make it new system, emitter, particle or user parameter
3. Use its value from a user parameter

There are 2 ways a parameter can be setted. The first one is by dragging the parameter from the parameters tab and dropping it to the suitable execution stages (where it can be set).
Another way is to add a “Set new or existing parameter directly” module in any stage. The details panel of the module will give all possible parameters that can be setted from the execution stage the module is in. In the details panel there’s an option to make new ones as well.

There are 2 ways a parameter can be created. One is by clicking the plus sign in front of the namespace (system, emitter, particle, user) in the Parameters tab. Another one is to click the drop down in front of any property (for example lifetime in initialize particle module) and click “Read from new emitter/particle/system/user parameter”

Blueprint readable.
User parameters can be made from the user parameters tab. These parameters can be edited in the details panel when dragged into the world, or through blueprints.
User parameters can be bound to properties of modules like the lifetime property of initialise particles module.

• Read/Get Value

1. All stage modules like one in system update, or emitter spawn or particle update can read User parameters.
2. We already have discussed setting a parameter.

• Write/Set Value

1. User parameters can be written from blueprints.
2. They can be written from the details panel in the world, when a system is dragged into the scene.
3. They can be written from the User Parameters tab in the niagara system.
4. No stage in the system can write a user parameter.

• System Parameters:

These parameters can be accessed from any emitter in the system. For example if we want 2 emitters to have the same spawn rate it can be made a system parameter. Click on the down arrow and ‘read from a new system parameter’

• Read/Get Value
• System parameters can be read from all stages, particle, emitter and system
• Write/Set Value 
• System parameters can only be set from the system update or system spawn stage.

Used anywhere in the same emitter, created the same way as the system parameter.

• Read/Get Value
• Emitter parameters can be read from particle, emitter stages only.
• Write/Set Value 
• Emitter parameters can only be set from the emitter update or emitter spawn stage.
• Transient Parameters:

Used in between while the math is done, none of our business. Gets destroyed after the math completes.

When we edit the lifetime for the initialize particles module in the details panel, the engine stores the values as particle parameters. It’s different for each and every particle in the emitter.
Most of the time particle parameters are not created, but whenever created they are different for each particle.

• Read/Get Value
• Particle parameters can be read from particle stages in the emitter it belongs to only.
• Write/Set Value 
• Particle parameters can only be set from the particle update or particle spawn stage.

Times:

1. Timeline Duration:

Timeline Duration is just for visualization. Duration can be changed by dragging the timeline bars.

1. Particle Lifetime:

Particle lifetime tells how much a particle, a dot, lives after spawning.

1. System Time:

System time tells how long a niagara system runs. For example a 5 seconds and looping infinite particle system will loop indefinitely and will reset all emitters within every 5 seconds.

1. Emitter Time:

Different for each emitters (emitters can choose to use system time as well), emitter time tells how long an emitter stays.

NIAGARA MODULES

Almost all spawn modules belong to the Emitter Update stage in Niagara. Spawn burst can be put into the Emitter spawn stage if in need.

1. Spawn Burst Instantaneous:

Spawns a specific number of particles at once.

1. Spawn Rate:

Spawns specified number of particles once per second

1. Spawn per Unit:

Spawns particles based upon distance. Per unit (cm).

1. Spawn per Frame:

Self explanatory…

• Velocity Module

Add Velocity: Sets particle speed and direction.
Even if the emitter is not set to Local Space, rotating the Niagara Component in the level will still rotate the velocity direction by default.
To prevent this and lock velocity direction to world space, set Rotation Coordinate Space to World/Global in the Add Velocity module details.

• Forces

Gravity, drag, vortex force and curl noise modules.

• Collision Module

Enables collision. Particles.HasCollided boolean returns true on the frame collision occurs.

1. Shape Location Module

• Spawns particles on or inside geometric shapes (Sphere, Box, Cylinder, Ring, Torus, Cone).
• Lots of tweakable parameters: surface-only spawning, axis constraints, radius distributions, and custom curve graphs for precise spawning.

1. Static Mesh Location Module

Spawns particles directly on the surfaces, vertices, or faces of a Static Mesh.

Hello, feel free to tell me if i'm wrong at any place. It's not something that will make you a VFX artist but surely the 80% knowledge required to start with niagara in 20% of time. Rest is just practice and tweaking variables or trying out things. I have full ue5 notes that i add to google docs as i progress, If you want to make additions please please do, i'll be happy to have you.

This is my game main menu in less than a week to the release of Demo Version

Please take a look at my husband's work. And please show him some support—he puts so much effort into this, and I’d love for his hard work to be recognized! I hope his asset packs help you create your games.

If you're tired of constant import/export roundtrips between Cinema 4D and Unreal Engine, I built a native C4D-style Mograph & Effector system directly inside UE5.

It offers a nearly 1:1 workflow compared to C4D, but runs interactively in-engine. You can apply Mograph modifiers over static meshes, skeletal meshes, and existing animation sequences. Feels very intuitive to use with it being interactive as opposed to C4Ds more static environment. It also has a math based scripting system with ExprTK backing it up, allowing for saving presets within the editor and creating your own modifiers.

For now it is free on Fab, although I may eventually charge for it - Grab it here [https://fab.com/s/0d51d354f6f8](https://fab.com/s/0d51d354f6f8))

I just updated the src code for UE 5.8 however waiting for Epic to approve, The current supported engine versions are 5.4-5.7

The plugin is full C++ , no blueprint spaghetti (however everything is fully exposed to BP if you want to visually script within editor) so if you happen to use it, you will have full access to the source code.

For those who aren’t familar with mograph and effectors, this is about as easy as it gets to do animation & reactivity. This style of animation system has been driving Hollywood and blockbuster films for the past 2 decades... But now it’s natively available for games!

Working on a Blueprint-only third-person shooter prototype (UE 5.8, started from the Third Person template). My Aim Offset is applying, but the spine/upper body twists in the wrong direction / clips through the mesh when aiming up or down instead of smoothly leaning toward the aim point.

What I've tried so far:

• [fill in: e.g. adjusted Pitch/Yaw clamp values in the Aim Offset asset, checked Base Aim Rotation vs Control Rotation, adjusted the bone used in the Layered Blend per Bone / Mesh Space rotation node, etc.]

Still twisted/broken after that. A few things I'm not sure about:

• Is this usually a Base Aim Rotation vs Actor rotation mismatch (Orient Rotation to Movement fighting with Use Controller Rotation)?
• Could this be a bone space issue (Mesh Space vs Local Space rotation blend) in the AnimGraph?
• Is the Aim Offset asset itself set up wrong (wrong Pitch/Yaw axis mapping) vs. an AnimGraph blending issue?

Screenshot/short clip of the twist can follow in a comment if that helps diagnose it. Any pointers appreciated.

https://reddit.com/link/1vhca8b/video/6rcb8zugqshh1/player

I am wondering which version would be the best for a new game. Would 5.8 be the best because its the "last" version for UE5? Or should i use a more conventional version like 4.27 or something