Comment by daenz | Hacker News Reader

Comment by daenz | Hacker News Reader

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).

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.

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.

I think its a generalised thing. Old Hands will lament that new hands didn't have to suffer nearly as much work/wear/time to produce something very similar.

It's about the seeming unfairness in cost of producing, not the end product. Everyone benefits with the new way (assuming its actually undeniably better). The newcomers also don't have the 'back in the day we had to...' stories either, and will make some mistakes the old hands wont with the new technology.

Lighting a movie set isn't trivial either but it would be nice not to deal with implementation specific settings.

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.

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.

And nonetheless there are hilariously bad scam games on Kickstarter like Dreamworld (which got it's first "funding" through ycombinator)

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

> 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...

> 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?

For Lumen's hardware raytracing:

> Video cards must be NVIDIA RTX-2000 series and higher, or AMD RX 6000 series and higher.

The best part of unreal compared to unity is the stability. You lose that with experimental and early access modules or versions

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.

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.

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.

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.

Well it is an early access after all. Curiosity aside, why would anyone want to migrate?

Because your particular project might really benefit from one or more of the new features?

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.

Reply on news.ycombinator.com