Subject: General Tech | September 1, 2015 - 04:24 PM | Scott Michaud
Tagged: unreal engine 4, unreal engine, ue4.9, ue4, epic games, dx12
For an engine that was released in late-March, 2014, Epic has been updating it frequently. Unreal Engine 4.9 is, as the number suggests, the tenth release (including 4.0) in just 17 months, which is less than two months per release on average. Each release is fairly sizable, too. This one has about 232 pages of release notes, plus a page and a half of credits, and includes changes for basically every system that I can think of.
The two most interesting features, for me, are Area Shadows and Full Scene Particle Collision.
Area Shadows simulates lights that are physically big and relatively close. At the edges of a shadow, the object that casts the shadow are blocking part of the light. Wherever that shadow falls will be partially lit by the fraction of the light that can see it. As that shadow position gets further back from the shadow caster, it gets larger.
On paper, you can calculate this by drawing rays from either edge of each shadow-casting light to either edge of each shadow-casting object, continued to the objects that receive the shadows. If both sides of the light can see the receiver? No shadows. If both sides of the light cannot see the receiver? That light is blocked, which is a shadow. If some percent of a uniform light can see the receiver, then it will be shadowed by 100% minus that percentage. This is costly to do, unless neither the light nor any of the affected objects move. In that case, you can just store the result, which is how “static lighting” works.
Another interesting feature is Full Scene Particle Collision with Distance Fields. While GPU-computed particles, which is required for extremely high particle counts, collide already, distance fields allow them to collide with objects off screen. Since the user will likely be able to move the camera, this will allow for longer simulations as the user cannot cause it to glitch out by, well, playing the game. It requires SM 5.0 though, which limits it to higher end GPUs.
This is also the first release to support DirectX 12. That said, when I used a preview build, I noticed a net-negative performance with my 9000 draw call (which is a lot) map on my GeForce GTX 670. Epic calls it “experimental” for a reason, and I expect that a lot of work must be done to deliver tasks from an existing engine to the new, queue-based system. I will try it again just in case something changed from the preview builds. I mean, I know something did -- it had a different command line parameter before.
UPDATE (Sept 1st, 10pm ET): An interesting question was raised in the comments that we feel could be a good aside for the news post.
Anonymous asked: I don't have any experience with game engines. I am curious as to how much of a change there is for the game developer with the switch from DX11 to DX12. It seems like the engine would hide the underlying graphics APIs. If you are using one of these engines, do you actually have to work directly with DX, OpenGL, or whatever the game engine is based on? With moving to DX12 or Vulcan, how much is this going to change the actual game engine API?
Modern, cross-platform game engines are basically an API and a set of tools atop it.
For instance, I could want the current time in seconds to a very high precision. As an engine developer, I would make a function -- let's call it "GetTimeSeconds()". If the engine is running on Windows, this would likely be ((PerformanceCounter - Initial) / PerformanceFrequency) where PerformanceCounter is grabbed from QueryPerformanceCounter() and PerformanceFrequency is grabbed from QueryPerformanceFrequency(). If the engine is running on Web standards, this would be window.performance.now() * 1000, because it is provided in milliseconds.
Regardless of where GetTimeSeconds() pulls its data from, the engine's tools and the rest of its API would use GetTimeSeconds() -- unless the developer is low on performance or development time and made a block of platform-dependent junk in the middle of everything else.
The same is true for rendering. The engines should abstract all the graphics API stuff unless you need to do something specific. There is usually even a translation for the shader code, be it an intermediate language (or visual/flowchart representation) that's transpiled into HLSL and GLSL, or written in HLSL and transpiled into GLSL (eventually SPIR-V?).
One issue is that DX12 and Vulkan are very different from DX11 and OpenGL. Fundamentally. The latter says "here's the GPU, bind all the attributes you need and call draw" while the former says "make little command messages and put it in the appropriate pipe".
Now, for people who license an engine like Unity and Unreal, they probably won't need to touch that stuff. They'll just make objects and place them in the level using the engine developer's tools, and occasionally call various parts of the engine API that they need.
Devs with a larger budget might want to dive in and tweak stuff themselves, though.
Unreal Engine 4.9 is now available. It is free to use until your revenue falls under royalty clauses.
Subject: General Tech | February 21, 2015 - 07:00 AM | Scott Michaud
Tagged: unreal engine 4, unreal engine, epic games
On Thursday, Tim Sweeney joined the Unreal Engine 4 Twitch Broadcast to announce “Unreal Dev Grants”. In short, Epic Games have set aside 5 million dollars to pass out in increments of five thousand ($5000 USD) to fifty thousand dollars ($50,000 USD), with no strings attached. If you are doing something cool in, with, or involving Unreal Engine 4, you are eligible and can use the money in any way. You keep all your “intellectual property” and equity, and you do not even have any accountability requirements.
It's free money that you can apply for, or they will even approach you with if they see you doing something awesome (you can even nominate other people's projects). The only “catch” is that your work needs to be relevant to Unreal Engine. From there, it could be anything from congratulating an awesome pull request for the engine on GitHub, to giving an indie (or even AAA) game a little bit of a financial boost. Tim Sweeney was telling stories about mowing lawns for the $3000 it took for him to launch ZZT. He mowed lawns so you don't have to.
For more information, or to nominate yourself or someone else, check out their website.
Subject: Editorial, General Tech, Graphics Cards, Systems | May 23, 2013 - 06:40 PM | Scott Michaud
Tagged: xbox one, xbox, unreal engine, ps4, playstation 4, epic games
Unreal Engine 4 was presented at the PlayStation 4 announcement conference through a new Elemental Demo. We noted how the quality seemed to have dropped in the eight months following E3 while the demo was being ported to the console hardware. The most noticeable differences were in the severely reduced particle counts and the non-existent fine lighting details; of course, Epic pumped the contrast in the PS4 version which masked the lack of complexity as if it were a stylistic choice.
Still, the demo was clearly weakened. The immediate reaction was to assume that Epic Games simply did not have enough time to optimize the demo for the hardware. That is true to some extent, but there are theoretical limits on how much performance you can push out of hardware at 100% perfect utilization.
Now that we know both the PS4 and, recently, the Xbox One: it is time to dissect more carefully.
A recent LinkedIn post from EA Executive VP and CTO, Rajat Taneja, claims that the Xbox One and PS4 are a generation ahead of highest-end PC on the market. While there are many ways to interpret that statement, in terms of raw performance that statement is not valid.
As of our current knowledge, the PlayStation 4 contains an eight core AMD "Jaguar" CPU with an AMD GPU containing 18 GCN compute units, consisting of a total of 1152 shader units. Without knowing driving frequencies, this chip should be slightly faster than the Xbox One's 768 shader units within 12 GCN compute units. The PS4 claims their system has a total theoretical 2 teraFLOPs of performance and the Xbox One would almost definitely be slightly behind that.
Back in 2011, the Samaritan Demo was created by Epic Games to persuade console manufacturers. This demo was how Epic considered the next generation of consoles to perform. They said, back in 2011, that this demo would theoretically require 2.5 teraFLOPs of performance for 30FPS at true 1080p; ultimately their demo ran on the PC with a single GTX 680, approximately 3.09 teraFLOPs.
This required performance, (again) approximately 2.5 teraFLOPs, is higher than what is theoretically possible for the consoles, which is less than 2 teraFLOPs. The PC may have more overhead than consoles, but the PS4 and Xbox One would be too slow even with zero overhead.
Now, of course, this does not account for reducing quality where it will be the least noticeable and other cheats. Developers are able to reduce particle counts and texture resolutions in barely-noticeable places; they are also able to render below 1080p or even below 720p, as was the norm for our current console generation, to save performance for more important things. Perhaps developers might even use different algorithms which achieve the same, or better, quality for less computation at the expense of more sensitivity to RAM, bandwidth, or what-have-you.
But, in the end, Epic Games did not get the ~2.5 teraFLOPs they originally hoped for when they created the Samaritan Demo. This likely explains, at least in part, why the Elemental Demo looked a little sad at Sony's press conference: it was a little FLOP.
Update, 5/24/2013: Mark Rein of Epic Games responds to the statement made by Rajat Taneja of EA. While we do not know his opinion on consoles... we know his opinion on EA's opinion:
— Mark Rein (@MarkRein) May 23, 2013
Subject: Editorial, Mobile | May 7, 2013 - 12:07 AM | Scott Michaud
Tagged: unreal engine, firefox, asm.js
If, on the other hand, you wish to see an example of a large application compiled for the browser: would Unreal Engine 3 suffice?
Clearly a computer hardware website would take the effort required to run a few benchmarks, and we do not disappoint. Epic Citadel was run in its benchmark mode in Firefox 20.0.1, Firefox 22.0a2, and Google Chrome; true, it was not run for long on Chrome before the tab crashed, but you cannot blame me for trying.
Each benchmark was run at full-screen 1080p "High Performance" settings on a PC with a Core i7 3770, a GeForce GTX 670, and more available RAM than the browser could possibly even allocate. The usual Firefox framerate limit was removed; they were the only tab open on the same fresh profile; the setting layout.frame_rate.precise was tested in both positions because I cannot keep up what the state of requestAnimationFrame callback delay is; and each scenario was performed twice and averaged.
- layout.frame_rate.precise true: 54.7 FPS
- layout.frame_rate.precise false: 53.2 FPS
Firefox 22.0a2 (asm.js)
- layout.frame_rate.precise true: 147.05 FPS
- layout.frame_rate.precise false: 144.8 FPS
Google Chrome 26.0.1410.64
It is also very enticing for Epic as well. A little over a month ago, Mark Rein and Tim Sweeney of Epic were interviewed by Gamasutra about HTML5 support for Unreal Engine. Due in part to the removal of UnrealScript in favor of game code being scripted in C++, Unreal Engine 4 will support HTML5. They are working with Mozilla to make the browser a reasonable competitor to consoles; write once, run on Mac, Windows, Linux, or anywhere compatible browsers can be found. Those familiar with my past editorials know this excites me greatly.
So what do our readers think? Comment away!
Subject: Mobile | August 29, 2012 - 03:45 PM | Matt Smith
Tagged: unreal engine, tegra 3, tablet, nvidia, gaming
One of the reasons why I have hope for Windows RT is its gaming potential. Microsoft has been hit-or-miss with its gaming projects, but when it succeeds, it really knocks it out of the park – see DirectX, the Xbox 360 and Microsoft’s digital distribution via its console. Bringing Windows to tablets could make life easier for game developers in that space and offer a wider selection of mature titles rather than mobile-focused games, which often (in my opinion) feel watered down and look underwhelming.
NVIDIA showcased this potential at IFA 2012 by demonstrating a Windows RT tablet (with Tegra 3 hardware, of course) running Unreal Engine 3. The tablet is shown playing the NVIDIA “Epic Citiadel” demo which we saw at the editor’s day conference used to debut the GTX 680 earlier this year. Quality details are probably reduced compared to the version that ran on the GTX 680 (it’s hard to tell in the video) but it still looks excellent and runs smoothly.
The demonstration highlighted the fact this isn’t some one-off or stripped-down version of the engine designed only for mobile devices. It’s a port of the existing Unreal Engine 3 engine used to make Windows PC games, which means developers shipping games that use UE3 should have minimal trouble porting their game to a Windows 8 RT tablet. Mark Rein, president of Epic Games, stated that Windows 8 RT code is now available to UE3 licenesees. It’ll be interesting to see which game developer is first to jump on board.
The tablet in the video is an ASUS Vivo Tab RT, an upcoming Windows 8 RT tablet with an 11.6” IPS display with 1366x768 resolution and a Tegra 3 SoC. A tablet like this could be a compelling mobile gaming device if the games become available. I’ve got my fingers crossed.