[HN Gopher] Unreal Engine 5 Early Access Release Notes
___________________________________________________________________
Unreal Engine 5 Early Access Release Notes
Author : ksec
Score : 102 points
Date : 2021-05-31 16:37 UTC (6 hours ago)
(HTM) web link (docs.unrealengine.com)
(TXT) w3m dump (docs.unrealengine.com)
| jayd16 wrote:
| Any word on build/import times? Nanite looks great but I wonder
| how it'll feel working with these large assets at scale.
| Although, could be cheaper overall than importing all the LODs
| and imposters you would normally make.
| alkonaut wrote:
| Does anyone know what (UI) tech is used for the editor?
| Jyaif wrote:
| The introduction of Chaos Vehicles and specifically the
| "predictable physics simulation that can be replicated over a
| network" sounds like something they made for Rocket League.
| mhh__ wrote:
| If they have proper physics I'll have to have a look at that, I
| wanted to try and make my own simracing game in Unreal Engine
| previously (i.e. use the engine for graphics and inputs etc.),
| but the built-in vehicles were a step in the right direction
| but ultimately very hard to try to use realistic physics with.
| spywaregorilla wrote:
| Does predictable physics mean it can be replicated over a
| networked game easily?
| ajdoingnothing wrote:
| Yes - but I wouldn't put too much emphasis on the "easily"
| part. I think that the physics are now pretty deterministic
| if you run a simulation using the exact same input (on
| different clients). However, in reality you'd still have to
| synchronize the state of the objects every now and then
| (e.g., if a client didn't receive certain inputs on time).
| falcor84 wrote:
| > "Full Body IK (FBIK)"
|
| I have a sense that this acronym could have been clarified a bit
| further. After going to the second page of Google results, I now
| think it's probably "Inverse Kinematics", but it shouldn't have
| been so hard.
| alkonaut wrote:
| It's like spelling out JPEG in the release notes for Photoshop.
| You could do it for good form, but it's mostly a waste of
| characters.
| RobotCaleb wrote:
| I don't disagree, but the target audience knows exactly what IK
| means
| daenz wrote:
| UE5 is a game changer in a lot of ways, but I personally would
| not begin to migrate any projects over to it yet. They are
| looking for people to hammer out the bugs with the early access
| (which is exactly what they should be doing), so you should know
| what you're getting into if you're going to convert your large
| project over. You could be in for a lot of pain. I have seen a
| few reports on /r/unrealengine of projects with custom C++
| modules having very little support (docs or otherwise) post-
| migration.
|
| That said, big features with UE5. Lumen is the biggest imo
| (bigger than Nanite) because it (in theory) achieves a holy grail
| of automatic dynamic global illumination, without a super
| expensive RTX-like raytracing card. The number of lighting
| problems and lighting-related workflows it will obsolete cannot
| be overstated.
|
| Nanite is cool, but from my super high-level understanding of the
| tech, it is only going to work on static meshes where the engine
| can build the fancy indexes it needs to render dynamic LODs. My
| understanding is that it won't work on any mesh that needs
| deformation of any kind (someone correct me if I'm wrong here
| please).
| gentleman11 wrote:
| The best part of unreal compared to unity is the stability. You
| lose that with experimental and early access modules or
| versions
| teamonkey wrote:
| > without a super expensive RTX-like raytracing card.
|
| Without a card that supports hardware raytracing, Lumen falls
| back to a software raytracing mode that carries some
| limitations[1]
|
| The min-rec non-RTX GPU is a GTX 1070, so there's (roughly)
| only one generation of supported GPUs that are supported but
| don't support hardware raytracing. My prediction is that the
| software fallback will eventually lose support and become
| deprecated as raytracing cards become more common.
|
| [1] https://docs.unrealengine.com/5.0/en-
| US/RenderingFeatures/Lu...
| vosper wrote:
| > The min-rec non-RTX GPU is a GTX 1070, so there's (roughly)
| only one generation of supported GPUs that are supported but
| don't support hardware raytracing.
|
| What about all of the AMD cards? There's the 5x00 and 6x00
| series, peers of GTX 20x0 and 30x0 respectively. None of
| those AMD cards have raytracing, right?
| teamonkey wrote:
| For Lumen's hardware raytracing:
|
| > Video cards must be NVIDIA RTX-2000 series and higher, or
| AMD RX 6000 series and higher.
| proxysna wrote:
| Well it is an early access after all. Curiosity aside, why
| would anyone want to migrate?
| mikepurvis wrote:
| Because your particular project might really benefit from one
| or more of the new features?
| [deleted]
| SeanBoocock wrote:
| One reason would be that you have a future (years) ship date
| and aren't yet in full production (but close). The sooner you
| adopt the new environment art and lighting workflows, the
| less sunk cost you'll have in assets/workflows that are now
| irrelevant.
|
| There are also staffing implications. If you no longer have
| to create LODs for your environment art, do you reprioritize
| your environment art outsource budget? Likewise lighting, if
| we can hit higher quality with 1/3 of the personnel, where
| does the budget then go to? The earlier you can get a handle
| on the implications of these new workflows, the better you'll
| be able to answer those questions.
| 127 wrote:
| It's really amazing not having to worry about light maps at
| all. Also the integration of Quixel Bridge and all the free
| high quality assets should be mentioned. It's really quick to
| build something that sounds and looks impressive.
| 411111111111111 wrote:
| And nonetheless there are hilariously bad scam games on
| Kickstarter like Dreamworld (which got it's first "funding"
| through ycombinator)
| astlouis44 wrote:
| Agreed, see this thread here on HN that was posted recently
| about how much of a scam it is...YC backed it too, which is
| embarrassing to say the least!
|
| https://news.ycombinator.com/item?id=27319457
| ehnto wrote:
| Lighting is easily the biggest hurdle I encountered trying to
| build games as a solo dev. It's not particularly hard to
| understand the concepts, but it's quite unintuitive and labour
| intensive to get good looking lighting. It was also very prone
| to engine-specific bugs or tweaks in obscure settings, very
| frustrating.
|
| I guess like many industries as these new technologies come in
| there will be old-hands who lament how easy it is for
| newcommers, but if I could do away with the whole lot and just
| look at lighting as if I were dressing a movie set, and
| materials acted exactly as you'd expect, it would be so
| enabling.
| ganonm wrote:
| You should look at Unity's high definition render pipeline.
| It uses physically based lighting so you can just e.g. look
| up the brightness of a particular light, enter it in, then it
| will render as you would expect.
|
| And yes, you're right about it being enabling. Anecdotally,
| I've heard that people coming from e.g. photography
| background find HDRP insanely easy to get good results and
| pick up quickly.
| jayd16 wrote:
| Lighting a movie set isn't trivial either but it would be
| nice not to deal with implementation specific settings.
| dagmx wrote:
| I don't think any old hands will lament how easy things
| become to get quicker feedback.
|
| It benefits them as well. These aren't substitutes for
| lighting knowledge and skills. Just more good tools in a
| toolbox.
| spywaregorilla wrote:
| Lumen is very cool tech, but it has its imperfections. Namely,
| fast transitions between lighting will have weird, unrealistic
| fades. But honestly, who cares, it's very cool.
| skohan wrote:
| It's not unique to Lumen either, a lot of RT implementations
| use multi-frame accumulation to achieve good results, we're
| just not quite there in terms of raw power to do bounce
| lighting without it.
|
| This is probably one of those things which will separate
| next-gen lighting from current gen when we have truly instant
| bounce lighting fill after a geometry change or light
| position change.
| shahar2k wrote:
| unfortunately with so many temporal optimizations even anti
| aliasing is no longer "instant" I think that specifically
| things like large bounce light changes will have to have
| some sort of hacky "pre-accumulation" step that is done
| case by case at least for the forseeable future... ray
| tracing tech is still gorgeous stuff but again there are
| trailing edges on so many moving objects because
| information has to be collected over multiple frames.
| skohan wrote:
| I've implemented temporal anti-aliasing, and done poorly
| it can leave ghosting artifacts, but done well it's like
| magic how much more detail you can get out of a scene
| using this technique. There's a really excellent GDQ talk
| about this by the makers of Killzone: Shadow Fall, and
| it's like night and day how much they were able to
| improve volumetrics using temporal stabilization, and for
| their split-screen multiplayer they basically use it to
| upsample a half-resolution image with very good fidelity.
|
| With AA it's a little easier, because you can just throw
| away accumulation data if the new pixel is too far away
| from the last frame's result, and you might get momentary
| aliasing but without ghosting. With RT it's a little
| harder, because that bounce lighting information actually
| needs a few frames to exist at all.
| Havoc wrote:
| Demo was super impressive. Wish they had shown off a wider
| variety of terrain though. Bit of jungle, bit of snow maybe.
| Don't particularly blame them, but they were definitely playing
| to their strengths there
| shahar2k wrote:
| the demo project is 100GB, I dont think I have the hard drive
| space for more variety at this quality level!
| dogma1138 wrote:
| Which would actually be interesting for consoles and even PCs
| the geometry detail that UE5 supports has a huge cost in
| terms of storage space the demo project is quite tiny
| compared to a game but it takes more storage than some chunky
| titles out there that used uncompressed assets for video and
| audio like the newer COD games.
|
| People were already complaining about 50-70GB games now it
| seems that 400-500GB titles might be coming in the next 2
| years or so.
| alkonaut wrote:
| I hope there is a resurgence in procedural geometry. Much
| better to have a nice 1kb rock than an awesome 1GB rock.
| arduinomancer wrote:
| > Nanite intelligently streams and processes only the detail you
| can perceive, largely removing poly count and draw call
| constraints, and eliminating time-consuming work like baking
| details to normal maps and manually authoring LODs, freeing you
| up to concentrate on creativity.
|
| Not having to create normal maps/LODs seems like a pretty big
| deal if this is true.
|
| If I understand right normally in games you have multiple
| discrete versions of the same mesh with different detail levels
| depending on how close the player is. You sometimes notice this
| glitching out in games where a model will suddenly pop in to a
| higher detail.
|
| It sounds like nanite is more like having continuous LOD for the
| mesh.
|
| I wonder how well it works in practice.
|
| Also curious how it will affect game asset sizes
| 127 wrote:
| For non-vegetation non-deforming assets it works great so far.
| Looks absolutely seamless and works an order of magnitude
| faster.
| DizzyDoo wrote:
| Unreal actually already has an automatic LOD creation system
| (https://docs.unrealengine.com/4.26/en-
| US/WorkingWithContent/...), and there are quite a number of 3d
| Content middleware solutions that run this sort of mesh
| reduction processes. In one sense Nanite isn't anything brand
| new, but what is really exciting about it is that it operates
| from the sculpt downwards. As in, you import from zbrush raw,
| with the highest raw textures, and everything is automatically
| handled by the engine itself, in such a way that the LOD
| transitions are really hard to spot.
|
| From what I've seen on Twitter, it looks like it really
| delivers, even in its early stage:
| https://twitter.com/IonizedGames/status/1397636481913610241
| Animats wrote:
| Now that's impressive. Seeing the dog picture scale out is
| encouraging. All the LOD algorithms do a good job on rocks.
| It's all repeated instances of one object, though. I'd like
| to see someone load in a big game level at high res and give
| us a tour.
|
| Quadric mesh reduction, where the algorithm tries to minimize
| the volume difference between original and reduce geometry,
| does great on rocks. Terrible on thin sheets like cloth or
| long thin things like hair. Mediocre on objects with lots of
| hard edges, like houses.
|
| I've been trying to run the UE5 Early Access version on
| Linux. Building UE5 Editor worked, and I built and ran one of
| the built-in sample projects. But the files for the demo are
| only available for download via Epic Game Loader, which is
| only available as a 32-bit Windows program. Trying to run
| that under Wine leads to a popup complaining some DLL is
| missing. But it doesn't tell you _which one_. Some people
| have been able to get it to work, probably depending on what
| Windows DLLs they happen to have installed.
|
| Trying to run Nanite on Linux produces a line of red text
| saying that the machine doesn't have a supported graphics
| card or driver. This is with a NVidia 3070 with the current
| NVidia driver on Ubuntu 20.04 LTS, which is about as good as
| it gets today.
|
| It's a typical "we tossed the Linux users a crumb" port.
| Well, it's early access. Filed all the appropriate bug
| reports.
| boulos wrote:
| > This is with a NVidia 3070 with the current NVidia driver
| on Ubuntu 20.04 LTS, which is about as good as it gets
| today.
|
| Driver installed by "hand" or via the Ubuntu packages? More
| importantly: What's the output of nvidia-smi?
| Animats wrote:
| Ubuntu packages. Driver version 460.73.01 Cuda version
| 11.2. GeForce RTX 3070.
| simias wrote:
| Looking at these image comparisons with the sliders I'm both
| amazed at how far real time rendering tech has come and the
| ingenuity on display, but also by how relatively little it
| matters at this point.
|
| Like the shadow comparison, it's undeniable that it looks better
| and more details in the "shadow map raytracing" version, but it's
| not like the reference picture looked all that terrible.
|
| I don't have a particular point to make, but as time passes I
| feel so privileged to have grown up with videogames in the 90's
| and early 00's. A watershed moment in computing, where we went
| from low res 2D graphics to high resolution 3D graphics. We've
| clearly hit diminishing returns since then.
| skohan wrote:
| I think the difference real-time lighting makes will become
| more obvious as games cease to be cross-gen and really embrace
| current generation hardware. Baked lighting can achieve very
| good, near-photorealistic results _in staticly lit scenes with
| static geometry_.
|
| Once we see games really take advantage of dynamic lighting in
| highly dynamic scenes with a lot of moving elements, I suspect
| we'll look back at current and recent games and see them as
| lifeless by comparison.
| aspaceman wrote:
| The main advantage of new technology is interactivity. Dynamic
| illumination is _dynamic_ instead of statically baked. That has
| obvious environmental advantages. Comments like yours that
| pixel peep screenshots miss the point.
|
| These limitations seem imperceptible to you, but are very real
| in terms of an artists ability to execute on their vision. Most
| games do not currently have multiple dynamic light sources in a
| scene. You can go back and play Fear on PC to see that and it's
| awesome - Doom 3 as well.
|
| But graphics tech optimized away from that direction
| (rightfully), and now we need to account for dynamic
| illumination and transparency. Better shadows (especially in
| interactive moments) is a nice bonus.
| amelius wrote:
| That might be different once you start wearing VR goggles.
|
| The experience becomes more immersive if you see a realistic
| world, and not pixels.
| ehnto wrote:
| The difference is likely in how hard it was to get the original
| result, and some unseen limitations in the technology.
|
| Game lighting has always been dozens of tricks and shortcuts to
| get lighting to look like it behaved properly, without it
| actually behaving properly. But newer technologies work on
| getting better at lighting and material behaviour and that
| allows a level of "overall correctness" that is much easier to
| achieve.
|
| I've made a similar comment previously, but Raytracing can make
| a Minecraft world feel like real life, because the lighting is
| correct even if the world is surreal. PBR was a huge leap for
| lighting correctness, and it's part of the reason why a game
| with "okay" textures can still feel just as good as a game with
| incredible textures. I think our brains can pick up on these
| lighting cues.
| dang wrote:
| Recent and related, though without specifics:
|
| _Unreal Engine 5 enters Early Access_ -
| https://news.ycombinator.com/item?id=27290854 - May 2021 (151
| comments)
| jscheel wrote:
| I tried to run this on my 16" mbp (8 core i9, 64gb ram, radeon
| pro 5500m 8gb). The starter 3rd person template maxed out every
| single core and I was getting about 17-20 fps.
|
| _edit_ 2016 !== 16 ", and it was apparently still compiling
| shaders behind the scenes. Now it's stable at 120 fps.
| wilde wrote:
| TBH that's better than I'd expect on an old laptop with an
| unoptimized build. Like the hardware they're using is what, 20%
| faster CPU and 400% faster GPU-wise, and they're developing on
| Windows?
| jscheel wrote:
| So, I can't type. 16", not 2016.
| speedgoose wrote:
| I think you would need a laptop with more powerful cooling.
| Your MacBook is most likely throttling a lot to not melt. My
| 2019 gaming laptop, i9 and a rtx2070, becomes a fan heater if I
| want good performances in Unreal Engine.
| jscheel wrote:
| So, I can't type. 16", not 2016.
| speedgoose wrote:
| It's a very nice x86 laptop, but it's still throttling a
| lot when it gets warm.
| lwansbrough wrote:
| Not sure what you expected.. a 5 year old _mobile_ GPU simply
| isn't cut out for modern gaming.
| jscheel wrote:
| So, I can't type. 16", not 2016.
| ryneandal wrote:
| I fooled around with it during my lunch break, it really is
| power hungry. R5 3600/2080 and It still ate all CPU during
| initialization.
|
| Once running, it was sitting at 30-70% depending on what I was
| doing.
| stefan_bobev wrote:
| One of the things I think goes a little underappreciated about
| Unreal is the fact that everyone gets the source code. Interested
| in how Nanite or Lumen work? The source is right there! With all
| the comments (or lack of), with all the debug statements and
| branches that can be used to diagnose the behaviour of the
| system.
|
| Often while developing, I dive into the source of the engine to
| understand how exactly some low level system works. I also
| blatantly copy all the complex UI widgets available in the editor
| when I want to extend them/make custom ones for my games (I hate
| UI programming). This is invaluable for teaching the next
| generation of engine developers imo.
| gentleman11 wrote:
| True, but does it expose you to liability if you later do
| engine dev work elsewhere? Actually curious how that works
| zarzavat wrote:
| Only if they have patented the algorithms and I seriously
| doubt Epic sees a future for itself as a parent troll.
| WillPostForFood wrote:
| No mention of the scripting language they've been teasing, hope
| it shows up soon!
___________________________________________________________________
(page generated 2021-05-31 23:02 UTC)