So, Nanite

It has NOT reach its cap. If you knew anything about VR, you'd know that only recently has it been actually viable to play(only around 2018 with the RTX 2000s and above) because of its extreme demands in performance(2k+ resolution per eye, 90+fps recommended to avoid feeling sick) and the tendency is for it to grow

 

But total of steam players have increased

 

This tendency to grow is something people have literally been saying since 2018 and it has barely grown. It's niche status is established. Everyone who's actually dealt with sales knows this.

 

Unity doesn't need to provide a Nanite solution. What Unity did do well is providing a toolbox. They need to go back to making the best toolbox out there, and enable us to create end solutions like Nanite.

Unity doesn't do high level rendering solutions well. On the other hand they have a great set of lower level rendering api's, more complete and far easier to use then what UE has. Now of course they keep breaking stuff and moving more and more into SRP black boxes, so there is that.... But the point is Unity is better suited to enabling their users to build Nanite like solutions. Unity is not well suited and never has been good at creating high level polished rendering solutions.

I would also encourage people to look at Nanite more broadly. It encompasses approaches that can be used in part and applied differently to different context's. There is a huge gap between say 2d billboards and Nanite, with a lot of interesting solutions to be had in between.

 

Seriously?
You believe single inflated graph, which is all over the internet?



This is how it more less look like.



Thats pretty flat graph to me.

This one is reflected here


Also according to this article, unless someone can explain what was a reason to early 2022 VR spike:

https://mixed-news.com/en/steamvr-in-may-2022-a-puzzling-jump-in-vr-users/

Steam none and VR comparison, most played games.


According to
https://steamdb.info/graph/?tagid=21978

 

You can play VR at 10 fps without being sick. However for that your VR framework has to give up on the idea of reprojections and remember orientation of the last received frame, treating it as a Virtual Movie theater. So if no new frame has been received, the HMD keeps image of the last received frame where it was, while still keeping head rotation.

Currently, Virtual Desktop does this. Oculus Runtime tries to reproject, and that results in a artifacts.

So the extreme demand for hardware is fairly artificial.

 

How many of them actively use it though and not just leave it plugged in to be picked up by the survey? My Rift is a few years old and while I've kept it plugged in about 80% of that time I can count the number of hours I have used it on one hand. That's the catch with the survey. We don't know actual usage info. We just know ownership.

 

Exactly this. I own a VR headset, technically, but it was used only a handful of times. I bought it late 2019/early 2020 or something, at the beginning of the pandemic, saying since we'll stuck at home, having more time will compensate for the inconvenience to use these devices. It didn't. I have the same problem with consoles too. I have an adequate PC since I'm working with it daily being a software engineer and all. My games are just a click away or so.
Walking into the living room to start the PC there, set up the headset, dealing with all the inconvenience it entails doesn't worth it for me. My daughter used it for a bit longer, but I'm pretty sure the headset wasn't moved for way more than a year, other than the cleaning ladies move it for removing dust from and around it.
Apparently I just don't care about the surround-thing that much, it doesn't have the "wow" factor. I'm perfectly content with my flat screen monitors and experiences I can actually get through them.
But again, for the same reason I don't own any consoles either (I'm lying I have an Xbox 360 somewhere in the abyss of some moving boxes with my full Rock Band set and every discs were ever released. But that wasn't unpacked either when we moved to our current place and that was more then five years ago as well).

 

I think my Quest 2 might get used by other people more than it does by me. I've used it I think 3 times to play games, two of which were for testing the setup. It's probably been showing up in the Steam survey for about a year, anyway.

My PSVR does get used a fair bit, less "because it's VR" and more "because it's sim racing" and that's the room where I set up the wheel and pedals, and the headset is a clear upgrade to that particular experience.

 

Constant 10 fps would be a pain. Maybe, and just maybe a spike at 10fps can be ok with your described method. Have only experienced spikes with SteamVR methods and its horrible.

Next generation headsets with Foveated rendering will solve this though. Actually a VR game will potentially be cheaper to render because we only need to render a small rectangle at center at full fidelity

 

In 5.1 Unreal added Nanite support for masked materials and vertex motion thingy, basically enabling nanite for foliage.

On the scene below, 4kx4k terrain + Lumen + volumetric clouds + these dense trees i am 35-40 fps (when i go into forest i get better fps due to culling) on RTX 2060 (cranked amount of trees to bonkers levels). There are 4 types of trees spawned here.

Nanite for trees is a game changer. The trees in the distance looks as good as in close range, no longer ugly billboards, lod transition changes and not perfect impostors .

Ofc in realistic scenario in game u wont have such density but still even smaller forests in the distance and close to camera will look as good .

There is also nanite for terrain, but still in development. It works but I have small problems with it, since it eats my entire ram when i save project with terrain nanite enabled . But from my tests it also looks bonkers, the terrain in distance never looked better

 

What's the preprocessing time of that scene?
Is it possible to spawn trees dinamically (as in a evolving nature simulation)?

 

I am using procedural spawning from UE. I think it takes around 10-15 seconds for me to spawn in this particular scene...depends on density and size of prcedural volume ofc. Usually u will haev multiple smaller volumes based on biomes etc so it will be a lot faster. Dunno about runtime, enver used those procedural tools in that context, no idea if even possible

 

One thing I don't like about UE here and Nanite makes it worse, is that UE doesn't actually support very large worlds as well as it advertises. What I found is people saying ditch their world composition (and world partition doesn't look any different). It's even worse once maps get really large, where UE doesn't automatically support stitching. And by very large I mean not really that large, like 32k maps.

Nanite aside why UE looks so good with open world out of the box is more a combination of better lights/shadows and their excellent atmosphere system which really ties it all together. Not really open world specific per say, but definitely tuned to make outdoor scenes look good. Unity doesn't have anything close here even without Nanite.

It's an uphill battle to compete with UE visually now days unless you go very stylized. You have to get rid of detail in some way is sort of the bottom line.

 

I'm not sure what you mean by stitching. If you mean landscape stitching, that was supported with world composition since its inception. At its core, World composition was just a simple level loader, not anything complex (to its detriment). Even if you ditch it, you can write your own pretty quickly.

World Partition on the other hand hooks on many systems, and even has its own data representation system. One file per actor thing is completely new, automated hierarchical-lod is pretty nifty, and the new data layers and level instancing systems are major workflow improvements.

Personally, my only problem with nanite, and how Unreal handles "open world" systems, is that it expects everything to be premade.

Nanite can't handle procedural geometry. You can't even make a nanite mesh at runtime because they take too much time to generate (Edit: 3.5 seconds for 50k vertices on low-end 4-core CPU). And the necessary code is under developer folder -not allowed to be in the game builds.

HLOD *requires* level geometry to be defined during authoring. Runtime generation of a large world isn't intended, or even considered by Epic.

Aside from Nanite and large world stuff, virtual shadow map is heavily dependent on caching, and too many moving geometry tanks the performance to a significant degree. Even rotating the camera around too fast can tank the performance, so can moving too fast. Foliage is especially problematic; I see people complaining about VSM and foliage performance every day.

Nanite *is* amazing, but the whole package of UE5 really *wants* you to make static worlds. Good performance depends on the world not moving too much.

 

Built in origin shifting is a big issue with Unity. If you are a multiplayer game with baked lightmaps its not so easy without native origin shifting. In VR you notice float resultion problems already after 1-2km from origin

 

That's more of a float issue than a unity issue. Although looking at unity's roadmap, they do plan on fixing the origin on the camera's position in the future to fix that

 

Yeah but most engines fix it by having native origin shifting instead of using double precision floating points. If they only fix it for camera it won't be enough. Physics, transforms etc need it too. Do you have a article that I can read i haven't heard this was in the works

 

Most engines avoid situations where float precision errors occurs. Typically by using small locations that fit into the safe area.

Examples of small world games include skyrim, gta san andreas and I believe GTA5. In those scenarios the world fits into safe area around world origin.

Regarding VR, the precision is likely to occur because of switching to half precision floats in those particular games.

 

I tried my own game moved the camera 1 click out. Everyrhing behaved wobbly. Unity uses single precision floats. (Ironicly type cast to doubles in JIT, and then back again so the double precision is lost)

If you want true seamless open world multiplayer (Think DayZ) that's really hard to achieve without native origin shifting

 

Dayz is such a good example of large world done right. Took em 10 or 12 years but damnit what a beautifully immersive world.

 

https://unity.com/roadmap/unity-platform/rendering-visual-effects all the way at the bottom

 

I could be wrong on that I'm not a UE expert, but I could not find out how to dynamically load in separate landscapes (not sections within a single landscape) without artifacts at the seams.

But ya it was immediately obvious how static centric UE is. That's actually my #1 complaint about engines generally. No it shouldn't take 100ms to modify a heightmap at runtime, or update a small piece of navmesh, or whatever other thing performs horribly because it was designed around nothing moves and you just got to completely punt on doing it well.

 

It's an engine issue because it's a float issue.

Yeah, there are a bunch of ways to work around the inherent limitations of floats. If your engine doesn't employ them natively then you need to implement your own, higher-level workarounds which address both float precision and engine details. That's why people want their engine to provide for it.

Plus, if the engine handles it then it benefits the whole ecosystem (e.g. 3rd party assets). That won't happen when people have to roll their own solution.

 

Code (CSharp):

1. Camera-relative Rendering
2.  
3. Camera-relative rendering would allow the Universal Render Pipeline (URP) to render distant GameObjects (with large world space coordinates) in a more robust and numerically stable way compared to the built-in render pipeline.
4.  
5. The absolute precision of floating-point numbers decreases as numbers become larger. This means that GameObject coordinates become increasingly less precise the further the GameObject is from the Scene's origin. The Mesh faces of distant GameObjects close to one another may appear in the same place and produce z-fighting artifacts. To fix this issue, camera-relative rendering replaces the world origin with the position of the Camera.

I wonder how that will work with physics driven objects etc. Sure it will probably look better if rendering is done in a local camera space. But I'm guessing that it means that things moved by script and physics still will be janky

 

So... in case anyone is still interested in Nanite in a thread called "Nanite"

 

What is the issue with converting floats to doubles? I am doing it here for audio analysis. using System; gives you the doubles equivalent of Mathf functions. Seems only a few critical variables to track with floats being out of precision range are the culprits and they can have error correction built in at distance threshold.

 

Just looking at the side by side frames I can do that kind of scene lighting and depth transform using Beautify and Horizon Based Ambient Occlusion post efx plugin assets. It takes zero frames per second off my framerate.

 

Pics or it can't happen

 

thanks for sharing something related to the topic
Lumen and nanite are cool, but i do not see any situation on that video where Lumen is necessary, in fact you can do that baking almost everything + some realtime probes and mid quality planar reflection on the mirros and it will look the same (if not better, without light leaking) but with more fps, unless... can you bring a light into a dark building changing the lighting of that building in less than 5 frames? can you drive a car in the night and see how the light bounces on building in less than 5 frames? if yes, then that video does not make justice to lumen at all (which i think is the case)

 

The authoring is probably much easier than other techniques.
And also I think that foliage looks very nice using lumen.

 

This is simply false. The developers of both those assets have stated in their documentations the performance impacts of using various features of those assets and it's generally a fairly noticeable performance impact.

Sure. But getting good lighting and shadows generally requires a lot of time and artistic skills to get right. Lumen does it by simply enabling the feature. Same with Nanite. LOD's generally require a significant amount of time to create. Nanite does it for you simply by enabling the feature and converting the mesh to Nanite. You're basically trading performance for time. And for many, that's a pretty good deal which is only going to get better as more and more devices become compatible and have the necessary hardware to run it well enough.

That said, for games like Fortnite it seems unnecessary given the game never had any intentions of having good lighting or decent LODs to begin with.

 

That it looks nicer is just a bonus. It's the workflow benefit that is the biggest feature with this tech

 

I use them both. The framerate stays the same on or off. So what yer saying is Nanite image wise is a crutch for those without scene lighting chops and the image part I can reproduce with two image efx plugins.

 

Please show your workings!

 

I look at it on my computer. Are you and your like boosters suggesting I am lying? Don't mean to bust ya'alls nanite bubble. Go get them yerself and play with them. If my scene is getting a fluctuation between say 210 and 215 fps, I still get 210-215 whether they are off or on. YOU post pics proving me wrong. or yer just mad that nanite ain't the whoop ass can it is hyped up to be. You seem to think hoop jumping is in order. Go for it!

 

Good luck baking lightmaps on a 6km² map where everything is destructible and the time of day changes.

But yeah, this game is designed to work without light bounces and where people toggle the sun shadows off to get a competitive edge.

 

Well, you just dismissed entire idea of real-time GI (getting us much closer to physically correct lightning model w/o baking) and Nanite (almost hassle-free automatic LOD, huge draw all reduction, the best type of occlusion culling) because... there some post process and ambient occlusion plugin?!

People politely asks about at least so you support some of your theories, although you totally missing the point.

It's not about your specific scene that we. never ever seen, have no idea how it looks how it's composed, what's kind of game it is, etc.

It's about 5 years old game with stylized art style which got upgraded with all heavy features running consistently 4K 60 on $500 console.

Digital Foundry guys very reasonably argue how important all of that might be for indie developers without huge asset budgets. As small budget game could have awesome things like real-time GI for acceptable performance cost. That with detailed shadowing that doesn't pop in a distance, have shadows cast every small rocks and grass blade. Much better than usually expensive cascade shadows.

Also comes with Nanite supporting WPO and masked materials, so we can have mesh trees in a distance instead of ugly sprites used for decades?

And TSR is giving us a built-in supersampling technique, available on consoles.
All of these addressing longstanding development challenges.

And you're talking something about postprocessing, being rude to people who politely ask just for a screenshot.

 

There is no tech in unity that comes close. Infact they had to undepricate enlighten because they didn't had a solution. And even enlighten is precomputed realtime GI so geo needs to be static.

 

Though that 1 draw call in nano tech seems promising. If he can get it to work properly on forward+ with some sort of GI it will be a success

 

that is also true, but i still prefer to bake it and have more fps, at least for me, more fps is priority. If the game is running at 100fps with cheaper techniques like baking and stuffs and you tell me "hey, lets use lumen, the game will run at 90 fps" and it will looks the same, i still prefer the cheaper but harder way, also this game is mostly static (for what i can see) at least for me, the gamer is the priority over the time i spend working on a game like fornite.
About nanite, i think is good in any case...

yes, exactly...

Look the video again in minute:
2:29 not exactly good back there (it is a shame that a AAA deliver something like this in my opinion)

4:24 some rocks has shadows, some others does not, not exactly accurate (pc version)
4:42 popping?
7:17 not exactly good, this does not happen with baked lightmaps (it is a shame that a AAA deliver something like this in my opinion)

7:54 shadow popping

and i can continue for the entire video, anyway, i'm not saying Lumen is useless, i love lumen, is a game changer, but in this game, maybe it is useless, or at least on that video

 

No reason to beat around bush. You are most certainly lying.

 

Baking can actually reduce performance more so in unity were the process is completely manual. Default in unity they place objects more or less random on the lightmaps. Since you can't batch meshes on seperate lightmaps drawcalls and bacthes will reach through the roof

 

Its quite fair to ask for some kind of visual data (especially as you seem to have it on your screen right now?) to back up your initial claims. Obviously if its NDA work then no worries; just grab some free assets and show the comparison.

 

Also it needs to be at the same scale, open world at 6x6 km

 

Those who are satisfied with the baking process are, of course, those who know that this system is sufficient for their projects. A game engine should give you as much flexibility as possible without questioning your creativity. Nobody here should make funny comments that a system like Lumen should not exist or that it is not needed. For example:

While developing a huge rpg game with a size of 2016 km2, we have already solved errors such as Floating Origin. We allow the player to navigate the entire game map and even closed dungeons without any loading screen in the game. Now it would be super funny if you told me that we need to divide the game into scenes for the baking process. We absolutely need Lumen-style lighting at the expense of performance. That's why we included the RTX system and unfortunately we had to add a graphics setting called RTX MODE after Ultra in the game settings. Maybe for those who still think we should bake, you can build your own houses and interior decorations in the game. So forget about the cooking system for such new generation game ideas.

As a final note, the baking system has high performance as you said. But have you ever had the opportunity to observe its weight on memory in a large-scale game?

I don't want to make the same comment about Nanite for the second time, as I said, due to the nature of a game engine, it is to provide a tool to the developer. How functional this tool is depends on the developers of the game engine. But no developer can deny the picture in the middle. If a system is needed, no one can deny it here.

 

I get physical trauma just imagining this.
And then you have to bake at least 2 lightmaps that transitions with each other for different time of days to get the same result as Lumen. No..

 

Or... people don't just assume everything they read is true. Do you assume everything you read is true?

"I have a magic flying carpet, and it's up to you to prove me wrong!"

The advantage & appeal of *Lumen* isn't so much how it looks, but that it can simulate that quality of global illumination in real-time, especially in situations where scene lighting isn't already known beforehand.

It's not. It's very dynamic. Fortnite's main feature is building forts (hence the name, "Fort-nite"), and they even have a creative mode where you can make your own custom maps/levels, which can get pretty detailed.

 

well you can see in the video that lumen is making those weird light leaking thing and popping so, there is that xD again i do not see why lumen is needed on that game and if you are making a game with light glitches, popping and weird effects + less fps just for sake of less work i would say at least fix those errors before getting that game released...
Also, you can see on any video game review from any game that people are always complaining about lower fps rates and stuttering so xD there is also that. Again, i love lumen but if is not necessary and will make things worse then don't use it, i feel like unreal did it just for more marketing

 

That's bad faith argument. It's edge cases you have to look for, and performance are good in that video. And stuttering is explained too by shader compilation issues but only on pc, and it's not tied to lumen and nanite.