[SOLVED] Unity vs Unreal Performance Comparison

// [SOLVED] The problem was in my graphics settings on nVidia Control Panel. For some reason, Unity wasn't even listed there to use my nVidia Card, it was uing my Intel card. I had to manually add it to the list and tell it to use GeForce Graphics. Now running Viking Village at 100+ FPS. So it wasn't at all any problem with Unity optimization. Stay sharp in case this problem happens with you guys! Thanks so much for the feeback. //


Hey guys, I made a scene performance comparison between Unity and Unreal and I'd like to understand more of the results. I downloaded The Courtyard and Viking Village from Unity Asset Store, but they ran pretty poorly on my laptop, around 10-20 FPS. So far we could think that my laptop lacks power, but I installed and downloaded very heavy scenes from Unreal and it worked more than smoothly. The scenes from Unreal were these:

https://drive.google.com/open?id=0B5D-l5Wy4jNiaDRXR2ZOVHhJV0U

https://drive.google.com/open?id=0B5D-l5Wy4jNiNnZDbUtOM3EtT00

So, both scenes are full of GI, Reflections, Refractions, realistic materials, the first scene has 410 objects and the second has 2291 objects (though not all in view). The second one has multiple light and particle effects rendering realtime. And though... you can see the FPS at the top right corner in green: 119 for the first scene, 51 for the second.

Whereas in Unity, for the Courtyard and Viking Village, I got no more than 10-20 FPS. How come? Both scenes in Unreal are much prettier, full of rendering features, particles, you name it.

I wonder if this is due to GPU x CPU usage difference, but I consider my hardware is pretty decent to run.

My system configs:
Dell Inspiron 7559
Intel Core i5-6300 HQ
8GB RAM
GeForce GTX 960m
Windows 10

What you guys think? unity wasn't supposed to be faster? Is it my hardware?

Thanks!

 

I'd like to know also.

 

I feel like it isn't a particularly fair comparison. Neither of those Unreal demos, at least as far as I'm aware, are using a terrain system like the Viking Village. Unity's terrain system is known to be very sluggish and it wouldn't surprise me if most of the problems originated with that.

 

Try to import the viking scene in unreal and you will know exactly what's different. The process of porting it should be revealing of the difference too.

 

Good point, but I just deleted all the terrain in the scene. FPS raised a bit, but not much, 25-30 depending what is in view, both in editor mode and game mode. Pretty poor performance, and even if it was the terrain's fault, it would be very bad as well. Any more thoughts?

I'm not trying to depreciate one or the other, I'm trying to understand. Besides, the same or worsse happens in the Courtyard scene, and there's no terrain.

 

I don't think this would be very optimal, because I don't believe the problem is in the meshes, and lights and rendering would be particular of each software. But good point, I'll see if I can do that.

 

Unreal DOESN'T have global illumination enabled by default. Unity has realtime GI. To kill performance in unreal, use a lot of reflective surfaces (see content examples demo).

Courtyard demo is a tech demo with custom shader. Also lighting is very different in both engines.

Spoiler

Skip to something like 12:00 unless you really enjoy watching progress bars.

 

That's the point, we need to see HOW Much difference there is to have a direct comparison. We could compare lighting, workflow, texture handling, shader handling, GI, light baking, etc ... because the necessary correction will be as informative as the actual performance, for example how do translate unity terrain into unreal terrain? maybe it will tell us something about how both terrain are handled and the nuance between the two?

Because it's easy to create scene that takes advantage of each softwares good points, direct comparison allow those elements to not be hidden.

 

True enough. I'll do that.

 

I have no experience with Unreal Engine, but I feel like it's a safe for me to assume that:
- Epic has many more and much better content creators than Unity. They started out making games and have made numerous AAA games after all.
- because Unreal Engine is a AAA engine made for AAA quality 3d graphics (which is what you're showing here) it probably has easier and better occlusion culling and similar performance tools built in.
- lastly and most importantly the demos in Unreal Engine has probably had a lot more effort put into optimization for the exact reason that AAA quality graphics is what Unreal Engine markets itself with and if they run really poorly that reflects poorly on the engine.

The Unity demo teams are probably 1/10 the size of the Unreal Engine demo teams, and they can't afford to put a lot of time and effort into optimizing their demos, but I feel like they should at least try a little because it feels a bit sloppy when they release things like the old Unity Labs demo where I was able to double or triple (I don't remember exactly, I wrote about it on the forums) the fps just by deleting a horribly optimized particle system that was invisible in the demo 99,9% of the time. I'm sure someone could make that scene run like butter if they put some effort into it. And I'm sure the same applies to the Courtyard and the Viking Village demos as well.

Edit: If you're curious you could try optimizing the demos yourself. I would perhaps start with the Viking Village demo because the Courtyard has some extremely expensive effects in it. Effects you wouldn't put in an actual game. The Viking Village would probably run a lot better if you used occlusion culling and level of detail in it. It wouldn't tell you anything about Unreal vs Unity performance, obviously, but it would show you that using horribly optimized, rushed demo projects to compare with isn't ideal.

 

I am starting to think that making such comparison will not be a good idea, because engines are too different (culling, rendering, everything). One of them may outperform the other in very specific conditions because of that.

Speaking of performance, usually I would expect unreal to perform better than unity most of the time.

 

Didn't someone do a western town scene in Unity and Unreal a while back.

Found it -> http://not-lonely.com/blog/making-of/unity-ue-comparison/

Looks like they did not compare performance just graphics.

That would be the ideal way to compare, take a complex 3D scene/world and put it in both engines then compare the FPS.

But probably best to build a prototype of your game in both engines and compare them for that type of game.

VR's performance demands should really test the performance of all game engines.

 

It is true, but Unity didn't have to do the same things at the Unreal level, but they should optimize what they commited to do, right? It's kinda disappointing to see these differences. Also, differences in files size: Unreal scenes are around 500-600MB, while Unity scenes are around 800MB-1GB, worse performance... I don't intend to depreciate Unity, on the contrary, I think they rock. I'm trying to understand more and see what I can do to optimize better my projects.

 

So cool comparison! Thanks for sharing this. Unity has come very far and very fast in terms of capabilities. Both in this project look just equivalent, with some differences in the aspect of lighting.

 

It's worth noting, according to blog, that unity's demo team are mostly artist, with just better access to technical team than us. So it's really not comparable, when I read stuff about unreal, it's their technical team the star of the demo (even art heavy one).

 

But each and every dev on Unity should be prepared to make something optimized, especially with this landmark projects which define the whole version of Unity. They know people are going to download the projects extensively, so it should be optimized. Nonetheless, I just would like to know what can be done to optimize projects, because I suffered from low performance on the editor in another laptop I had. It was indeed the reason I bought a new laptop.

 

I use to develop on intel GMA I share the pain, making the same game on blitz3D at 60fps then moving at 10 fps on unity was my saddest experience, I hadn't even reach graphic stage, it was the physics ... just the prototype, and the blitz version was more heavy graphically lol

 

An interesting point: The author states he gets 45-50FPS in Unity with pre-computed GI and 60FPS in Unreal with baked lighting. He also says that without baking the lighting in Unreal, all realtime, he gets 12 FPS. That says much, but he compared Unity and Unreal both originally baked and he still got significant difference in FPS.

 

Given Unity can do pretty complex mobile phone titles, this would indicate just inexperience in Unity. That's usually the case for people coming to unity from other engines, they don't know the best practises.

 

No, he didn't compare both engines with normal baked lighting. In Unity he used precomputed realtime GI which is more expensive but also more dynamic than normal baked lightmaps.

For a real comparison, he would have had to use baked lighting on both engines. But there are also other differences in the two scenes (lighting setup seems different, there might be differences in shader complexity, post processing seems a bit different..even placement of some objects is different), which make it hard to draw definitive conclusions.

 

Interesting. When it comes to overall quality I can't decide on one being better than the other. On the inside scenes the UE shots have much cooler lights coming in from the windows, but the lighting in both varies so much I can't say either is bad or even worse than the other. I also like the wheels on the wagon better in the U5 shots; metal rings looking right, while it seems the UE version is all wood. That'll splinter!

 

Hmmmm that's true.... so if it is realtime, what does "pre-computed" stand for? For me pre-computed is at least very similar to baked, isn't it?

I got a very interesting feedback in another fórum. A guy downloaded the Viking Village with a GeForce GTX 960m and he got 100+ FPS. He said that maybe Unity is using my on-chip card instead of my nVidia card. I'm checking this now to see if that was the case.

Thank you for all your feedback guys. I'll let you know if I resolve anything.

 

It means that changes in lighting (light color/intensity, emissive material changes, etc) will affect the scene in more or less real time... for all objects that were "baked"/precomputed. Precomputed GI only works on static, non-moveable objects and precomputing takes forever.

 

Well, guys... weirdly enough, IT WAS my nVidia settings. For some reason, Unity wasn't even on the list to use my nVidia card. I had to manually add it and tell it to use my GTX, because it was using my Intel graphics. Now it runs smoothly at 100+ FPS. That was awkward, but also fortunate.

Not sure why Unity was not set on nVidia graphics but default but... mistery solved. Thanks!

 

The thing that annoys me about this kind of thing is that in Blitz, XNA, etc the movement was always rock solid. Just smooth. Sure if throwing too much around you'd get slowdown fps dropping from 60 to 30. But still everything was consistent. In Unity, I can have just one object moving across the screen wrapping around at edges and it is never smooth regardless of vsync on or off. It's like there is a bug in the Present/Flip/Whatever code that updates the display. Some kind of timing issue that causes the object to stutter/jerk. I wasted a lot of time in the past trying to get rid of it but finally just accepted it's just how it is.

 

You will experience jerky movement when you're trying to track physics-driven object from script-driven object and vice versa. Physic engine runs at fixed framerate and requires magic in order to create illusion of movement. That magic is not good enough when object tracking is involved into the process, though. Also, tracking code must be placed into LateUpdate.
https://docs.unity3d.com/Manual/ExecutionOrder.html

It makes sense to put all camera-movement-related functions in LateUpdate as well. Needless to say, those functions shouldn't move anything that is not camera.

 

I never use that physics update can't even remember what it is caused. I also don't use any of the physics other than performing casts. I thought about just completely replacing that part as well with a simple OverlapRects check but I like the physics casting methods. They work well. But maybe if I get rid of that last bit of physics stuff that will help.

I'll try using late update sometime after I finish current project. Seems like I tested that before but definitely worth testing again if it solves the issue. I only know that in my research of the issue there are a lot of people reporting the same thing. In 3D it is not really noticeable at least not nearly as noticeable as 2D.

 

It doesn't matter, the kind of code I need must happen in the fixedupdate anyway or it's lost and the control are broken. I cannot NOT use physics else I don't have any contact information, no matter how much I try to neuter it. Most people who are adamant it works, have use case that don't match the sophistication needed, and are just happy with the bugs, stutters and less than perfect control, but it suit their games not mine. And people who have a solution rolled their own closed source physics solution that use polygon soup anyway.

I spen... LOST 3 years chasing that ... For this project I might shift to godot, just reading the collision feature seems like they got my case covered ... Unreal scares me.

edit
I even discovered you should use OnGUI to listen to key events that's a hack, you buffer them into a list and now you have good input timing.

 

Err... I hope you aren't placing control logic into fixedupdate. Fixed update happens in bursts, and placing response to user controls there result in wacky behavior. Basically, FixedUpdate is a place to query for collision info + you could apply forces there, but spawning, moving/etc should happen in Update. Looking with camera at something should happen in LateUpdate (and nothing else should move there)

Also... do you both (meaning you and @GarBenjamin ) have minimal example of your issues?

 

That's what is was called... FixedUpdate. I don't use that all. I can knock one out but you should be able to do the same. Just create a sprite a solid rectangle (obviously large enough to be able to easily see the stutter) and then make it move across the screen left to right (or vice-versa) and wrap around to the other side.

See if it ever moves across the screen smoothly. Maybe it is because I am used to playing games from long ago where this kind of thing was always rock steady and smooth, time spent with Blitz and XNA or both. So maybe most devs these days don't even notice the jitter.

 

I do that, but having decouple physics update and control is bad anyway, it mean control are lagging from physics in a way that fracks me up, so Update is a nono. But I still need physics listen to point of impactS, that's a plural, then act accordingly, moving the logic into update fracks thing up, so I update the collider in fixed update which frack up the FPS ...

Now it's some years back, I haven't revisited the code, here it is for extra fun

Spoiler: code

Code (CSharp):

1.     bool TestCollisions ()
2.     {
3.         float CeilingTest     = -MOTION_CEILING;
4.         float GroundTests   =  MOTION_GROUND;
5.         float FrontTest     =  MOTION_WALL_DIRECTION;
6.         float FrontFactor     =  0;
7.  
8.         bool Align             = false;
9.         bool ShouldAlign    = false;
10.         bool Result         = false;
11.        
12.         //create normal vectors for temporaly storing the alignment
13.         Vector3 CollisionNormal      = Vector3.zero;
14.         Vector3 GroundNormal      = Vector3.zero;
15.         Vector3 CeilingNormal      = Vector3.zero;
16.  
17.         float DotProduct= 0  ;
18.        
19.        
20.         //Iterate through each collision and
21.         //register all the collision data
22.         //that may occured within the player sphere
23. //#################################################################################### IN collision loop
24.             //----------------------------------------------------------------------------------------------------------------------------------------------
25.             //
26.             //----------------------------------------------------------------------------------------------------------------------------------------------      
27.        
28.         if (collision != null && OnCol)
29.             {
30.            
31.            
32.             foreach (ContactPoint contact in this.collision.contacts)
33.             {
34.                 //Clear current collision normal
35.                 CollisionNormal = Vector3.zero;
36.     //----------ShouldAlign = false;
37.            
38.                
39. //select {entity type from collision object}
40.                
41.     //----------case Collision_world_polygon_align
42.                 ShouldAlign = true;
43.                 CollisionNormal = contact.normal;
44.                 DotProduct = Vector3.Dot (CollisionNormal, this.Motion_Align);
45.            
46.                 //mesh without collision at all like world limit
47.     //----------no translation >> case collision_world_polygon
48.                
49.                 //for moving platform and the like , disable vertical slope align
50.     //----------no translation >> case collion_world_box
51.    
52. //end select
53.             //----------------------------------------------------------------------------------------------------------------------------------------------
54.             //
55.             //----------------------------------------------------------------------------------------------------------------------------------------------
56.                
57.                 //test for ground collision
58.                 if (DotProduct > GroundTests && (vSpeed <= 0.0 | this.Motion_Ground))
59.                     {
60.                         if (ShouldAlign)
61.                         {
62.                             Align = true;
63.                             GroundNormal = GroundNormal + CollisionNormal;
64.                         }
65.                    
66.                         GroundTests = DotProduct;
67.                     }
68.                
69.                 //test for ceiling collision
70.                 if (DotProduct < CeilingTest && vSpeed > 0.0)
71.                     {
72.                         CeilingNormal     = CeilingNormal + CollisionNormal;
73.                         CeilingTest     = DotProduct;
74.                     }
75.                
76.                 //test for front collision
77.                 if (DotProduct >= MOTION_WALL_UP && DotProduct <= MOTION_WALL_DOWN)
78.                     {
79.                         //even though the dot product told us there was a collision
80.                         //it may have been everywhere around the player
81.                         //check out the orientation of the collision
82.                         //with a cross product
83.                         CollisionNormal = Vector3.Cross (CollisionNormal, this.Motion_Align);
84.                         DotProduct         = 1 - Mathf.Abs (Vector3.Dot (CollisionNormal, this.transform.forward));
85.                        
86.                         //finally test for front collision
87.                         if (DotProduct > FrontTest)
88.                         {
89.                             FrontTest  = DotProduct;
90.                         }
91.                    
92.                     }
93.             }//end for
94.         }//end if
95.         else
96.         {
97.             //print("null");
98.         }
99. //#################################################################################### OUT collision loop
100.             //----------------------------------------------------------------------------------------------------------------------------------------------
101.             //
102.             //----------------------------------------------------------------------------------------------------------------------------------------------      
103.        
104.         //if there is a collision on the front
105.         //calculate how much the speed should drop
106.         if (FrontTest > MOTION_WALL_DIRECTION)//dot:0.30 / 63°
107.         {
108.             FrontFactor = 1f - Mathf.Min (((FrontTest - MOTION_WALL_DIRECTION)
109.                 / (1f - MOTION_WALL_DIRECTION)) * Time.fixedDeltaTime * 1.2f, 1.0f);
110.            
111.             hSpeed = hSpeed * FrontFactor;
112.             //Debug.Log("front");
113.         }
114.        
115.        
116.         //once we know there's a ground collision for sure
117.         //change alignment
118.         if (GroundTests > MOTION_GROUND)
119.         {
120.             if (Align == true)
121.             {
122.                 GroundNormal.Normalize ();
123.                 this.Motion_Align = GroundNormal;
124.             }
125.             else//never happen because not implemented
126.             {
127.                 this.Motion_Align = this.LocalGravity_Alignment;
128.             }
129.            
130.             Result = true;
131.        
132.         }
133.        
134.         //if no ground collision was found
135.         //maybe there's ceiling collision
136.         else if (CeilingTest < MOTION_CEILING_STOP)
137.         {
138.  
139.             //if the ceiling slope is low enough
140.             //Make sonic land on the ceiling
141.             if (CeilingTest < MOTION_CEILING_STOP)
142.             {
143.                 vSpeed = 0;
144.                
145.                 Result = false;
146.  
147.             }
148.            
149.             //if not, adjust to new aligmenent
150.             else
151.             {
152.                 CeilingNormal.Normalize ();
153.                 this.Motion_Align = CeilingNormal;
154.                 Result = true;
155.             }
156.         }
157.         else
158.         {
159.             this.Motion_Align = this.LocalGravity_Alignment;
160.  
161.             Result = false;
162.         }
163.        
164.         OnCol=false;
165.     return Result ;//&& CastEdge();
166.     }

 

So UE4 added itself to the nVidia setting but Unity doesn't? If that's the case, report it as a bug as Unity really should do this + all unity games, otherwise people playing your game will have same problem as OP.

 

Thing is that it's actually not Unity (the engine) that registers to be executed on nVidia HW. It's the application that has to be registered to use nVidia. It has been like this for ages.

 

You know, one of the first things I did in unity was putting control into Fixedupdate, and that was a horrible idea. It is horrible idea because FixedUpdate is not running at fixed intervals, but it is called several times in a row without pauses BEFORE Update(), which means that if you put control reponse there, a few millisecond delay in button press may propagate to several frames of difference in movement. After experimenting with this a bit I came to conclusion that fixedupdate should ONLY be ever used to register collisions and query ocllisions. Not to respond to collisions, but just register that they happened. Also, you definitely shouldn't spawn anything within that function. Keep in mind that on a powerful system Update will be called more often than FixedUpdate.

There's a very high chance my test app won't be having your issue because I'll probably do something differently. That's why I asked about minimal example.

 

I Did had control in update, there was no choice anyway, fixed update don't register control, they are only polled at update interval, the problem is that you already had many fixed updates (and therefore collision events) between inputs, so it's worthless for the kind of control I wanted ...

 

Yeah it's just that UE4 does do this. So Unity ends up sucking as many people aren't aware this even exists. It needs to be added to player settings, and Unity itself is an application unless you forgot.

 

Currently I'm under the belief that you will have the issue no matter how you decide to implement it. Just displaying a moving rectangle regardless of how it is actually done I think will produce the jitter because it seems to be some kind of glitch in the underlying systems between updating the position internally and it actually being updated on the display.

I can throw one together but probably not this week because I want to wrap up this current game project and release the code.

 

@neginfinity Probably the dead easiest way to notice it is to make two sprites. Just rectangles solid color. Place them side by side snapped together. Now move them independently at the same exact speed. Be sure camera is positioned on even pixel coords and be sure the gameobjects are positioned on pixel coords. Watch what happens.

Now the interesting thing is if you create a parent GameObject for both of those and only update the parent they will stay perfectly together although you still get the stutter.

It seems like some kind of timing issue at the core. Like sometimes it takes more than a single monitor frame just to update and render one rectangle. Other times it is easily done within one frame. Which also makes me think maybe the display update just isn't synchronized with the monitor.

Actually you may be able to find a sample project because just doing a google search for unity3d display stutter wil bring up a lot of hits.

 

Is it not more likely to be a minor floating point error?

 

Possibly for the two objects getting a seam between them at times but if locked to pixels it shouldn't do that. And I can't see the overall stutter being floating point related but who knows. I don't know how they are doing things internally.

It's not a major thing at this point because I just accepted it happens with Unity. Still I am wondering why? Actually I seem to remember @hippocoder mentioning in the past that he ran into the same thing and no matter what he tried the "gremlin" wouldn't go away.

 

Sorry if it has already been mentioned, I didn't read other replies:
Did you try this?
http://docs.unity3d.com/540/Documentation/ScriptReference/Rigidbody-interpolation.html

 

Yea I solved the early jitter, it's more the 9fps as performances that posed problems, that's what I'm referring to..

 

It almost seems like every object is being rendered to the screen independently. I can't imagine that. I'd expect all rendering to be done to a backbuffer and then flipped over to the display all at once.

OR every object is updated then immediately rendered to a backbuffer. And sometimes there is not enough time to do that so some are left behind. Instead of updating ALL objects and only then updating the display. Anyway I got to get off here.

 

It's worth mentioning in my case I had only two objects, the player spherecollider (rigidbody) with an animated mesh, the terrain as a collision mesh (same set up as blitz3d).

 

Your kidding? I have to check my settings too.

 

@Harry3D
Are you using OSX? If so, could you explain how to change those settings?

 

I'm looking at my Nvidia control panel and not seeing any program listings, could I ask, where did you change your settings? And how did you determine that Unity3d was not using your graphics card?

 

That's for laptops.

 

Um, well I am on a lap top, has a 4 gig Quadro.

 

Well, I have Intel GPU disabled in my BIOS specifically for that reason.