Porting our project to unreal engine?

[Dream_Powered]

Hello Everyone,

First post here!

Our team is currently reviewing Unreal Engine in order to port our game which currently uses the Neoaxis Engine

Of course it wasn’t as pretty as Unreal, but our tweaked renderer was running quite nicely with a large number of assets per level (over 50k, with logic, particles) , and the levels filesize were kept pretty reasonable.

The only issue is that Neoaxis doesn’t supports deferred lighting, which has been supposed to come for the past 3 years or so.
In addition to that, we were in partnership with NeoAxis team, we did our part (optimisations sharing, community management, tutorials etc) but the developer of the engine didn’t do his part, took our code and contributions, stole the money one of us lended him and banned us, as well as other people from the community (who just renewed their license) from the forums and completely locked them.

So we will stop using Neoaxis and are looking for a replacement.

UE is for sure looking great graphically, but we have some specific requirements in terms of performance considering how our levels are built.

• Our game happens in Dungeons, so only a fraction of the meshes are rendered at the same time. At the moment, culling relies on an old school portal system (but it works well)

• Each levels are build with small walls,ceiling etc… chunks and contains approximately 50k Assets (in that around 20k are small details meshes without collision), 95% of them being static meshes. the rest are lights/particles/dynamic objects/logic. There is around 300 unique meshes per levels, so everything is currently heavily instanced or batched ( physX + rendering batching, for meshes lower than 1000 tris, which is something like 90% of the meshes) in Neoaxis.

• Physics and tick are also disabled with camera distance (currently 200 meters), so we don’t have perf problem with these.

From our preliminary tests, unreal doesn’t seem to have batched static meshes and instancing doesn’t seem to be automated, so the performance when having a large number of mesh doesn’t seem to be that good.

I am wondering, is there a way to make theses kinds of level in UE? Is there batching for rendering and physics implemented? What about instanced meshes. I have read a bit about it but it doesn’t seem to be automatic? Can we implement theses ourselves?

It seems there is the possibility to split the level in sublevels, but would this work for non linear levels? Will it be able to load all the static meshes for the chunks next to the player with background loading (that still means quite a large number of meshes!)? What does it means for level designers, would they have to work one (or a few) chunks at a time in the editor and not on the whole level?

We will probably have a lot of other question for you guys later, but for now, this is our biggest concern.

Thanks a lot for your help,

The Warcry team

[Kris]

Instancing is supported, but I have no idea about automatic instancing.
The entire source code is available on GitHub, so, yes, you could implement it yourself.

Have you looked into level streaming?
All your sub-levels / pieces could be done as separate chunks, then loaded/unloaded as required.

[darthviper107]

By default, it will load an asset only once into memory if it’s used multiple times. But to improve draw calls you can use Blueprints to do Instanced Static Meshes, but that’s not automatic. It sounds like though that it should be able to automatically calculate visibility and hide objects that aren’t visible which would fix performance.

[jwatte]

considering how our levels are built

If you switch engines, you will realistically have to consider re-building all levels and game logic. Source art, like Max/Maya files, Photoshop textures, and so on, generally can be re-used.
This generally means re-implementing existing game systems, which is much faster than inventing them from scratch, but it is real work.
Also, you’ll probably want to build a throw-away small game for a month in the new engine, to learn how the engine works, before actually porting over your big project.
It may seem like you’ve stalled out while you’re doing it, but it’s totally worth it, so that you avoid the biggest problems when you actually work on the full port.

When you say “particles,” do you mean “particle system instances”? Because the runtime cost of a particle system depends a LOT on how big the particles are, how much blending overdraw there is, and such.
Also, if you can’t express the particle effects you want as Cascade particles, then you’ll probably have to re-think how those are expressed (see “re-build your levels” above.)

[Firefly74]

Hi ! thanks for you answers !
( i’m working in the team )

@Kris;613748

Instancing is supported, but I have no idea about automatic instancing.
The entire source code is available on GitHub, so, yes, you could implement it yourself.

Have you looked into level streaming?
All your sub-levels / pieces could be done as separate chunks, then loaded/unloaded as required.

Having to deep dive in engine sources without the experience is not a good idea i think, also, we would have already quite enough work to do while porting.

Had a small look at level streaming, i don’t really know the good practices for it, but even though, its looks like not enough

@darthviper107;613759

By default, it will load an asset only once into memory if it’s used multiple times. But to improve draw calls you can use Blueprints to do Instanced Static Meshes, but that’s not automatic. It sounds like though that it should be able to automatically calculate visibility and hide objects that aren’t visible which would fix performance.

i had a look at the instanced static meshes, but after testing the work-flow in editor, looks like it’s not meant for it. You suggest to generate the instanced static meshes at runtime ? ( and remove the classic static mesh at that time ? ) does using this change anything in culling/ physic ? ( that also mean poorer perfs in editor if optimisation is only enabled InGame )

I tried the Foliage system, perf looks quite good and it support manual edition, is there any limitation known to this system ? ( culling ? )

@jwatte;613763

If you switch engines, you will realistically have to consider re-building all levels and game logic. Source art, like Max/Maya files, Photoshop textures, and so on, generally can be re-used.
This generally means re-implementing existing game systems, which is much faster than inventing them from scratch, but it is real work.
Also, you’ll probably want to build a throw-away small game for a month in the new engine, to learn how the engine works, before actually porting over your big project.
It may seem like you’ve stalled out while you’re doing it, but it’s totally worth it, so that you avoid the biggest problems when you actually work on the full port.

Yeah, that will be quite some work … Once we have our assets ported ( flowing a structure / naming convention )i will do a map converter ( for all basic things like static meshes and decorative objects )

I’ve followed some tutorials, and tried to reproduce some stuff we had ( character controller ), looks like hard work, but far from impossible. Our biggest concern at the moment is rendering perfs with a large number of object in the scene (we didn’t though the old engine had more automatised optimisation than UE4, we have our full level loaded at once there, sounds strange to have to use level streaming here ( but we will if it’s the only solution ))

i know comparing is probably not relevant because the engines internals are really different, but it had default instancing ( for every meshes, static or not ) + static batching ( obviously batched mesh are not instanced anymore ) for static meshes that enabled it

( i’ve found this post, i didn’t understood everything ( static path ? ), but that’s the only one saying static batching is working in engine , do you guys know something that would help to search in that direction ( i think we will contact the poster )

Thanks again for your answers !