UE5

But you, guys, know that's this is a typical tech demo? Designed as the stress test for new technology, pushing hardware to the limits. That's especially important when working on new renderer and asset management (which Nanite partially is).

Making a demo that runs well on every hardware would make zero sense. It wouldn't stress-test new systems. Developers wouldn't know how the engine handles anything more than simple scene, like... you know... new renderers in... another engine

This valley demo is 100 GB (with generated caches), contains a lot of scanned rocks. And very much overdone monster meshes, composed out of extremely detailed static meshes. We wouldn't even get 2 fps with UE4 at this polycount. If the scene would ever be load as the entire level and monster would have to be loaded to memory.

There are few other demos like Infiltrator or... my... this Kite demo... OK, the Kite demo is kinda weird, doesn't prove much, it's just a nice promotional video. Anyway, none of this demo represents engine performance in the typical game.

It's the same as judging Unity performance by their demos. Well, at least Unreal demos are... ekhem... real. Not using some engine hacks or solutions never actually added to the engine

For instance, this UE5 + voxelized landscape + every rock reacting to physics. Running on 1080 Ti.

 

Is that a real question? I've been using Unreal since it was released and I keep up to date with their current musings, do you know how many dynamic GI solutions we've been presented with so far? Quite a few, when the engine got released we had SVOGI which was too heavy / too buggy and it got dropped.

Next there was some LPV migrated into the main branch from the Fable Legends thingy (unfinished), next we had some terrain based attempt which I didn't pay much attention to and I'm sure there's something in 4.24. I'll skip the Nvidia branch..

I know its a tech demo and as usual I'm like that's nice, back to work.

 

Pretty sure it was rhetorical.

 

Ye that is true that SVOGI was supposed to be RTGI solution for UE4 and on that basis we need to get Lumen with grain of salt, but I think Lumen seems to be more polished, also in general ppl have better PCs than 7 years ago even considering Steam data and consoles are considerably more powerful in this gen. They still have like 1 year to polish and optimize things up and I want to be optimistic here, that Lumen actually will be a core feature of UE5, not something that failed like SVOGI .

Nanite just works, its so fun to play with it.

 

I don't remember Epic ever actually promoting real-time GI in UE4. Never heard Epic saying "we have dynamic GI, not the experiments" before Lumen.
Perhaps to referring to some materials shown even before releasing UE4? Was there any trace of SVOGI in 4.0? This time is not a rhetorical question.
Really, I remember a lot of stuff missing in their new deferred renderer in the early versions of UE4. Didn't know that anything GI-related was even present in the codebase. But maybe there were some leftovers?

LPV? Someone integrated a partial solution from Fable and... that's it, probably nobody in Epic had worked on this. It wasn't mentioned in release notes or anywhere if I remember correctly.

First time I hear about "some terrain-based attempt" or "something in 4.24", in terms of GI. Care to elaborate?
What they've done lately was adding things like virtual texturing, a new sky atmosphere model, SSGI, optimizations to distance field generation. Most of this stuff very useful to build complete non-RT GI solution, but... Lumen is the first-ever dynamic GI presented by Epic. You know, something actually implemented. Not just some forgotten presentation.

 

Came for the lighting, stayed for the phenomenal blueprint polish and functionality.

Mind also blown when he picked up the sphere and the GPU particles were influenced by the runtime objects which all influenced the bounced lighting in real time. All of these next level systems working in tandem and at runtime is so next level it hurts. The volumetric smoke with depth obscurance was also so many simultaneous levels of awesome.

The mind boggles in so many directions. Those blueprints are opening the door to so much gameplay possibilities and a low barrier to entry to high level systems that anyone can use to start getting their feet wet with gamedev, but then you start to think about the cinematic possibilities of Realtime movies and adventures. One can imagine the bed ridden/ elderly going on hour long nature hikes in VR. Dungeon masters creating games in real time with players taking on the roles of NPCs and players alike. Chefs teaching a virtual course to people the world over in a digital kitchen (Picks up two pieces of bread and sandwiches it around a student and they turn into an idiot sandwich). Watching your favorite movie from the vantage point of a new secondary characters with little easter eggs strewn about. The potential for this tech to positively effect people of all walks of life the world over is endless.

I know we're beating a dead horse at this point, but some of this stuff I'm seeing for the first time and these tools really invite you in with exciting new possibilities and wonder at what expanding functionality they'll be adding over the coming years.

As hardware advances, pipelines are optimized, and features are added, can you imagine the kinds of crazy real-time particles and lighting, and gameplay, and innovative real-time experiences that will be coming from this? Gaming and entertainment are starting to feel like a wild frontier again, like we're on the precipice of a redefinition of entertainment, in damn near every industry with a single piece of software. Maybe hyperbolic, we'll see. The mandalorian has already made waves with Unreal tech and this is all waiting in the wings... As more filmic projects enter this engine the lines between gaming and film will blur and more and more of the best creators of media will intermingle to create amazing experiences with this tech.

I know i'm being giddy and stupid, but we haven't seen advancements of this caliber in a long time and it's a tad nostalgic of better times in this industry.

 

They had LightPropagationVolumes (killed off)

And they currently have SSGI and raytraced. See here:
https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/GlobalIllumination/

Haven't played with those.

 

The initial release of Unreal 4 was actually based upon SVOGI..

"https://forums.unrealengine.com/t/svogi/489/24": Or here is the reason why without having to search:

"We chose to remove SVOGI in order to reduce our maintenance burden and allow us to iterate more quickly on other new and exciting features. It takes a considerable effort to maintain a complex system like SVOGI as the engine grows and evolves: every time we add a new feature or modify an existing feature we have to ensure that it works with all existing features. For that same reason we do not plan to re-integrate SVOGI in to the main branch of UE4."

LPV is still implemented into the main branch: https://docs.unrealengine.com/4.26/en-US/BuildingWorlds/LightingAndShadows/LightPropagationVolumes/

DFGI for open world GI (apparently abandoned in 4.(9)?), essentially a one bounce solution from a directional light created by EPIC: https://forums.unrealengine.com/t/the-state-of-distance-field-gi-in-4-8/29515

I've not checked out 4.26, I just saw the word GI mentioned but I shall check it out shortly. Work on your google fu grasshopper .. Also, I'm not really sure what the point of this is? Arguing for the sake of it?

Look end of the day I'm only interested in practical application, Lumen means nothing until it performs well on your average machine like CE's implementation. If it gets to that stage (and Epic doesn't dump it) then I'll get excited about it, as you said this is just a tech demo nothing more.

 

Yeah, true that. Lumen seems to be designed to run better than RTGI. I was also quite surprised it's reserved for high-end machines.

Totally forgot about DFGI, this presentation about "pre-UE4 GI". So there were many attempts, right.
My point wasn't arguing. Honestly, I already forgot on Epic attempts in this area. All so useless I didn't even remember it. I'm not an artist, so it doesn't bother me at my daily work. I see now how it was confusing for artists for all these years.

So we got 3 "irrelevant" attempts + SSGI (a cheap workaround, not enough if used alone) + DXR-specific RTGI + Lumen in UE5. Quite a lot, indeed

Speaking of LPV... well... it was just some code imported from the licensee... Saying "Unreal had LPV, it had GI" it's like saying that Unreal supports 2D. It's there but only creates confusion.
I guess it only survived so long because Epic does keep old and abandoned stuff in the engine for a very long time. LIke UE3's Matinee survived until UE5 Early Access

 

Maybe it's just me but I'm really hating UE5's excessive motion blur and shimmering artefacts. It's enough for me to not use Lumen if that's the trade off. For me it looks better for cinematics than games at present. I'm a sucker for a polished image in motion.

Also the low framerate in the editor and excessive inertia made it a life or death dogfight in the skies just to navigate close enough to a rock that got clipped by the near camera plane anyway. Tech good, but needs a lot of work and probably a better GPU than the 2070S I am using for serious editing.

 

Epic's two hour plus presentation mentions that they could have made it work with older hardware but that they deliberately chose to aim for next generation hardware. Which if you think about it makes sense as by the time you've optimized and made a game with it we'll have had one to two new generations of hardware.

Part of the reason for the performance problems by the way is that Lumen uses raytracing under the hood for part of its processing and it's currently using a software raytracer not dedicated hardware. While they mention a way to turn it on the current hardware implementation is missing the features needed by the tech demo.

 

I think unity should add something similar to Nanite in near future because I feel like it's game changer as I can make highly complex and detailed cities(like megacity but even more complicated and detailed) with Houdini and directly start using it inside UE5 without wasting time on creating LODs which would be a nightmare for such a complex scene, I can also create a huge detailed landscape or planets of millions of polygons with Houdini and later nanite will take care of it and make them run in realtime.... UE5 can literally make anything complicated and huge task which u can think of easier and thousand times faster than any other software out there and will games made with are going to hugely differ from other games

 

https://blog.unity.com/manufacturing/pixyz-software-joins-unity
Unity has acquired PIXYZ but still charging for it!!!

 

these give hope for more performance / features:
https://twitter.com/SebAaltonen/status/1407661348197175299

 

Unity digging their own hole...

 

Anyone surprised by this doesn't understand business and financials. A company that charges a fixed fee for one product cannot afford to give away all of their other software products. Epic's royalty on the other hand means not only can they afford to do it but that it's likely to make them more money in the long run due to it aiding developers.

 

Epic is in the position where they can offer 5%. I don't think it's bad. I would happily give Unity 5% if I got all the middleware free. But it's hard for a company adopting royalties to not cock it up with chasing people for it.

Epic's 1m headroom likely helps THEM too because they don't need to track a million scammy indies

Epic also offers a flat license fee you can pay but I suspect it's intended for bigger developers. It would be challenging for Unity to adopt both business models but not impossible. This would need years of preparation.

 

Epic's upfront fee is similarly priced to a Unity source license (aka: starting at five figures), and likewise depends on your project scope, team size, and target platforms. Definitely not for garage developers, but AFAIK high profile indies with some good financial backing often go that route.

The big guys (the likes of SquareEnix, EA, etc) always go for the upfront fee, it's much more convenient for them. There's also publisher-wide licenses, which waive away all royalties for all of a publisher's Unreal products. So, for example, if you develop an Unreal game and publish through a publisher that has such a license, you don't have to pay anything to Epic.

 

What kind of games? Can you show any examples? Any tricks necessary to get unity games looking better?

I always found it hard for things not to look like plastic, so I actually made my art style (for my one published game) to actually be a board game made of plastic.

 

Actually, no but I'm sure some dev's must be going for the BOTD style right?.. Although it really comes down to this, what do you think looks good? Here's a few excerpts from my project and general musings. If you think it's rubbish then maybe I'm wrong.. This we pre-HDRP mind due just some custom PBR shaders and probably so out of date at this point.

If I spent some time with HDRP I recon I could get close to the BOTD demo in terms of general quality.. Although I tend to do my own thing anyway, or I can't decide what style I ever want to go for ..


Stylistic Version:



Realistic Lightbox (or trying to be) version:



Stylistic Terrain from game:



Realistic attempt at terrain:

 

All looks fine to me. I wouldn't be able to say its one engine or another without getting scientific.

The thing is though, you had to do extra work to get these results, right? Like mess around with shaders, etc? I can respect the knowledge to do that sort of thing but it doesn't come overnight, and in the meantime I want to publish some games, hence for me whichever solution requires me to do less work to get the result is best choice.

 

Back then yeah, but nowadays? HDRP from what I've seen of it should be more than sufficient to reach whatever graphics levels you want. It really depends on your project but I will say this, no matter which engine you choose it can get hairy fast.. Work on a large / mid high (or sometimes small(ish)) high quality project without the pre-req knowledge and you'll be up a tree in an instant.

 

My trouble with the new pipelines was that trying to get multiple third party assets to all work on one pipeline was impossible. And I had to rely on third party assets for a realistic, large forest world in unity.

So far I've stress tested the project in unreal and don't hit the same pinch points. And I haven't needed to buy any tools. I've also been able to do most the coding with blueprints. If my games world could be sized down I might have stuck with unity. But the gameplay actually depends on map size, so there isn't room for compromise there.

I am only just learning to code with blueprints but i've made a couple prototype games and so far it seems like I can avoid most problems so long as I keep scope simple and stick to tried and true methods. I also have to consider workload involved in projects because I dont see myself hiring a lot of help in future. So probably I stick to single player shooters and just iterate on theme and game feel principles, rather than trying to create something novel or complex.

In short, for me unreal and their blueprints makes for a more beginning-coder friendly environment, whereas Unity necessitates that I have more like expert level of knowledge. And even if I do, there is still the issue of having to build so many tools from scratch, and how much time does that take?

Also about the shader graph and all that... well it's new. I just dont trust it. THe thing is, if something is a little buggy, I won't know enough to debug it. It's really difficult for a beginner to learn if the tools aren't trustworthy. But with the material graph and blueprints in unreal, they've been around for awhile. Any issue I face is always user error and I can find answers fast.

When I was working on a project in unity, a guy was trying to teach me how to use map magic (older version). I was trying to figure out how some nodes worked just by turning off and on. But the thing had a bug I didn't know about, so I wasnt able to make sense of what was happening. Pretty frustrating and waste time.

That's the main reason I insist on trying to always use the best, most mature tools. Because I am not an expert. I need experts to guide me.

 

It's simple as this, Unity is not nor probably will ever be in the same stratosphere as Unreal (even with bolt-ons) in many area's not just graphics (as in performance) in regards to 3D games. HDRP is just another example of several other area's that need asset store help, although this has been the same since I first picked up Unity in 3.X. The ethos is very different in Unity, they create a partial toolset so everyone can do anything under the sun with it. Epic create tools that work on practical 3D games that covers most (not all) scenario's and aren't reliant on several teams of coders to finish it off.

Although all I am saying is UE isn't perfect.. Recently on a test upgrade path for a work project, all the plugins stopped working, you couldn't cook the game as it caused a memory leak and crashed the editor / process half way through. Now let's say for most other projects it's fine and Epic can't be bothered to fix it. What do you do? Of course we had to delve into source and fix it, this is just one example of many. After we fixed the issues some of the features didn't work on export.. *Sheesh.

Again the rate of iteration in UE is just insane, great for those who love shiny new features but not for those who just want to make games. If you can find a more stable version that does everything you need then you are laughing hard.. I don't want to parrot myself but the main things Unity have are Enlighten and C#.. Lightmass looks great but it is a PITA at times.

In conclusion you either asset store or roll your own in Unity (which takes time and a lot of experience) or hope to whatever you don't come across an issue in UE.

 

Yeah always this big risk.
I think for myself best way to manage is keep projects to six months or less production time, and simple enough that when I ask a question most anyone could say, "yeah that's been done a million times. Did you search the forums?"

 

Wait a moment I recognize these sample prototype, is zarconis our old pal shadowK?

 

It is a hackweek project so I am assuming that it will not be implemented directly inside the engine and we might get it on GitHub like the Auto LOD project like this
https://github.com/Unity-Technologies/AutoLOD

 

You know I re-read this and had a flash from the past when I started using Unity, this char controller talk on another thread was a prime example. I created a top down controller in like five hours flat (as a tester), it was just a point and click script w/ a char controller driving the physics (easy) which was nice.

Then I moved onto a third person controller which required a lot of things, NPC interactions, world interactions, combat, multi-zone collision detection for parts / angles, AI etc. and I had a whale of a time. I moved from Cryengine, XNA and custom built solutions of all things, it should NOT have been this difficult to get a half functioning TPC + camera.

I used the Physx char controller to drive the third person mesh and it didn't work right in quite a few scenario's, tried Unity's examples which were worse than mine, reached out the asset store to see how they approached it etc. and there were still issues galore, jitter, AI not doing what the documentation stated etc.. So I lost a lot of time there, then I moved to a custom built rigidbody solution that also had issues galore.

I reached out to hippocoder, the community etc. etc. and I couldn't get a clear answer on the issues, through a lot of custom work, trial and error I finally managed to get something half decent working but still. What I essentially had to do was bypass Unity's AI and Navmesh system which inflated the cost of development several times over. I'm not saying that I couldn't have make some N00B mistakes but we were a month in at this point, in UE it was 2,500 lines of code in the deep depths of C++ to do all of this and it worked exactly how I'd expect it to.

Moving on from the controller most of the asset store stuff I tried had too much overhead for a game my size or wasn't "ready" for a production game shall we say. I know there's a lot of great asset store devs but in Unity there's a lot of area's to be filled like you specified. Also the most popular supported products seem to have specific design ideals in mind, I'm not interested in procedural terrains for example.

I am heavily considering Unity because I like their rendering and lighting side, the BOTD grim side and Heretic demo is exactly what I'd go for in terms of style and also writing a GI solution like Enlighten is just a no go. I'd even consider trying to wall off my open world game to make it easier on the engine.

In summary though, the reason i'm still um'ing and arr'ing is because in Unity I spent 20% of my time developing the game and 80% finding my way around issues, fixing up asset store stuff to work with my pipeline or finding new and inventive ways to bypass Unity's half baked internal systems. I'm not sure if it's worth it TBH..

 

I don't have near so much experience - I started making 3d art in 2017 with practically zero computer experience before then - but after making 1 1/2 games in unity (art only, no programming), and now having spent a couple weeks working in unreal, my thoughts are similar.

A couple weeks doesn't sound like much, but in this time (most of it spent follwoing beginner tutorials to learn blueprints) I have coded more than half of a project that I spent six months working on in Unity. Now that's not a 1 to 1 comparison because much of that time was spent iterating on art and such, plus I was working with another developer and communication time does slow things down, but still... we spent most time and energy building tools to support the large open world, and in the end we couldnt get past some engine level memory related bugs. But in unreal these problems have in built tools to solve them, and performance is night and day better.

The biggest plus though is that I am a total moron who gets cross eyed looking at code, and here I am with most of the functionality built for my game with less than two weeks of training with blueprints. That's real empowerment.

Unity is what it is and that's fine, my only big qualms is how persistently it is marketed and believed to be the indie engine of choice. Perhaps more indies would find success if this was questioned more often?

The way I see it, Unity is a blank slate and you got to rebuild it to suit your needs. That's fine.... for experts, or for teams with real money and very particular needs.

I think for the basement dweller who just wants to make same old same old thats been done a million times but this time with their own personal twist, it's better to have a complete, polished toolset, no? I can adjust myself to the recipe so long as I know it's a good one. But I'm no chef, I have no business trying to do everything scratch. Nor do I want to. I just wanna make the games and play them and watch other people playing them and having fun. I like to spend my time iterating on experiences, not building tools or solving dependency puzzles.

Based on my experience trying to make an open world in unity, I'd say forget about it unless you are able to make a stress test for performance pretty quickly.

 

Blank slate's defeat the whole purpose of using a commercial engine (unless it's some out there project).. Also do you know what's harder than starting from scratch? Reverse engineering someone else's work, especially if it has been in dev for 20 years w/ hundreds of people working on it. Plus framework style engines are light weight and allow full control of every component, that's probably why Bethesda, EA, CD Projekt etc. use their own. Buying a source code license to then mould it to your own specifications wouldn't make financial sense in a lot of cases, how long has it taken Unity to get where it is?

A, AA and AAA don't usually waste money for no apparent reason, well unless you've got Tencent sort of money. Square Enix probably used UE4 because it was right up their alley, why roll a solution when something has everything you need? If you're in a team of <10, experienced or not forget about it.. You need a well thought out / well equipped base to work off of. I agree with @hippocoder in the general sense, Unity is best at small 3D, VR, mobile and 2D.

Still, it doesn't mean you can't create an "open world" game dependant on one's definition. Even Skyrim had loading zones. I could solve most of my performance issues by simply walling off my game into 1 / 2 KM2 blocks and then loading the next zone.

Ultimately though I always feel like I'm shoehorning Unity to do what I need it to do despite liking so much about it. Although I might give it another go?!

 

True that.

And that.

Took me awhile to figure the second one out even though my intuition was guiding me there.

Just by chance when I started with 3d art I chose maya cause I thought I might want to work at a studio one day and it seemed to be the standard. I have nothing against blender or it's weirdly cult like followers, but when I see all the issues over and over they face, like so much trouble to export and import models, poor rigging and animation tools, dependency on plugins to do basic stuff... it makes me glad I use the million dollar software day to day. How much time is wasted when you use less efficient tools? I think the $200 a year I spend on indie license is going to be paid back once I sell my next game, and who knows how much time and headache I've saved just by using a more mature software.

Anyway, that's my general mindset. Because I am a indie basement dweller, that doesn't mean I should use the cheapest and lousiest tools. I need the best, because I am doing an entire teams worth of work. Anything that saves time is worth it.

 

There are plenty of big games made in Unity, but my context is from the smaller developer, which makes up most of this forum's active posters. The big games in Unity have a fair bit of money and teams behind them, so that they can make the tools themselves and solve all the problems.

I think Unity is capable, I just wanted to clarify it's out of the box tooling (including package manager content) is suited more to smaller titles and mobile.

 

Yup, exactly.

Plus if you actually make things from scratch, you gain usable experience and knowledge, while working around Unity features what you learn is how to work around something someone sloppily coded years ago, that no one has bothered to touch since, that will eventually become obsolete.

 

There is? The only one's I were aware of were PAMELA and Escape from Tarkov, the first has issues and the second hasn't been released yet. https://store.steampowered.com/app/427880/PAMELA/

 

Subnautica is Unity. According to Linkedin the studio has 11-50 employees which is the same as for PAMELA.

https://store.steampowered.com/app/264710/Subnautica/

 

It's cool but not in the silly scope game made in Unity category. Reason I ask is it does add a sense of relief if others have done X and you're not the one wondering into the wilderness staring up at the skies starry eye'd as the "first" to really have a go.

I'm honestly not being facetious, there's a comfort factor when the greats produce games of a similar style (also they usual have articles on how they achieved it). I haven't seen a Witcher 3 or even a Skyrim in Unity. Not even on a much smaller scale..

On the flip side, you do get extra kudo's for making it work.

 

Both games were also not made in Unreal Engine. But at this point we're so far into AAA territory there is no discussion to be had without huge teams so it's completely useless.

What can be done with smaller teams?

 

I suppose the only way to really know is to do it again and devlog the experience properly this time around. Although due to experience I wouldn't approach it the same way, so it becomes a bit of a moot point.

The main practical difference from my experience yet again, if you can manage to demonstrate a project that punches well above its weight and you start having issues Epic will thrown you on to UDN / offer some support (usually). Now, I don't have a clue how Unity operates in those regards? If I hit the ceiling, then what? Don't get me wrong I have "had those days" and asked Epic some embarrassingly stupid stuff but they were helpful nevertheless.

You can always tone down a project but getting out of invested eco-system is difficult..

 

Good luck.

 

"It might get fixed in DOTS in the next 100 years"

 

yeah, but all have access to source code and have heavily edited it, every time i hunt one of those, i found that the problem i had was not solved in a way i can ....
Like Zarconis I killed a game because there is no way I can make ultra precise controller I need, I do want to make open world game but all my research lead to no no land, huge simplification or code edition. I mean I'll still try, but unity is more to explore concept, and given the amount of time I sunk into work around I should probably only prototype on unity then literally port it to something from scratch, because as a mere designer, I had to go so low level to understand things that I probably don't need unity anyway, because i have been as good as implementing stuff myself so far.

Unity is good to make unity game like the team without source code, if you don't see a game already made like that, don't assume you can period.

 

You sure? I don't think Rust does use a source license, nor does The Forest, although Forest is a far smaller team that began with playmaker of all things.

Source licenses aren't really necessary unless you want to strip a lot of Unity out for some reason, and the reasons to do that are significantly less with SRP and modern updates to Physx. It sounds like I'm playing Unity's tune here but SRP really is reducing the reasons to get a source license.

One of the main reasons to get a source license historically were outlined with INSIDE. That game just couldn't get good streaming going without considerable effort.

Unity has a lot more work to do in streaming and so on, but AFAIK they aware of it and we can still design around it. A smaller team will have vastly less reason to stream because smaller teams simply can't manage that many assets that force streaming to be the main focus.

With some compromises, I don't think any small dev needs a source license right now.

 

Rust most likely doesn't use a source license, garry mentioned the fact they didn't, and don't want to mess with the inside of unity unlike the rust console port, where they had to do it to get it to a playable state on console I believe. The comment is somewhere out there, was recent since it's about the console port.

 

Ori And The Blind Forest is known to have used extensive source modifications to achieve rock solid performance and stutter-free streaming.

Even with SRP, there are still major black boxes in Unity which you cannot work at all, or at least not without making entire systems from scratch. From my experience:

- Asset loading and streaming. You can create meshes and textures directly, but we don't have the means to upload/update their data asynchronously like Unity does internally.
- Everything involving GameObjects and MonoBehaviours (serialization, memory management, initialization).
- Camera and shadow culling: you cannot manually produce a CullingResults to feed SRP, those are only generated in the C++ side. This means any custom culling solution has to settle for disabling/enabling renderers in the main thread.
- The entirety of the terrain system (but you can work around it by not using any of it and recreating the whole thing from scratch, which should take a couple months depending on what features you want to have).

Things get a lot worse when you're working on consoles and can't brute force through inefficiencies by upping your game's recommend specs.

 

Also team that bypass unity internal by using dll and treating unity as a graphical engine

 

There's tons of ways to async load in Unity: https://docs.unity3d.com/ScriptReference/30_search.html?q=async+loading / https://docs.unity3d.com/Manual/StreamingAssets.html
Level load async / asset bundle streaming, as I said in my other thread the issue is its effectiveness, I still got stalls and micro stutter which shouldn't happen if used in a specific way.. It doesn't in UE anyhow.

Full description here: https://forum.unity.com/threads/unity-flax-ue.1130116/page-2

I will say the terrain system is interesting, the frustum culling overhead in general is rather high and dynamic occlusion is a necessity. If I use a single tile and a bit of pre-loading no issues it's when we get into a multi-tile setup things start to get interesting.. Can't remember the exact specifics but it wasn't exactly useable performance wise.

Well I suppose I could have released it with these problems like some have but that's not my thing..

@hippocoder

"With some compromises, I don't think any small dev needs a source license right now."

Please explain because given a month I can have any engine writhing around saying "no more please", it's not all that difficult to do. I find the limits and then work backwards to hit a specific minimum viable target by heavy optimisation..

 

It means there are many games released using Unity every single week without any problems. Because the problem is between chair and keyboard.

Now I could demand Unity render this huge planet, or even a city and when Unity fails to deliver, it's obviously Unity's fault and not mine because I didn't tailor my approach to Unity's strengths and weaknesses.

Unity is lacking in a lot of areas but if you understand those places and compromise, which I said in the post you replied to, you won't have many problems. This does mean scaling your game down to suit how much work you're willing to do on top of Unity's baseline.

Example: I can do an open world giant game in Unity but I'm not willing to put in the extra work involved in getting it all streaming. So I use less unique meshes and put the burden of streaming on textures, which Unity does very well without problems and without much if any tooling.

So the compromise is everything for the indie.

One final point: you can't test streaming in editor unfortunately, only builds. The editor overhead and management is enough to make it stutter regardless.

 

@ Zarconis, you sure thats not shader variants being generated? Most issues I've had e.g. with async sceneloading as been due to shaders not being warm.

Personally, I don't really care what AAA games have been made with Unity, its a poor measurement on what I can do in the engine. My focus is, what can I make in Unity. Single developers mainly rely on the engine or assetstore to provide most of their tools. Its not just a matter of skill, but that of time - the main reason we use a general purpose engine in the first place.
Its like the ancient Maya vs 3dsmax discussion. Yes, ILM and Pixar mainly use Maya, they have 5 gazillion tools engineers - do you?

If Unity released source access tomorrow, I would be the first to cheer and dance. That said, I doubt I'd be able to maintain a custom branch of the engine while also making games.

SRPs! I'm sure its amazing, but how many indies are going invest into owning their render pipeline? Even larger companies seems to use the prebuild SRPs.

Same goes for Unity demos, which showcase what it can become with enough engineers and time at the helm. Unreal showcase what the engine is.

Unreal

• Stock engine.
• High quality assets that work using stock features.
  
• Access to full project, thats even maintained between versions. Their elemental and infiltrator demos where keep up to date until 4.24, thats like 6 years!

Unity

• Custom branch? I'm assuming its one of the reasons they don't release the projects anymore. Tons of custom tech of which we have zero access.
  
• High quality assets that likely use this experimental/custom tech.
• Zero access to project. With everything being so versions locked, brittle and experimental - its almost pointless either way. Bling bling at the shareholders, and down the trash - wasted opportunity.

If facing the same direction as Epic, it hard to deny the amount of tools and features you'll get for free using UE. What scares me is getting in over my head on the C++ side of things.

 

Fully owning, no, but modifying, a lot.

The problem is that the SRP as a system, instead of having high tweakability, which appeared to be the goal a few years ago, where we would be able to have a very simple high level render loop script, that we could add and remove things to, at some point they changed their goals and now it's more "own the whole pipeline or use as is" kind of deal.