LY efficiency for VR compared to UE4

First, I’d like to avoid any name-calling and fanboy answers. Quite simply, I found UE4 quite challenging to run at 60fps in VR in my last couple of titles. There are a lot of inefficiencies in UE4 that I’m hoping to avoid if I move to LY.

In UE4, most logic with any meat on it ran 10-11x slower on BP than in C++ (using stat startfile/stopfile for measurement). Any time saved with rapid BP prototyping at the beginning we pay back in spades when it comes time to optimize. On a smaller team there’s not much time and resources for converting things to C++ as they get finalized. A lot of things got finalized at the last minute as well.

There are some ridiculously expensive things in UE4; or ridiculously implemented. Moveable actors are ridiculously expensive on the render thread (when any actor moves it gets removed from the scene, deleted, and new one recreated and added to the scene). Dynamic shadows are very expensive and pretty much turned off save for a few small lights during key moments in small areas. Any gameplay systems included in the engine are ridiculously expensive, especially the Character Movement Component; others like the perception system are pretty bad as well. Pretty much anything Epic did in gameplay is pure crap from a performance point of view. We made our own version of most of their systems for 8-10x improvement in performance. The whole UActor structure is a bloated mess and they don’t have a lightweight version that would work better for large quantity of AI. A lot of these bloated structures get copied around from game thread to render thread, garbage collected, and perform inane number of sanity checks with no recourse for doing it any other way.

For LY, I imagine Flowgraph or LUA aren’t any better than Blueprints in terms of performance. Still running psedo-compiled code through a VM. So from that point of view FG and LUA I would only use for setup or simple instructions.

So how would LY fare in comparison with the other issues? Is there a simple lightweight way to move actors around and/or play animations for them? Is the basic actor a simple structure? Is the architecture tighter in comparison?

LY documentation seems insufficient at the moment. Forum activity is low, especially in Programming. Online searches for issues yield poor results. Not sure if the engine is ready for general development since resolving all issues on your own can be quite time consuming.

I did not ask the UE4 community what they thought of LY. I’m more interested in seeing if LY’s approach is more streamline.

In my projects I had direct access to Epic developers and our (major) publisher’s resources. I rewrote a fair amount of UE4 for performance, so I’m very familiar with that side of it. VR on UE4 with our target spec plus console was very challenging for our games at 60fps. I did not think our assets and gameplay were overly ambitious, and seeing what other major UE4 VR games had to do to get their games running 60fps, it seems like we were all in the same ballpark.

At any rate, if LY is more lightweight, that would go a long way for me. The fact it’s free and without royalties for the titles we’re looking at is appealing to those above me. If it’s easy to just associate a piece of code with some game asset and able to tweak parameters in-editor and handle calls and responses in c++, I would consider that a reason to try it.

Hey @rantrod, thanks for checking out Lumberyard for your project. We are definitely still early in our life cycle and continue to make strides in our production and roadmap milestone efforts and the community is continuing to grow and starting to become a great resource for peer-to-peer discussion and help. We do have a long way to go, but we are working towards it and we do have developers constantly monitoring the forums to help resolve issues in a reasonable amount of time. As for your more specific technical questions, one of our techs will hop in here to give you some more insight.

I really think it comes down to how well your team knows C++. You have access to the full engine and examples, so you can make it as lightweight as you want. Cryengine comes with an actor system, and even an example ISimpleActor interface example if you choose not to use all the features of IActor. The code is pretty easy to download and checkout for yourself. I really prefer Cry/Ly over UE4, although I’m just a hobbyist. The only thing I wish LY had is UE4’s netcode, GridMate in my opinion isn’t much of an improvement over CryEngine’s networking… I’d like to see what their plans are for it.

Thanks for the reply. One convenient thing in UE4 is the UPROPERTY system. Easy to associate assets to code that way. Is there a similar thing or a straight-forward way to associate assets to code in-editor in LY?

You have access to the full engine and examples, so you can make it as lightweight as you want

Sure, UE4 also gives you full engine source. It’s about how much time and effort needs to be spent changing the codebase to your needs, and doing so in a way that doesn’t prevent you from cherry-picking benefits of future versions.

In UE4 that time ended up being pretty high and we spent many overtime hours doing so. If LY is closer to our goals, that’d be great.

The code is pretty easy to download and checkout for yourself

True, but if we decide to investigate, testing it would not be easy or fast. We’d run a lot of diagnostics on it to compare it to UE4 and it would take a very long time.

Is CE or LY known for being better at handling a very high amount of actors? There were levels we ended up with >500 actors moving around simultaneously (had to build our own parallel pipeline for actors to make that happen). Wasn’t the actor system going to be replaced with something else?

Fanboyism is irrelevant and a time sink.

Logically speaking I find your exagerated use of ridiculously not the best way to make your point professionally, but that’s just me maybe they won’t bother anyone else.

I use ue4, and am trying LY , but ue4 has had tons more time to perfect. LY is a extention of cryengine and very much in beta so I"m not sure there really is a direct comparison.

I’m running a large terrain, highly detailed with expensive lighting and a not very high end rig that basically meets ue4 requirements and I get by just fine long as I abide by common perf. bottlenecks.

If I had a i7, it would be smooth sailing , prob. same here.

You are obviously welcome to your opinion no one would be bothered by that, but I must ask, did you ask any of these questions over at ue4 forums and give anyone a chance to answer ?

Btw, I"m experiencing zero slowdowns on my very elaborate terrain on a very non high tech rig.

YMMV I guess.

I like both engines for what they offer, so fanboyism here is non existent because the only thing on my mind is using the best tool for a given use.

Ty for your question.

Hello Rantrod,

Flowgraph is fully interpreted, i.e. not run in a VM and I couldn’t disagree with your assessment of it being as heavyweight as Blueprints. But the lua interpreter is relatively small and efficient, and I would think closer to the performance of a managed language like C#.

As someone else pointed out, Lumberyard was built upon CryEngine, and suffers some of the problems that CryEngine did in being very large, rather monolithic and neither very light nor very tight. However, recent Lumberyard work is improving things. We have a fairly sophisticated systems optimization program, and we have largely rearchitected the engine core with a modular component/entity system which simplifies the design and reduces interconnectivity of the engine, and enables us to make lighter weight components. I don’t feel that this effort is complete, but we are going in the right direction at high velocity.

It’s also worth saying that just because one engine is ‘lighter weight’ than another doesn’t make it better. It is possible to get amazing professional results out of Lumberyard as a result of its comprehensive rendering pipeline, fully featured content pipeline and so on. The fact that the code is in there isn’t a bad thing, and everything has a purpose. If you want the advanced features, they are there. And the fact that you are free to refactor, modify, chop and change, slim down and optimize the engine because you have full source does give you the ability to fix any problems that you encounter, or simply remove code for features that you are not using.

And in fact, with the Lumberyard Gems system, we are undertaking a lot of that effort for you. PRO TIP: everything, including your game, should simply be a Lumberyard Gem. Gems themselves are our way of breaking up the engine horizontally. In other words, as we are going through the various systems, we are breaking them out into smaller pieces of functionality. The core strategy is to give customers an a-la carte engine. If you want it, you include the functionality and if you don’t you can remove it. Now let me be quite clear that we are not there with this either just yet, but we are seriously tackling complexity management from multiple angles.

Lastly, it’s important to realize with any engine, the complexity of the data determines how long it takes to process all of that data. Really, the best way to do this is to make a representative piece of gameplay and look at what is slow, prioritizing data optimizations, to understand what can realistically be processed, and build art guidelines around the existing engine capabilities. If this doesn’t get results, then we can look at the code with you. We can help you instrument code, get profile captures, and suggest means in which either the code or data, or threading model or data representation/format can be improved to get the performance you need. Finding a millisecond or two per frame is not usually a big effort, but using the code well with good data, and crafting the data to work well with the engine can resolve most issues.

We hope you will try Lumberyard and benefit from the huge amount of work we are putting into it, and the functional and performance improvements that we are making over the long haul.

Al :slight_smile:
Solutions Architect

Lumberyard will still be free with full source code after we get out of Beta. Your use of Lumberyard will still be governed by the AWS Customer Agreement and Lumberyard Service Terms.

Thanks for your reply @Binky… For extra clarification, will LY be free after it gets out of beta?

I’m sorry, I think I misunderstood. It looks like you’re talking about UE4’s “everything is an actor.” Al Murray’s response below is pretty good.

Thank you for the comprehensive response Al !

I did look into Gems and liked the concept. Making the game itself a Gem is a great tip.

There are architectural decisions that affect all CPU performance. For example in UE4 all actors copied into mirror structures in the render thread and stored in a scene octree. When an actor moves in the level, it is removed from the scene, deleted and sent for GC, a new actor is created from scratch copying all parameters from the game thread, all light influences recalculated, and then re-added to the scene. In one of our levels with 120 actors moving, this process cost 7ms on its own!!! That leaves 9ms for the whole rest of the game. Reprogramming that system was a big pain.

Another example is all the sanity checks UE4 does. When an actor moves on the game thread a multitude of sanity checks happen: Is this actor supposed to move? Is it replicated? Is it parented? Are the links valid? Is the transform valid? etc, etc, etc. With just 15 actors moving in an empty level, the sanity checks cost 0.5ms which is not huge but in a level with over 500 actors, we were losing about 6-8ms to it. I created a parallel actor system where I eliminated all the checks we didn’t need and removed that overhead.

Lastly, Blueprints are a hog but Epic added a ‘Nativize’ button so it converts them to C++ code when packaging. Is there something similar planned for FG’s or Lua?

there is no engine to fit every kind of workload es just look at how many superadvanced 3d engines get stuck with abit more complex ui. I guess you need some time to evaluate properly do your profiling with your use cases.

Generally when you have order of magnitude in the many hundreds to thousands of something an ad hoc and possibly paralellized system could be really taken in consideration or also be the only hope (as you have find out in ue4) if the general solution requires working with not really lightweight elements get accessed and moved around. This kind of figures doesn’t really cope with script for non trivial loops especially if you iterate the entire set every frame and even more in a frame.

However merging here and there or changing updating strategies like interliving and other subtle tricks are sometime way more efficient than a brand new system and more in line with the kiss principle.

Nativize for lua doesn’t make sense as for very long time end effort own implementation of this nativizer would not be as efficient as just using lua jit(a far more realistic solution to your concerns) will require a huge amount of work and still not be the solution you are looking for.

Transpillers from dynamic to static languages with no Garbage collector use to do very bad things and implementing very naive gc strategies.

If script is your bottleneck probably you have delegated to it the wrong things.Nativize lua would require almost the same amount of effort cpp haxe required and if you look at cpphaxe you would notice that after all this effort it is still far from native.

The relative gain could be potentially huge in blueprint if you consider its performance baseline.Less can be achieved when your system is just way more efficient especially if you are focusing the wrong aspect to optimize.

Game maker also sports a script to c transpiller called yyc it is way faster than interpreter ,but still lags against native even if it has to convert a very simplistic language lacking whatever feature you consider advanced today and it doesn’t even need a gc as game maker has very simple memory management.

p.s. apart from lua jit lua can be precompiled to bytecode if i remember well and it saves a bit on the size and first execution timings.