Subject: General Tech | November 15, 2016 - 06:04 PM | Scott Michaud
Tagged: vulkan, ue4, pc gaming, epic games
Every couple of months, Epic Games drops a new version of Unreal Engine 4 with improvements all over. As such, you should check the full release notes to see all of the changes, including the fifty-one that Epic thinks are worth highlighting. Here are some that I think our readers would enjoy, though.
First, Vulkan support for mobile devices has apparently moved out of experimental. While this will not be enabled for desktop applications, it's interesting to note that DirectX 12 is still in experimental. Basically, if you squint and put blinders on, you could sort-of see some element of Vulkan beating DirectX 12 to market.
Second, Unreal Engine 4 has significantly upgraded their forward renderer. In a lot of cases, a deferred renderer is preferable because it's fast and consistent; the post-process shader only run once per output pixel, ignoring lighting triangles that are covered by other triangles. The way this is structured, though, makes multisample anti-aliasing impossible, which is slightly annoying on desktop but brutal in VR. As an added benefit, they're also using forward shading to help the deferred renderer with translucent materials.
Unreal Engine typically uses a lot of NVIDIA SDKs. This version updates PhysX up to 3.4, which allows “continuous collision detection” on rigid bodies. This means that fast moving object shouldn't pass through objects without colliding, because the collision occurred between two checks and was missed, if this feature is enabled. They are also adding the Ansel SDK, which allows players to take high-detail screenshots, as a plug-in.
Skipping down the release notes a bunch, Unreal Engine 4.14 also adds support for Visual Studio 15, which is the version after Visual Studio 2015 (Visual Studio 14.0). Both IDEs are, in fact, supported. It's up to the developer to choose which one to use, although Visual Studio 15 makes a lot of improvements regarding install and uninstall.
Finally, at least for my brief overview, Unreal Engine 4.14 begun to refactor their networking system. It sounds like the current optimizations are CPU-focused, but allowing more network-capable objects is always a plus. Epic Games claims they are benchmarking about 40% higher performance in this area.
Subject: General Tech | November 9, 2016 - 06:25 PM | Scott Michaud
Tagged: pc gaming, VR, ue4, red alert, command and conquer
Command and Conquer: Red Alert 2 was a 2D real-time strategy game about a science-fiction alternate universe version of Cold War Allies vs Soviets. The base-building mechanic involved collecting funds from captured neutral structures and harvesting resources throughout the map. Ádám Horváth, a fan of the series, with 3D assets created by an artist who goes by the name Slye_Fox, created a VR implementation in Unreal Engine 4.
The interface implementation is quite interesting in particular. It looks almost like someone hovering over a board game, interfacing with the build menu via a virtual hand-held tablet. The game mechanics look quite complete, with even things like enemy AI and supply crates (although think the camera didn't catch when it was actually picked up) implemented. It definitely looks good, and looks like it could form the basis for a full real-time strategy interface for VR.
Subject: General Tech | July 27, 2016 - 08:47 PM | Scott Michaud
Tagged: microsoft, epic games, unreal engine, unreal engine 4, ue4, uwp
The head of Epic Games, Tim Sweeney, doesn't like UWP too much, at least as it exists today (and for noble reasons). He will not support the new software (app) platform unless Microsoft makes some clear changes that guarantee perpetual openness. There really isn't anything, technically or legally, to prevent Microsoft (or an entity with authority over Microsoft, like governments, activists groups who petition government, and so forth) from undoing their changes going forward. If Microsoft drops support for Win32, apart from applications that are converted using Project Centennial or something, their catalog would be tiny.
SteamOS would kick its butt levels of tiny, let alone OSX, Android, and countless others.
As a result, Microsoft keeps it around, despite its unruliness. Functionality that is required by legitimate software make it difficult to prevent malware, and, even without an infection, it can make the system just get junked up over time.
UWP, on the other hand, is slimmer, contained, and authenticated with keys. This is theoretically easier to maintain, but at the expense of user control and freedom; freedom to develop and install software anonymously and without oversight. The first iteration was with Windows RT, which was basically iOS, right down to the “you cannot ship a web browser unless it is a reskin of Internet Explorer ((replace that for Safari in iOS' case))” and “content above ESRB M and PEGI 16 are banned from the OS” levels of control.
Since then, content guidelines have increased, sideloading has been added, and so forth. That said, unlike the technical hurdles of Win32, there's nothing to prevent Microsoft from, in the future, saying “Okay, we have enough software for lock in. Sideloading is being removed in Windows 10 version 2810” or something. I doubt that the current administration wants to do this, especially executives like Phil Spencer, but their unwillingness to make it impossible to be done in the future is frustrating. This could be a few clauses in the EULA that make it easy for users to sue Microsoft if a feature is changed, and/or some chunks of code that breaks compatibility if certain openness features are removed.
Some people complain that he wasn't this concerned about iOS, but he already said that it was a bad decision in hindsight. Apple waved a shiny device around, and it took a few years for developers to think “Wait a minute, what did I just sign away?” iOS is, indeed, just as bad as UWP could turn into, if not worse.
Remember folks, once you build a tool for censorship, they will come. They may also have very different beliefs about what should be allowed or disallowed than you do. This is scary stuff, albeit based on good intentions.
That rant aside, Microsoft's Advanced Technology Group (ATG) has produced a fork of Unreal Engine 4, which builds UWP content. It is based upon Unreal Engine 4.12, and they have apparently merged changes up to version 4.12.5. This makes sense, of course, because that version is required to use Visual Studio 2015 Update 3.
If you want to make a game in Unreal Engine 4 for the UWP platform, then you might be able to use Microsoft's version. That said, it is provided without warranty, and there might be some bugs that cropped up, which Epic Games will probably not help with. I somehow doubt that Microsoft will have a dedicated team that merges all fixes going forward, and I don't think this will change Tim's mind (although concrete limitations that guarantee openness might...). Use at your own risk, I guess, especially if you don't care about potentially missing out on whatever is added for 4.13 and on (unless you add it yourself).
The fork is available on Microsoft's ATG GitHub, with lots of uppercase typing.
Subject: General Tech | June 1, 2016 - 06:26 PM | Scott Michaud
Tagged: unreal engine, ue4, unreal engine 4, epic, epic games
Epic Games has released Unreal Engine 4.12, which adds quite a bit, especially cinematic tools. Those who created games or mods in Unreal Engine 3 or 4 will know about Matinee, the interface to animate objects in a scene. It has finally been replaced with Sequencer, which is designed to feel more like Adobe After Effects or Adobe Premiere. They also add a bunch of features to DirectX 12 and Vulkan, but both are still in experimental preview. Vulkan, for instance, only implements rendering features for mobile, not desktop.
Beyond Sequencer, mentioned above, Epic has also added a bunch of new rendering technologies for high-end graphics. This includes High Quality Reflections, Planar Reflections, Grass and Foliage Scalability, and Twist Corrective Animation Node. These are quite interesting for someone like me, who has been getting back into pre-rendered animation recently, but finds that typical, production renderers (such as Cycles) are quite heavy, slowing me down. Epic was interested in bringing Unreal Engine into a video production workflow, even back in Unreal Engine 3, and it's good to see a lot of attention in this area. It might be enough to move me over at some point, especially for animations that don't have a hyper-realistic style. Even better -- this level of visual quality should land in some games, too.
Unreal Engine 4.12 is now available on Epic's Launcher.
Subject: General Tech | February 11, 2016 - 12:27 PM | Ken Addison
Tagged: vr edition, video, UMC, ue4, podcast, phanteks, nvidia, logitech, GTX 980 Ti, g810, evga, enthoo evolv itx, asrtock, arm, amd, 28HPCU
PC Perspective Podcast #386 - 02/10/2016
Join us this week as we discuss the Logitech G810, Phanteks Enthoo EVOLV ITX, GTX 980 Ti VR Edition and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the Store (audio only)
- RSS - Subscribe through your regular RSS reader (audio only)
- MP3 - Direct download link to the MP3 file
Hosts: Ryan Shrout, Jeremy Hellstrom, Josh Walrath, and Allyn Malventano
Program length: 1:30:34
Week in Review:
0:26:20 EVGA 750W GQ Power Supply Review
0:36:45 This week’s podcast is brought to you by Casper. Use code PCPER at checkout for $50 towards your order!
News items of interest:
Hardware/Software Picks of the Week
Subject: General Tech, Shows and Expos | February 4, 2016 - 07:47 PM | Scott Michaud
Tagged: GDC, gdc 2016, epic games, ue4, VR, vive vr
Epic Games released Unreal Engine 4 at GDC two years ago, and removed its subscription fee at the next year's show. This year, one of the things that they will show is Unreal Editor in VR with the HTC Vive. Using the system's motion controllers, you will be able to move objects and access UI panels in the virtual environment. They open the video declaring that this is not an experimental project.
Without using this technology, it's hard to comment on its usability. It definitely looks interesting, and might be useful for VR experiences. You can see what your experience will look like as you create it, and you probably even save a bit of time in rapid iteration by not continuously wearing and removing the equipment. I wonder how precise it will be though, since the laser pointers and objects seemed to snap and jitter a bit. That said, it might be just as precise and, even still, it only really matters how it looks and behaves, and it shouldn't even prevent minor tweaks after the fact anyway.
Epic Games expects to discuss the release plans at the show.
Subject: General Tech | January 20, 2016 - 07:06 PM | Scott Michaud
Tagged: vulkan, ue4, nvidia, Intel, gdc 2016, GDC, epic games, DirectX 12, Codemasters, arm, amd
The 30th Game Developers Conference (GDC) will take place on March 14th through March 18th, with the expo itself starting on March 16th. The sessions have been published at some point, with DX12 and Vulkan prominently featured. While the technologies have not been adopted as quickly as advertised, the direction is definitely forward. In fact, NVIDIA, Khronos Group, and Valve have just finished hosting a developer day for Vulkan. It is coming.
One interesting session will be hosted by Codemasters and Intel, which discusses bringing the F1 2015 engine to DirectX 12. It will highlight a few features they implemented, such as voxel based raytracing using conservative rasterization, which overestimates the size of individual triangles so you don't get edge effects on pixels that are partially influenced by an edge that cuts through a tiny, but not negligible, portion of them. Sites like Game Debate (Update: Whoops, forgot the link) wonder if these features will be patched in to older titles, like F1 2015, or if they're just R&D for future games.
Another keynote will discuss bringing Vulkan to mobile through Unreal Engine 4. This one will be hosted by ARM and Epic Games. Mobile processors have quite a few cores, albeit ones that are slower at single-threaded tasks, and decent GPUs. Being able to keep them loaded will bring their gaming potential up closer to the GPU's theoretical performance, which has surpassed both the Xbox 360 and PlayStation 3, sometimes by a factor of 2 or more.
Many (most?) slide decks and video recordings are available for free after the fact, but we can't really know which ones ahead of time. It should be an interesting year, though.
Subject: General Tech | November 17, 2015 - 06:40 PM | Scott Michaud
Tagged: ue4, Nintendo, maker, hobbyist
Okay this is just cool (albeit a little old news).
YouTube user CryZENx made a few tech demos that star classic video game characters, with modern, Unreal Engine 4-powered graphics. Samus has a glossy, metallic suit of armor. Goku launches bright Kamehameha blasts, as well as punches, kicks, and spins with his power pole, all while his tail wags and whips around behind him.
It is also one of the first demos that I've seen use NVIDIA FleX. One level has two spout of clear blue water. One flows over a pile of rigid bodies and splits in the corner of the world, and the other flows through two water wheels, which shape the spout before it blobs on the ground.
As always, be careful running what you download from the internet. That said, it doesn't trigger a permission escalation (UAC) or anything, so chances are that it is just a typical project cooked through Unreal Engine 4. Nintendo and others might be a bit upset at their trademarks being used, but it's a non-commercial tech demo for a hobbyist game developer.
They would be better off hiring them.
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, Graphics Cards, Shows and Expos | March 4, 2015 - 05:52 PM | Scott Michaud
Tagged: GDC, gdc 15, nvidia, epic games, ue4, unreal engine 4, PhysX, apex
NVIDIA and Epic Games have just announced that Unreal Engine 4 developers can view and modify the source of PhysX. This also includes the source for APEX, which is NVIDIA's cloth and destruction library. It does not include any of the other libraries that are under the GameWorks banner, but Unreal Engine 4 does not use them anyway.
This might even mean that good developers can write their own support for third-party platforms, like OpenCL. That would probably be a painful process, but it should be possible now. Of course, that support would only extend to their personal title, and anyone who they share their branch with.
If you are having trouble finding it, you will need to switch to a branch that has been updated to PhysX 3.3.3 with source, which is currently just “Master”. “Promoted” and earlier seem to be back at PhysX 3.3.2, which is still binary-only. It will probably take a few months to trickle down to an official release. If you are still unable to find it, even though you are on the “Master” branch, the path to NVIDIA's source code is: “Unreal Engine/Engine/Source/ThirdParty/PhysX/”. From there you can check out the various subdirectories for PhysX and APEX.
NVIDIA will be monitoring pull requests sent to that area of Unreal Engine. Enhancements might make it back upstream to PhysX proper, which would then be included in future versions of Unreal Engine and anywhere else that PhysX is used.
In other news, Unreal Engine 4 is now free of its subscription. The only time Epic will ask for money is when you ship a game and royalties are due. This is currently 5% of gross revenue, with the first $3000 (per product, per calendar quarter) exempt. This means that you can make legitimately free (no price, no ads, no subscription, no microtransactions, no Skylander figurines, etc.) game in UE4 for free now!