[HN Gopher] Unreal Engine 5 ported to WebGPU
___________________________________________________________________
Unreal Engine 5 ported to WebGPU
Author : astlouis44
Score : 102 points
Date : 2024-02-15 17:45 UTC (5 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| crazygringo wrote:
| Can UE5 games be compiled to WebAssembly?
|
| As someone who knows very little about this space, is this just a
| hack for fun that nobody would actually use, or does it herald
| the possibility of an entirely new set of games that run in the
| browser?
| kevingadd wrote:
| Unreal previously had built in support for asm.js + WebGL, so
| it's pretty reasonable to expect that you can compile UE5 games
| to WASM. The question is whether they will run, and it looks
| like the people responsible for this demo have ported the
| renderer, which is a big part of the equation. You would also
| need to port things like input, sound, filesystem and
| networking, but since they're loading textures and models,
| filesystem is probably ported too.
|
| The browser is still pretty bad for deploying large
| applications like a UE5 game, so your guess is as good as mine
| when it comes to 'will people be able to actually ship this
| way'.
| snarfy wrote:
| I remember their 'citadel' demo. I recall it disappeared
| rather quickly. All that seems to have survived is a youtube
| video of it. https://www.youtube.com/watch?v=c2uNDlP4RiE
|
| > The browser is still pretty bad for deploying large
| applications like a UE5 game Please wait,
| downloading 80gb of content....don't refresh page or clear
| browser cache...ever
|
| I do appreciate the achievement here, but it's not something
| I personally would want.
| jncfhnb wrote:
| Not at the moment.
|
| Seems likely to be a hack that nobody would use.
| adam_arthur wrote:
| The screenshot on the post appears to be running in the
| browser. So probably yes?
|
| I doubt they are exporting pure JS interacting with WebGPU, but
| no idea really
| warvstar wrote:
| Not from the official source, but we (Wonder Interactive Inc.)
| have a custom version of the engine that compiles to wasm. We
| are looking to upstream to Epic, or at least have a plugin that
| doesn't require custom source.
| boarnoah wrote:
| I love the idea you folks are trying to get this upstreamed,
| would benefit everybody.
|
| IIUC the reason HTML5 was dropped in the first place was for
| the big render re-work that went on during 4.27 + 5.0. So now
| seems like a good time to add modern WebGPU support back.
|
| Do have to ask, isn't your business model for
| "theimmersiveweb" built around this WebGPU capability?
| Providing that tech to others or making your site a
| marketplace for web games?
| dmytroi wrote:
| UE5 dropped support for 32 bit platforms, so at the moment not
| without some code changes.
|
| WebAssembly is working on adding support for 64 bit address
| space though.
| kevingadd wrote:
| This work was apparently done by Wonder Interactive, you can see
| a previous post about their Unreal browser porting work here:
| https://theimmersiveweb.com/blog
| Jasper_ wrote:
| astlouis44 (the submitter) is also the CEO of Wonder
| Interactive
| astlouis44 wrote:
| I'm actually the COO! The CEO is my co-founder, who has also
| commented on this thread.
| dang wrote:
| Is there another link where this work is discussed in more
| detail?
| ww520 wrote:
| This is great news. This opens up other languages using Unreal
| Engine. This also opens up other target platforms for Unreal
| Engine.
| jbverschoor wrote:
| Perfect.. Although cocos2d / cocos3d have been cross platform
| forever.
|
| Let's see how they'll do content streaming / no loadtimes
| xandrius wrote:
| Now time for them to switch to a saner language (say C#), and
| it'll be great!
| JCoder58 wrote:
| There have been a number of community attempts to implement C#
| as a first-class scripting language. Most fail due the
| developers running into life.
|
| The latest active plugin for C#/.NET is UnrealSharp
| (https://github.com/UnrealSharp/UnrealSharp). They have an
| active Discord: https://discord.gg/HQuJUYFxeV
| xandrius wrote:
| That might actually make me want to give it a try! Thanks :)
| alex_lav wrote:
| C# continues to be the best language I never ever want to use.
| Maybe UE supporting it would change that!
| CSMastermind wrote:
| Definitely one of the benefits of picking Unity over Unreal.
| not_your_mentat wrote:
| Hey Thought Police! Are we allowed to say positive things
| about Unity again?
| StrauXX wrote:
| Epic is working on a, somewhat Haskell esque, scripting
| language for UE5. It's called Verse and currently available as
| a beta in the Unreal Editor for Fortnite, which is a simplified
| UE5 for creating community content for Fortnite. I haven't
| tried it yet, but the talk they held at the GDC a few years
| back was promising.
| xandrius wrote:
| I wonder why so many prefer reimplementing the wheel (see any
| sort of Xscript out there) instead of leveraging some pre-
| existing and proven languages. I don't mind if it is
| something other than C# but I want great IDE support and,
| most importantly, memory safety + strongly typed.
| wdb wrote:
| Think this is are the same people:
| https://www.youtube.com/watch?v=TI3KVJFz2L0 (Unreal 5.2 on the
| Web, done properly!)
| Zetobal wrote:
| I get the excitement around it but most ue5 games are giant... I
| get that pixel streaming is expensive for stupid car
| configurators but downloading 8gb just to look at your new car...
| I don't know.
| jsheard wrote:
| Yeah, the elephant in the room with big games on the web has
| always been and continues to be data storage. Even if the user
| sits there and waits for the whole thing to download there's
| still no reliable way to make sure it _stays_ downloaded until
| the user decides they want to uninstall it, all caches and
| storage APIs are subject to the purged at any time.
| warvstar wrote:
| We have the ability to stream in content from our CDN, so
| even devices with little to no storage capacity can run games
| of near infinite size. The main issue in today's browsers is
| the 4gb ram limit, although many games can run within that
| limit. We have MEMORY64 support as well, removing that ram
| limit, but it will probably be a few months before some
| browsers enable MEMORY64 without having to use a flag.
| jsheard wrote:
| Streaming solves some of the problems, but the browser
| purging caches behind your back means you'd presumably have
| to serve the same data to the same user many, many times in
| the course of a playthrough. Even if you get a good deal on
| bandwidth, is that economical? And how wide of a connection
| does the user need to keep up with streaming high quality
| assets?
|
| Games are already pushing 100GB when you download them up-
| front, with redundant streaming it's not hard to imagine
| that piling up to over a TB of bandwidth for one user.
| warvstar wrote:
| It can be, we have our data cached as close to the user
| as possible, in over 300 locations. It does add some
| latency, because instead of a 3ms latency to fetch and
| decompress assets, it now might be 17ms. However, because
| we also have a memory cache, this can reduce that latency
| significantly, and we use that for as many small and
| recently accessed assets as possible. Our virtual fs is
| multithreaded and works in tandem with Unreals async
| loading threads, so we are able to fetch multiple assets
| at a time, reduce wait tune. We also have the ability to
| know what assets are commonly fetched in a certain period
| and to fetch those ahead of time.
|
| Of course, if you combine bad networks, lack of storage
| capacity and large projects, you can be sitting around a
| while, or may not have the best experience. Keep in mind
| though, that the browsers don't usually evict data from
| the cache unless you've used up the storage quota, the
| system is under storage pressure, or the origin has not
| been accessed in a while. According to them
| warvstar wrote:
| That's actually the main thing we've worked on, WebGPU support
| is small potatoes compared to it, but I'm happy it's getting
| some attention here. We have an asset streaming system that
| enables you to stream in large, or near infinite size worlds at
| runtime, of course you still have to be smart about memory
| usage. We also have a server-side streaming solution that can
| be used as fallback, for constrained devices.
| astlouis44 wrote:
| For anyone interested in learning more, you can join our Discord
| here:
|
| https://discord.gg/prsKfwyzDC
___________________________________________________________________
(page generated 2024-02-15 23:01 UTC)