No Unreal 5 thread?

Chris Robert - he talked about it on a Star Citizen show last year, but he only mentioned it and how revolutionary it would be, and after that I never heard anything about it. If that's what I'm imagining.

 

Speaking of John Carmack, Id Tech 6 was supposed to have a virtualized geometry system akin to Nanite. He just thought it would take too much effort to make it work properly at the time (early 2008).

https://en.wikipedia.org/wiki/Id_Tech_6
https://twitter.com/id_aa_carmack/status/1397672732033228801?lang=en

 

- but try to move some times a single folder or jpg files inner the engine (5.0 beta 2)... #rip crash the system. Cool, Nanite... yeah...Nanite... pffff.

WORST, 'retarget' a character... meh!

 

Except Megatextures had very specific, technically hard to adhere to requirements and suffered from extreme texture popp-ins. Nanite doesn't have similar issues id's Megatextures had as far as I'm aware. Not from the developer's perspective or end user's perspective.

 

That eventually evolved into virtual textures, actually.

 

That's exactly the impression I got. I've been working with UE a little. Saw that 5 was no longer in preview, and during the download read in the announcement that despite the official launch neither of their big-ticket items, Nanite or Lumen, are actually finished yet. I know that they've also done a bunch of significant work elsewhere, but indeed, officially launching while their flagship features are still work-in-progress feels like standard iterative development stuff with a lick o' marketing paint on top.

Are they so far from being ready that Epic didn't want to wait? Or, my hunch, is this a way to get a couple of extra marketing splashes as they're individually launched in the coming months?

The sample I looked at seems really cool. Giving developers a whole, ready-to-go game which can basically be modded into whatever we want (as long as we're making a shooter) is a nice starting point. That said, what's going on with their documentation on that? A massive page in the manual tells us what's in each of the sample's in-game menus (do they think we've not played a game before?) but nothing I saw explained the architecture or best practices that the project is meant to demonstrate. I guess that'll come in a series of videos or something?

Also interesting: they've been pushing hard towards visual editors for everything for years, but their best practices sample has a whole bunch of Blueprints where all you can see is bounding boxes, and all of the heavy lifting is done as data entry.

As someone who was never a fan of the big chunky icons they used to have all over the place the new UI feels like a significant improvement. Overall it still feels cramped, even with a pair of large monitors.

Anyway, new and better tools are good to have, and I've been having fun playing around with it.

 

Like no indie games can benefit from no retopology/baking of any kind needed (Nanite) or being able to scale systems from a couple hundred objects to several thousands (Dots).

I'm a one-man army, and made things using DOTS that would have been outright impossible to do without it (or rather, take years to make).

If you mean efficient and good quality in-editor tools for character and terrain creation, there's already some in most engines (depending on where you set the bar for "good quality"). However that saves you what, the time spent exporting assets? Which is considerably less than you waste doing retopo and baking normals/occlusion, for example.

Imho the capability to throw extremely detailed/unoptimized geometry data at the engine and have it automatically optimized in realtime for both performance and quality (for the current camera pov) is invaluable for small studios. This can easily reduce the amount of man-hours needed to create assets by half.

 

In order to retopology to even come to question, you need the highpoly mesh to exist first. And trying to sculpt everything in Zbrush is rarely an efficient workflow. In many cases, it is easier to model a prop as lowpoly from the start. So no matter how you look at it, Nanite is only justified for photorealism and ultra detailed graphics. Even if it works "as fast" in a simple scene, UE5 game still going to have higher minimum system requirements than say Unity. Ones who win the most will be hardware manufacturers I guess

 

I have to say I was very impressed with the UE 5 Release - State of Unreal video. Something about it just put Unity marketing to shame. I think as a whole it just felt very coherent and targeted with a very clear vision

Nanite and Lumen are going to be game changers, though unsure to what extent for the indie market, but really it is the coherence shown between engine and free tools like Quixel Mixer and Megascans, MetaHuman etc that is making a huge difference. It just feels like a complete package.

What really impressed me was Unreal's web presence and community focus. Maybe they've always had this, but what they showed in terms of having a community site where you can access learning, content, forums all with a cohesive design. They provided tools to allow you to easily make your own tutorials to publish and the snippet repository was especially interesting ( see here ) as it allowed you to copy and paste code and text based assets ( e.g. graphs ) directly from the engine into the browser to share with others.

It certainly peeked my interest in UE much more than it ever has done in the past.

 

None of the rendering features is ever "finished". No software is ever "finished"

That being said, both Nanite and Lumen are production-ready. It just works. One of my projects already uses it extensively. And it's definitely not AAA
Users just need to be aware of new feature limitations, as usual.

Now waiting until R&D makes Nanite usable with skinned meshes. Removing polygon limitation on characters in dialogues, om nom nom nom

 

Which most of the time does, unless your game has is a stylized, low-poly look to it. You need a hi-poly version even if it's only to bake normals/occlusion for the low-poly one. I don't think hand-crafting height maps in photoshop and then converting them to a normal map is the preferred workflow nowadays.

Many indie games opt for a cartoonish/flat shaded look precisely because it allows you to skip many steps in the asset authoring pipeline (flat shading? no bake! simpler geometry? no retopo!) that Nanite allows you to skip regardless of your artistic goals.

Yes, of course. But this kinda assumes small studios don't want to have photorealistic, detailed graphics. I wonder how many studios would choose a simpler, sober visual style over realism for purely artistic reasons if time/money were less of a major constraint.

Not saying every game should be photorealistic, but a broader artistic palette is certainly a nice thing to have and I think Nanite accomplishes this.

 

I don't care what word they used, the important point is that in their own release post they specifically called out those two features as still being early access, or preview, or experimental, or delayed fanfare, or whatever label you want to pin on it.

Edit: Here we go: "Meanwhile, although some major new features like Lumen and Nanite have not yet been validated for non-games workflows..."

So it's officially ready, but only for some types of stuff, which is indeed a correction worth making

 

Yep, especially important given that many shiny rendering features (of any engine) in recent years are so performance-heavy that are useless for a game developer. Like RTX-only lightning or 3D fluid simulation. The latter is also available in UE5 in its initial version but is not heavily promoted.

Nanite works on the old gen (since Maxwell GPUs in Nvidia case, the first GCN in AMD case). They say it even works well on HDD.
Lumen is more demanding, as designed for the current-gen console. It might be still playable (30 fps) on GTX 1060, although it might depend on the game.

Huge parts of Unity/Unreal are like this, designed primarily for game workflows. Isn't that what we want most of the time?

However, I'm puzzled about what they actually mean by "Lumen and Nanite have not yet been validated for non-games workflows". What's missing? Perhaps the temporal accumulation of Lumen causes a visible delay when rapidly changing the camera and that's a big no-no for rendering a movie? Things like that?

 

It might be the most efficient workflow in many cases, especially for anything modular. Trim sheets are very powerful technique. Alternative will be sculpting many pieces for every possible situation, which isnt exactly time saving. In only situation where the sculpt+retopo is preferable (character models) Nanite doesnt exactly help either

And time/money contraints will always be there, even if you download the entire megascan library, you'll need the rest of your assets to be on comparable quality level

 

They can just use Unreal's Raytraced Global Illumination for non-real time rendering purposes.

 

ECS/DOTS is a greater thing than improving graphics. At some point, all engines will make it trivial to manage rendering.

What they won't all do equally is make it trivial to control all your data at scale.

In Unreal, CPU time is a struggle and people compiling the matrix demo, and profiling are seeing it's not all about how quick your GPU is. There's a heck of a hit on CPU as well. Certainly more than this 6 core CPU can run smoothly.

But in Unity, my code runs like butter and now I'm learning DOTS, it's running like butter on lube.

I think when 1.0 launches, most people should actually check out ECS anyway. It's rather fun and enjoyable to think differently about your data.

 

it seems that you spend more time moving assets around than developing lol

jokes aside, there's a fix redirections button that solve these issues, and even when UE does crash, from my experience it takes much less time to reopen the project than in Unity.

working with Unity in huge projects is so painful... takes forever to open, get into playmode, exit playmode, refresh the project, reimport a single asset...
of course there's a lot of bad practices that contributes with all this overhead, but still

 

Retopo is relevant in various non sculpting scenarios as well. Like boolean workflows, which can bring incredibly quick results, but also messes up the topology. So it's not just photorealism necessarily. And not having to spend the brainpower on correct topology sounds rather creatively freeing.

 

They look like Unreal and this is awesome.
Even tutorials made by some random people on the youtube looks better with unreal than unity.

 

I also watched some Unreal videos recently, so I had the feeling that all Unreal games somehow look the same, they all have the same Unreal look.

 

Imagine Unity laughing at Unreal

 

I may be wrong (havent tested yet) but I think that any auto LOD algorithm, Nanite included, can only go down from the existing polycount, so if there is any derpy triangulation because of booleans, it will only make it worse.

 

On other Nanite-related matters, what does everyone thinks about Epic deprecating hardware tesselation shaders "because of Nanite"? Are they really that redundant (from my perspective not at all, for functionality displacement shaders offer, such as, again, modular creation, and animated effects) to Nanite, or it is some 4d chess move to funnel more free beta testers into Nanite development?
https://forums.unrealengine.com/t/nanite-and-displacement-tesselation/231500

 

Tessellation is much faster with custom shaders so they have been redundant for a long time (depending on implementation). You can still generate your tessellated geometry with compute shaders (and should).

 

Hmm, but what was the difference between tesselation shaders built into UE and custom shaders with the same algorithm? And why users in the thread I've linked are complaining if it would be trivial to just custom code them back?

 

I'm not a fan of removing tesselation. I've seen many people complain about it on UE forums and discord.
There's no alternative for a ton of use cases, and when it comes to landscape the only alternative is VHM which is in alpha, and it's workflow is much worse than tessellation.

 

Nanite workflow is a big win regardless of the style you're aiming for. There's really no discussion to be had.
The majority of games use baked normal maps to fake the real thing, and like Pantheneye mentioned - even games that avoid unique bakes through highpoly assets would still benefit from nanite crunching it down.

 

If we're talking about game runtime performance: not true, it's the other way around.
Unreal has it's own game thread which is separate from rendering.
The rendering work is done on the render thread.

They handle draw calls a lot more effectively as well.
Your game thread only does your blueprints and C++ game logic & possibly UI.

The matrix demo has crazy requirements for good reason, but most unreal games are GPU bottlenecked, unlike unity where it's the CPU (per thread performance since usually it's the main thread, so increasing threads/cores won't help).

Starting from UE5, they switched to DX12 by default. Almost all (probably all) rendering work is done on the rendering + RHI thread.

It used to be that game thread still handled a bit of work from the rendering thread, but this changed a while ago.

Unfortunately DX12 in unity HDRP is much slower than DX11 last I tested (2021.2).

 

Interesting. If these changes are indeed Nanite-related, Epic are betting the most on this system, even willing to break other stuff. The only reason I managed to find, for why those features cannot coexist, is that Nanite is running some custom rasterisation code on GPU, and thus an exception of normal rendering process. But why remove tesselation altogether, thats still beyond me. Sure they could just disable it working on Nanite objects

Another limitation of Nanite which baffles me is no VR support. Could someone more tech savvy explain for me why it can be problem? From my limited understanding, all thats needs to be done for VR is to render the view from 2 cameras each frame. Is it somehow more complex on the renderer/GPU side?

 

Enabling Nanite is as simple as checking a box on each compatible mesh. How can you not justify that? Since we have so many people who believe this is only valid for photorealism I'm currently in the process of getting one of Synty Studios demo scenes working in UE5 to show some actual statistics.

 

Very often new rendering features don't support VR in the first release. Recently it was like this for volumetric clouds and water implementation. Earlier probably Niagara VFX and much more.

I believe there are 3 reasons
- It's simply more work to adapt shaders, render passes to stereo rendering. Might be easier after the flat rendering code stabilizes.
- Enabling these new features on VR often would result in a performance hit. A few months more of stabilizing/optimizing a given feature can result in actually acceptable performance on all of these mobile-based VR sets. While Nanite itself is a gamechanger, it adds a fixed base cost for every frame.
- And... Fortnite is being developed on every possible platform, except XR. Fortnite is a testing ground for most (if not all) rendering features. Flat rendering has to be prioritized.

 

I'm not questioning the ability of ticking a checkbox, only what the point would be, in case of lowpoly. Millions of objects? Sure there are already instancing techniques for that, including in Unity.

 

All of the following images were made with Synty Studios Dungeon Pack linked below. I imported the assets to UE4 (marketplace download didn't support UE5), migrated them to UE5, changed rendering mode to DX12 (migration tool missed this), and enabled Nanite on all static meshes.

https://syntystore.com/products/polygon-dungeon-pack

Without Nanite the number of triangles drawn is around 2 million and the number of draw calls is up to 1,500.

Spoiler: Before Nanite

With Nanite the number of triangles drawn is around 80,000 and the number of draw calls is up to 550.

Spoiler: After Nanite

Overdraw included to show that you could optimize this quite a bit further if you wanted to.

Spoiler: Overdraw

 

Even the first option wouldnt be a huge hit to performance, on modern platforms

 

Modern platforms include some low-end devices like the Switch.

 

Which was perfectly capable of that level of graphic even before UE5

 

I swear I have never seen so many people argue against free performance.

 

There's a difference between "being capable" and "how much effort requires pushing the game to another platform".
In the case of Switch, many, many studios (both Unreal and Unity) hire external studios, so they wouldn't spend time on porting. Switch often requires lowering asset quality to fit into its budget.

It's amazing how much time we spend justifying that automatic and simple optimization is crazy useful for developers

 

Yes, but only with way greater optimization effort than flipping a switch.

 

It wouldn’t, if you were just rendering the environment. But is a game. The difference between those two tests is that on the second, you can have more characters, props, animations and of course vfx. I’m not a fan of micro optimizations, but optimizing as you go and taking advantage of things like that is just smart development. If you only consider performance when it becomes a problem, you development journey is going to…. be less optimal, and fun.

 

That goes without saying for anyone who knows what they're doing. No engine magically enables things that the hardware is incapable of doing.

We use Unity / Unreal / Unigine / whatever not because they're magic, but because they've already done a bunch of work which we then don't have to repeat.

 

About Switch: https://docs.unrealengine.com/5.0/en-US/nanite-virtualized-geometry-in-unreal-engine/ (Supported Features of Nanite - Supported Platforms). So no magic optimization for it indeed

 

The Switch is a Maxwell-based platform and Maxwell is supported on the PC. Nothing prevents it from being added if it isn't already supported. Of course even if it doesn't come to the Switch it's still free performance for platforms that do support it.

Once again it's very bizarre to me that people are railing on free performance especially when we've literally had people asking in the GIGAYA thread that Unity target less than ideal platforms to see just how difficult it is to target them due to performance concerns.

 

How you can be sure there arent other limiting factors besides GPU architecture? When even more powerful consoles (X-One, Ps4) are only listed as "experimental support", with no guarantees given.

It is not "railing against performance", it is simply critical examination. The euproria around Nanite is getting annoying. For what we know, it is situational to use (even the shape of the mesh can reduce its effectiveness), and has lot of compatibility issues inside engine itself (transparency, VR, tesselation shaders). Not sure why you keep bringing up low-end platforms since Nanite excludes most of them (mobile and last gen consoles). When something requires better hardware to simply run, it isnt free performance.

 

And that’s all folks, join us next week where we’ll try arguing that not using any LOD at all and having full polycount even for meshes 2km away is good, actually.

 

Every. Single. Rendering. Feature. Is. Situational. To. Use

Using Static Mesh vs Skeletal Mesh, skeletal animation vs vertex animation, static light vs dynamic light, separate actors vs Instanced Static Mesh. Modeling vs sculpting. Geometry vs normal maps vs mesh decals. So on, so on.
Every time a new feature is introduced to rendering, we need to ask and answer ourselves what's a trade-off, what's supported or not.

https://twitter.com/bartwronsk/status/1327509557015310336



"Euphoria" is fueled by state-of-the-art technology which is available free of charge (we don't pay extra for Nanite, unlikely some advanced features of Unigine or Unity).

All you need to do is mark this checkbox on the given mesh at any time. No need to switch rendering pipelines, rework meshes, or use another programming paradigm. It's one of the easiest to apply asset/rendering optimization ever.

Nanite already supports approx. 90% of geometry is used in the game. Static meshes with opaque materials.
Work on supporting masked materials and World Position Offset is underway, perhaps it will come with 5.1.
Support for skeletal meshes is researched.

In other words, it's already production-ready, you can reach milestones and ship games with it. And it gonna improve over time, the same as UE4 rendering improved its brand new deferred renderer gradually. It was a bit lacking in UE 4.0, but still, we got justified "euphoria" when comparing UE 4.0 with UE3

That's what developers need exactly, especially non-AAA studios without a dedicated rendering team. Most of us

Sincerely, I do hope I managed to "de-annoy" this topic for you

 

It's a bit of a bummer they don't support Switch (at least not officially: we have full source code access after all).

Maybe it's not a high priority since UE Switch games tend to use forward rendering due to the lower memory bandwidth and Nanite doesn't work with forward yet (but it should be possible by doing the forward+ in the same pass which renders the materials to the screen).

 

Nanite can be interpreted as an extremely granular LOD system.

Crafting only the highest LOD, and having the engine dynamically decide the level of detail at which to rasterize it is good imho. What are the downsides? Takes up less disk space, less memory, depending on your mesh you might not need to have normal maps.

Heck, if your triangles are small enough you wouldn't even need to use textures or unwrap the mesh at all. Color information could be directly stored per-vertex. I know I'm stretching the concept here, but the general direction Nanite is pointing at has few downsides that I can think of. Of course it does have a lot of limitations now, but still.

 

I agree. I was being sarcastic, implying that people "critical" to nanite will tell us that no LOD at all is superior, somehow.

 

Unity also unlocked free performance gain for literally free. And it is available already past few years. It is DOTS burst. Even no need for jobs or ECS to use it. But it requires specific way of coding.

Plus it also works for many low end hardware.

I see it like performance focus, Unreals tackles GPU side, while Unity CPU side.
That's nothing new. But it is good, it is available to others. Choosing tools that suit the need.

And as benefit of Ninite progress is, devs using Unity, also developing similar solutions for GPU, as we observed.

Lots of goodies on reach of your hand.

But I also don't get it, why some people are so jealous, from getting performance gains, provided by the revant engine.

Feels like Ninite is treated sometimes in similar ways as DOTS. Like they are only useful for milion of things on screen. But ignoring totally benefits of being used in small scale projects.