How does UE4 stack up against CryEngine 5's rendering capabilities

I say, games development for the company.

The biggest problem with CryEngine 5 is the lack of documentation, tutorials, and assets that you can play around to figure out features.
I have to admit that CryEngine 5 is a very good engine but it is known to be lacking in updates. With the speed that Epic is updating Unreal, we know that Unreal Engine 4 will be improved in time MAYBE even to the level of CryEngine with their features that make level creation much less of a hassle.
Unreal Engine 4 is used by a lot of developers by a massive amount of creative people that are more than happy to share their work with other developers threw documentations or YouTube video tutorials.

If it was up to me. (and its only my opinion)

Blueprint in Unreal Engine 4 is a massive plus, even if C++ will be always better and more optimized than Blueprint it still very fast and easy way to create entire project.
Plus the lack of proper documentation from the CryEngine side makes it a no go for an indie development team that is still learning the ropes.

With CE5 they are pushing things faster, documentation, over +800 marketplace assets.

I’ve been reading its source code on sundays and I think is really impressive things they done as well.
CryTek is that kind of beast, never do anything but when it have something started it never stops until finished and burned out.

Never thought of it like that. Well, I’m convinced, it seems I’m going to start learning to program in C++ properly instead of relying on blueprint for everything. If those are my only choices (and paying someone else to do it for me is hardly a long term solution), I would rather come out of all this knowing how to program. Here’s hoping learning all that in my off time isn’t an insurmountable task to be any good at it.

Well, you can’t learn how to do everything, so it’s perfectly reasonable to find someone else to cover things outside of your ability. You don’t have to necessarily pay in cash; payment in kind (i.e skill share) is also an option. Skill sharing is good because whilst you’re losing time to solving a problem, the person you’re losing it to can probably solve it quicker (and better) than yourself.

True, but it’s been bugging me for a while now. Not really a fan of tying my entire skill set to a single game engine, seeing as how they come and go every few years. I’ve become too reliant on the UE4’s blueprint, and I’ve been using the material editor since the day the UDK came out (although to be fair, Maya’s Hypershade made the learning curve for the latter a bit easier). I can’t write a single line of shader code or make anything past a basic command line game in C++, yet I can make any material I want in the material editor and I’ve made a 60% complete game with all of the art and scripting done by myself thanks to blueprint. Continuing like this, I’ll end up being amazing at Unreal and not much else.

Unfortunately I don’t know any programmers that would be willing to do that (or at least any that have the time), so for the time being at least everything on the project falls on me.

Fortunately, material concepts translate really easily into HLSL when you start learning (but learn C++ first as HLSL is not forgiving) - gameplay programming in UE4 isn’t too bad either, since you’ll find you’re basically using the C++ functions that the blueprint nodes call 75% of the time, and stuff like math fits nicely on a single line rather than sprawling across multiple screens.

With UE4, I have:

  • Prototyped a mobile quiz game that shuffles questions, answers, and records score in just 2 hours
  • Written a material for swinging vines that automatically handles sway and stretch through vertex animation by itself (different sizes are automatically calculated)
  • Applied final lighting and post processing for a complex underwater scene in just a couple hours
  • Created mist particles with fully featured lighting, soft cutoff, and a variety of optimizations very easily
  • Created a rope fence blueprint that makes building a long and winding fence take minutes instead of hours
  • Created and painted landscapes in the realms of 4 square kilometers by myself with no other program involved (aside from textures)
  • Made UI menus through UMG in no time at all
  • Modeled realistic and plentiful fish behavior using GPU particles and Blueprints
  • Everything runs with dynamic shadows, caustics, cloud cover dynamic lighting, dynamic GI (distance field), HDR post processing, beautiful temporal anti-aliasing and motion blur, at 1080p 60 FPS on a graphics card costing ~$200 last year. Same project runs above 100 FPS on a GTX 1060

No, Unreal can’t handle fluid dynamics… yet. No, Unreal doesn’t have its own simulated cloth solution aside from APEX integration. No, dynamic GI is not as nice as I’d like it to be. But all things considered, this is truly one of the greatest, if not the greatest engine you could ever use.

Cryengine is ish compared to UE4. I am and always have been avidly against CE. No good documentation, assets or tutorials to learn their engine. IMO, CE graphics look muddy as hell. What good is “pretty” graphics if you can’t see enemies in your game?

I don’t know how other Engines are handling iteration, but I love how it feels like Epic are putting a lot of time into adding features that mean something at this current point in time, and third party developers make a lot of content for us, also compare our market places (maybe not unity)

i fee like i am reading a post about Android vs. Apple.
How about you use them both and see what one you like the best, then, stick with that. If you guys dont like UE then, so be it … thats your choice
Some people like Unity - if it fits their project, then, it will be better.
Some people like midgets fighting donkeys while having eggs thrown at them … what you like is what you like, no one will “argue” you from that.

Instead of asking these questions, i downloaded Unity and CE and Unreal. Here i am … lots of “woah nice!” in CE … .lots of “who uses this ****!?” in Unity (lol, sorry, i hated it). The scale of use, functionality, assets, etc etc etc … COMMUNITY … has made this my home. It may not be home to someone else, and thats fine. No one can answer your question because YOU need to test and find out for yourself …

thats the honest simple answer. Try CE, it may work out better for your needs.

CE is good for no one except for Crytek or CIG (and given how much of it CIG rewrote… even that is debatable). Yep, I just said that.

/thread

And that’s in-editor performance, too!

I think if people used blueprints for level construction instead of just placing static meshes, they’ll be floored with what the engine can do. Manually installing the individual components of a fence can take hours. With blueprints, you can select one post to another and use look at rotation in the construction script to automatically transform and place different instances of fence meshes at the same time. Within minutes, you can set up a long and winding rope fence with perfection, and through the power of construction scripts, this can all be done in-editor, on-the-fly, yet pre-built so that nothing NEEDS to be generated at runtime in the packaged game. In other words, it’s extremely efficient, makes your life a whole lot easier, and completely customizable to any application you want.

Here are some images of a project I’ve been working on. Fullscreen at 1920x1080, IN EDITOR, on an EVGA FTW edition NVIDIA GTX 960, 68 FPS for the first shot. These screenshots were taken directly from the editor (F9 key) then converted to a .jpg in Photoshop. NO TOUCHUPS were made other than in-engine post processing. When you work in the Unreal Engine editor, this is what you are looking at. When you play your game, this is what it will look like. My graphics card is already more than a year old and on a newer card than mine ran this at 100 FPS when it wasn’t optimized!

How in the hell can you consider landscapes a constraint?! Grass is proceduraly generated on this landscape based off of vertex painting of the grass surface. Each vertex takes information about the surface type, and it blends physical properties as well as visual heightblends for the materials. My character will make a different sound, leave behind a different footprint, and create a different dust effect for each surface type. The second screenshot shows parallax occlusion on the sand, basic normal mapping on the dirt, and a simple texture/foliage for the grass, as well as rocks with world-space blending in the background (Try coding that in HLSL without the material editor’s help by yourself). Also, the landscape removes unused surfaces per component, and with DX-12 you can easily have thousands upon thousands of draw calls per frame. And if you’re not happy with landscape’s astounding resolution, you can use tessellation to make the landscape infinitely detailed and use texture displacement maps to physically bump geometric detail (Tessellation was actually CHEAPER than parallax occlusion mapping in an underwater scene for a client, so yes, not only can you have tessellation in your final deliverable, but it is actually the preferred method!)

People were definitely amazed by CryEngine when it first came out. Nobody ever had water that good, nobody ever had dynamics that good, nobody ever had lighting that good. But UE4 clearly surpassed it on all fronts: it’s visually masterful, easy to program, and intensely optimized. But even when it’s not well optimized (there’s caustics and cloud cover in the material function of the directional light all over the level, but you can’t notice any caustics in the image), it still renders effortlessly and beautifully. Again, UE4’s faults are in the lack of dynamic fluid simulations (you can import fluid simulations… but nothing else), built-in cloth simulations (if you don’t have Maya or 3DS Max, good luck getting cloth on characters), volumetric rendering (coming soon, but it’s still expensive overall), and dynamic GI for dynamic objects (only LPVs work with dynamic objects/skeletal meshes, but static objects look fantastic with distance fields). As long as you do not rely on those kinds of things, then you’re gold with UE4.


1983695b972518f98069b4c20016ae123f88fd86.jpeg

1 - Yes, they have. Before UE 4.13, if you wanted deeper details on landscape, you needed to use parallax occlusion mapping which upped your shader complexity like crazy and wasted resources. Now that DX-12 has been more thoroughly implemented, you can make your landscape work much better with LODs and cull it for significantly less cost, and after UE 4.13 you can tessellate your landscape and only the lowest LOD will feature the triangle explosion. You can displace detail with real geometry for less than the cost of parallax occlusion and save as much as 10 FPS using the new technique while benefiting from all of tessellation’s features: proper occlusion, proper lighting, proper shadows. You can also apply deformed vertices to the landscape’s physical heightfield for collision.

2 - Landscape deformation would impede on the purpose of a height-field. With heightfields, we have a very cheap method for dynamic GI and a fully accurate model for use with the distance field features. If you want to model something other than what is possible on a height field you will need to build your own meshes on top of it, but you will also lose some features: unseen parts won’t cull, tessellation must be applied to the whole object, and while you can use vertex blending on static meshes, you can’t change the surface’s physical properties with it.

3 - There really isn’t a huge demand for Super Mario Galaxy-esque or No Man’s Sky spherical type of world building. The unusual surface is much more complicated, especially from an artist’s standpoint, and much more difficult to render from an engineer’s. Few people really care to make games like this, and few seriously wish to play them. If you want to make an environment, landscape is for all intents and purposes the best tool to do it. If someone wants to make spherical worlds, that’s cool, and people will comment that it’s cool. Super Mario Galaxy did an amazing job, and that was cool. But it’s highly unorthodox and largely impractical a feature for a massive mainstream game engine to tackle. That’s like saying UE4 is a terrible engine because it doesn’t support Rift’s megatextures or Portal’s gravity gun. No, lacking those things doesn’t make it a terrible engine. If you want to build those things, you can with the tools available. You just have to adjust your scope and tackle it in a different way. Instead of massive gigantic spherical planets, try smaller SMG-sized planets and use static meshes with face extrusions for that.

Yes, VR is exploding now, and tools need to be made in the engine in order to support development for it, and that takes time. I just got back from a meetup of UE4 developers in my area, and there are guys making procedurally generated games in VR right now, VR tools for the Marketplace, and a VR ad concept for Coca Cola. And VR was added in like a few months ago. Yes, landscape was also featured in UDK 5 years ago when I first started learning it with many of the same features it has today, but now the engine has been built to the point where we can fully take advantage of it and do things that we could never do before, like tessellation. It’s hard to tell in the shot below, but the entire scene is being lit by underwater caustics, and the light from the caustics not only bends around the tessellated landscape surface, but also casts a shadow and occludes correctly. This would’ve been impossible to do before UE 4.13 as tessellation would be applied to the whole landscape and sink the performance like a dead weight. Now, you can do it on a GTX 960 in 80 FPS. That’s what’s improved with landscape in the most recent update. And that’s only just the landscape. We also got sequencer in June.

301fc9e57661086ba937518f567c36dc73d4ea87.jpeg

3 - Spherical worlds are also very case by case issue where you probably couldn’t come up with a one solution fits all approach. Like the approach for Astroneer (a UE4 game in dev that’s Minecraft + No Mans Sky) wouldn’t work for Star Citizen or Super Mario Galaxy.

Not every engine feature has to be a “one solution fits all approach”, as every project being done in the engine is different and has different needs. Just do what Epic’s doing right now in 4.14 already with the origin rebasing feature for multiplayer - make it an option in the project settings menu. There are very little reasons not to offer more options for the people who would need them, and sometimes you underestimate how useful particular features are until they’re in the hands of the developers that can use them. It’s like the forward rendering engine Epic’s putting into the UE4. It’s a very specific feature that only a handful of projects, usually VR focused, will need, but by putting it in as an option instead of a requirement it doesn’t actively detract from the experience of the rest of us.

I’m not sure what build you’re using, but I’m having drastically different results on my GTX 780. These are the performance results on a brand new 4.14 build I just compiled tonight for this, and the 4.13 results are no different. This is on a blank template map with nothing added or changed except for adding the landscape. And, this is after I increased the landscape LOD distance factor to try and reduce complexity.

landscapetess.png

A lot of people have been asking for a forward rendering option since day 1, particularly for transparency and antialiasing, and sometimes for performance reasons (and now VR). Epic does prioritize features it needs for internal projects, which is why Epic is finally making a forward render option that people have been begging for.

I do agree that Epic should work on adding features that make developing a massive world or space game easier, since that is a really common request. But specifically making procedural, dynamic, spherical, voxel based terrain tool sounds a bit too specific and a demanding request.

My only problem with the UE4’s large world tools are that they’re incomplete. We have origin rebasing, now after a year and a half of waiting it’s in multiplayer for 4.14, but that does nothing to solve server precision issues.

We have massive terrain capability, but having multiple loaded at once is an insane strain on the system and takes up very large amounts of disk space because of the non-procedural nature of the tools. For example, SWG in 2003 had a procedural system that was artist driven and that turned out the same result every single time. As a result, they got massive worlds while only taking up a few megabytes of disk space, a tiny fraction of what a similar terrain in the UE4 would consume, with comparable complexity.

We have great, easy to use netcode that works great at almost anything you throw at it, right up until you have your game thread cap out the CPU due to AI, too many players, or too many things running, since it’s single threaded and there’s no option to modify that. I’ve even found presentations from 2014 saying Epic wanted to make UObjects thread safe, but two years later it’s still something that hasn’t been worked on (if Discord is to be believed).

There are so many things in the engine right now in regards to larger singleplayer games, but Epic dropped the subject for the most part once the Kite demo released instead of seeing it through to the end to refocus on smaller games and VR. And for those projects, that’s great to have that kind of support, but if Epic’s going to take the approach of being a generalist engine they should make sure that these sort of features get the polish they need before moving on to a new emerging trend like VR that might not even go anywhere in a year; when we know that people will still want to build ambitious games regardless of it’s VR or not later on down the line.