I know what would happen.
I would have to recreate all the blueprints and maps.
But all my bluprints are just data.
All code is in C++, so it is 99% compatible with UE4.27.
And all my assets I have made with Blender so the only inconvenience is creating the blueprints and maps again.
Even my behavior tree is made in C++.
I think I could do it if necessary.
The results will be better in UE4.27 (In the editor). Because the UE4.27 editor consumes less resources… But in Standalone it will be practically the same… I’m sure there is not much difference.
Are you talking about entity component system (ECS)?
I tried it in unity a few years ago… it was experimental.
I haven’t seen anything like that in Unreal yet.
I don’t think it will work for my AIs anyway, I have a very complex behavior tree.
I don’t know if you read my comment above.
I have excellent performance in Standalone.
My whole problem is inside the editor.
In any case, all the ideas you provide for optimization are appreciated.
I’ll take a look at all of them!!
Yes, that’s correct, I encountered this issue at an earlier stage but managed to significantly improve performance. I estimate that there will be up to 10 ships and a total of about 100 turrets in a battle, and my tests indicate that this setup maintains an acceptable performance level.
However, what’s particularly frustrating this time is that everything works fine in version 5.4, while the exact same setup performs poorly in 5.5. So far, it’s unclear what exactly is causing the problem. I’ll continue investigating this further.
Sometimes something seems to be working well and then you take it out of context and realize that it really wasn’t a solid solution. This happens a lot in programming.
That’s why it’s good to program in the most generic terms possible… even better in an abstract way…
I know you’re going to tell me that you didn’t change the context. But maybe they did.
Maybe you were relying too much on a delay… And the reality is that delays are not at all reliable in most cases. (Loading assets, waiting for spawns and things like that, delays are a bad idea → It’s just an example)
Epic used their Mass entity component system for the vehicles and pedestrians. They go the route of only converting them at runtime to “normal” actors when you interact with them in some way (like when you crash into a vehicle). Pedestrians also use vertex animations while in the mass state to further reduce load on the system.
Got even closer to solving the performance drop.
Disabling this widget returns performance to normal.
My theory is that this glow effect material affects Draw Thread.
Turning off this retainerBox option in 5.4 gives a small boost.
Performance in both versions looks similar now but 5.5 consumes more memory and RHIT much faster
I’m glad you found the solution.
It seems like it’s consuming a bit more VRMA.
But if you notice it is also consuming 4G less RAM.
Looks like it’s a good deal after all.
i have not idea… maybe it is a bug… i found a lot of bugs in each new version of UE.
To see the true performance do not cap it at 30FPS.
Your true performance is much higher than that.
t.maxFPS 999
Remember what I told you about programs that fail when the context changes?
Well, I’ve noticed that the same thing happens to me in the behavior tree.
I programmed it at caped at 30 FPS.
Now when I want to test it at 120FPS the NPCs don’t move.
At least I know it’s a time-related problem.
So from time to time it is good to test different FPS and in different contexts (not all computers behave the same way). There is a concept called over-optimization (over-fixed). It is when you optimize the parameters too much for a specific system and then it only works on that system. And it doesn’t work anywhere else.
First, let’s describe the RetainerBox parameters: RetainRender - enables the material effect for child elements, so this should be true RenderOnvalidation - makes the RetainerBox content redrawn every time the widget is updated (for example, when the text changes) RenderOnPhase - makes the redrawing regular. If Phase = 0 and PhaseCount = 1, it will repaint every frame, and if Phase = 0 and PhaseCount = 2, it will repaint every other frame. But I didn’t understand how it would work if Phase is greater than 0.
What I did, for text UI elements I made the parameters RetainRender=true and RenderOnvalidation=false, thus RetainerBox is redrawn only if the text or its parameters have changed.
However, for graphic elements in which the change occurs at the level of dynamic material, this approach is not suitable. Unfortunately, in the widget BP it is impossible to set RenderOnPhase, so I also have to do RetainRender=true and RenderOnvalidation=false, but I manually redraw RetainerBox
But for a widget with a RTT-based minimap this approach is not suitable and therefore it is necessary to do regular redrawing using a timer with specified frequency parameters. In this case, I update RetainerBox every second frame.
So, as a result, I got a decent performance with a fully functional HUD
Editor, cinematic with no FPS cap
Why is there any RT at all?
Its 2d space.
Place blips of whatver you want based on Location rather than taking a RT for the minimap.
Learn how to just plot a point/circle inside of a UV based on a location.
Also passin in the Z rotation.
At that point, draw a shape that represents whatever oriented in the rotation you passed along.
The rendering cost of a widget that does this is probably .0001ms - compared to some 15ms of a render target (maybe 8ms if completely stripped? Probably too generous for ue5).
But why does 5.4 consume significantly less memory?
Yes, I thought the same. The original idea was that I would only need the blur effect on a small area of the screen and therefore did not want to apply it to the entire screen.
Because I want to show scene elements on the minimap, and since my level is generated automatically, there is no other way
As I have written many times above, in 5.4 I have no problems with this at all. Someone broke something in 5.5 and the performance dropped significantly.
I constantly read here that I did something wrong, yes it is obvious that I did something wrong, it was trying to switch to 5.5. On 5.4, all other things being equal, there are no problems with performance.
Your advice about minimap is bad, because I want to show exact objects, not generic blips. And my scene is dynamic, so I have to update it regularly.
Just in my experience, render targets are one of the things that breaks the most when migrating a project to a new version, sometimes deleting and undoing it is enough to get the engine to behave better, other times I’ve had to click every checkbox twice for every setting in poorly performing parts of a project or remake those elements from scratch.
