Ark: Survival Evolved: Low fps becaue of UE4 or due to no optimizations?

[slayeruk]

@CNKIT;317287

im not an programmer but i do use c++ for some projects and i write all base functionality in c++ then use blueprints to manipulate it in-engine (children and such)

example:

i write up a base class for a projectile in c++ and use it as the parent class for a blueprint. then i make a ton of children blueprints based on this (i once had 33 blueprints based on a single custom class made in c++) whats to say thats not what they have hence all the number of blueprints?

I am assuming that is exactly the reason fo the large amount of blueprint files.

They made some custom classes in c++ and then when actually creating the game they glued it all together with blueprint, that would make sense.

You are also ignoring the fact that they said they used profiling tools to see where the bottleneck is, and it was GPU.

[mordentral]

@Burnz;317255

Almost nothing done with blueprints ? Just the AI, spawning, inventories, structures, networking, buffs, projectiles, UI, gathering. The folder Content\PrimalEarth\CoreBlueprints consists of 1196 files. And again, in the PDB i could not find a single class that wasn’t automatically generated by a blueprint. You don’t seem to understand that blueprints are converted by the engine into C++ code - those are automatic generated classes. So of course the game is made of C++.

That’s exactly why we have this conversation. You cannot lie about the game being made by 99% custom C++ code when you release the evidence that it’s not so - the pdbs and the folder structure shows what’s true, it’s not denyable. If you want to proof me wrong then do it with facts, with evidence, not with another quote from the developer. I showed you facts that everyone can verify, you just give me ********. Proof me wrong instead.

Just look at the BPs, they shipped all of them with the dev tools so they are directly accessible to you, the “blueprints” are just subclasses of the base c++ class (item/creature) to set variables, there is literally no Blueprint scripting nodes in any of it except for the HUD (fine) and AI (using states). In fact I don’t think any of them know how to even use the blueprint scripting system based on the template mod they shipped out as it is an in efficient rats nest of nodes, so if anything they are lacking in knowledge with the very thing you accuse them of solely using, also please don’t say that blueprints are converted to c++ again.

You are showing a direct lack of understanding of UE4 by declaring any of this as a problem. You are totally correct that there is a blueprint for each item and creature in the game, they expose public variables to the designers to change values in, however there is NO game logic in any of them as that is all handled in c++. They are using the engine as it was meant to be used currently.

You can even directly use Stat Unit in game right now since it has console accessible and see that the game isn’t CPU limited at all, so even if they were doing what you claim, the problem STILL isn’t there, but would be with the rendering pipeline that they set up and their Global Illumination.

[Pirate]

I played ARK and the first thing I noticed after the dozen shootergame.exe crashes ( btw any programmer can rename shootergame to whatevergame in a matter of seconds) when I looked at the files was that it was just full of slopped together unoptimized marketplace assets. **** piled on top of ****.
It’s performance is bad because of it’s core design, skill level of developers and it’s use of unity assets sold as UE4 assets with wasted memory on oversized textures.

But hey, they made enough millions to either fix the performance issues or vanish with all the money. So good for them! (so not jelly) Either way I guess that makes this is a pointless discussion.

[anonymous_user_0dc1700e]

You have multi-threading out of the box on a per object basis, just set this in BP or somewhere in code on your tick-able object…

bAllowConcurrentTick = true;

Bam, multi-threaded per-frame actors or component ticks, seriously how hard was that?

They even block the render thread for you so that you can be sure your async tick is done in the current frame. Threads that block the game thread are of course not the place for long running processes, and just be sure your tick function doesn’t access anything it shouldn’t, and be sure to make sure to guard your critical sections with atomics, and keep your async thread out of places it shouldn’t be.

Welcome to the world of procedural programming.

[Cpt.Trips]

@Bleakwise;393569

You have multi-threading out of the box on a per object basis, just set this in BP or somewhere in code on your tick-able object…

bAllowConcurrentTick = true;

Bam, multi-threaded per-frame actors or component ticks, seriously how hard was that?

I know this thread is ancient, but maybe someone else stumbles upon it following the same bread crumbs.
As far as I can tell, bAllowConcurrentTick is for Component Actors only.
For Actors the property would be PrimaryActorTick.bRunOnAnyThread = true (it is false by default).
After enabling it in a test, my average CPU usage doubled with noticeably more cores working.

I don’t know if it is available for Blueprint actors, but exposing this would be a no brainer (e.g. create C++ actor class add the line to its constructor and parent BP actor off of it).