Constantly Crashing on Layout Systems

Hey I'm trying to bake a rather large scene and anytime I get to layout systems the editor crashes. I cannot figure out why and I can't find anything relating to the issue. Also curiously it doesn't come up with the typical unity crash where it suggests an error report it just says "Unity Editor has stopped working". I have baked the meshes in my scene using a mesh baking tool and it is only when I try baking those that this occurs. Maybe It is something to do with 10k+ objects being compressed down into a couple hundred I really can't say. Perhaps somebody with a better knowledge of this subject could shed some light?

I just tried it again and it gave me a memory could not be read error.

 

I dig up this post because I'm facing the same issue with Unity 2019.3.0f6 + HDRP 7.1.8 on a fairly large scene with DXR.
Unfortunately, due to large scene volume I think, the bug reporting is not working (connection closed systematically on bug report).
Quite annoying...

 

Hi,
I just tried but unfortunately I get the same result "Connexion closed"

By the way, I think the issue comes from the (very) big project volume (nearly 10 Go). At the end of the upload, I get the message. I have a fairly good connexion (512 Mb) and the upload is done in a few minutes, but no luck.

Here is the crash issue:



I tried to disable every gameObjects and tried to re-enable them one by one and let the process finishes between them (create geometry, visibility, layout system...). Although it's a loooot time consuming (which is quite unproductive for realtime raytracing...), it worked for some times... and crashed again. Now, I cannot reopen the project without flushing the entire library folder because the crash occurs at the project opening.
I think the DXR is far from being ready to be used for anything else than a few objects and some gadget scenes. With more serious scenes, it cannot yet sustains it.

 

Hello,

Yes, I agree this is not logical from my part. But if I do what you advice to do, no light is bouncing off.
I though GI bounces was due to DXR, but it seems not indeed. That's obvious.

No problem, it was just a test of the DXR features. I give up on this for now.

By the way, let me digress and formulate a critisism which I believe is shared by a lot of developers like me: the GI in Unity is more and more messy to understand. Is there any way to make it just work as expected ? without crash, without inconsistancies, without fiddling with dozen of parameters just to setup basic GI ?
With time passing by, it seems that a lot of GI features coexists. A lot are outdated and not supported anymore, and some are still in beta...
But nothing in GI actually works as expected, and nothing has ever worked since then.
As far as I'm concerned, since GI has been implemented in Unity, I've never been able to take an old project, and modify it without being obliged to update it drastically to the point of redoing everything related to lighting (not to mention AR or VR). In a word : it has never worked consistently.
(Even the bug report is not working in this case !)

And now DXR is coming up, not to simplify things.

This should be simple shouldn't it ? Yet, it is not without juggling with different techniques that are ether outdated, either not working, either not compatible.

I'm a 44 years old developer and a skilled 3d artist, and I don't understand this way of reseting everything every couple of years. Unity developers should incorporate basic profitability principles. Actually project maintenance on a basis of two or three years old is just a pain (Not to mention projects of 5 years or more that need to be practically completely redone). For some of my clients, it's a terrible brake on investment with Unity.

Sorry for that blow of anger, but I'm a bit tired of Unity's mess.

 

Hi,
I 've pointed out the bad sides, but there are good ones of course.
The good things (of Unity GI) actually for me are :
- The increasing baking speed wich is a very good thing for productivity.
- DXR : even if it's on preview stage. This is very promising.

What I would like to see in future (glad you asked me) :

- A possibility to incorporate baking light data (or realtime ones) in prefabs, so they can be downloaded on the fly from let's say an online database with addressables package for example. That's an issue I'm regularly facing on.

- Less parameters for "basic" GI with of course the possibility to tweak them if needed. The preset system is a good base for that kind of feature I guess. GI is not an easy task to configure. But I would be inspired by unbiased rendering software such as Maxwell render, Maverick... just and idea. I know Unity is not and unbiased render engine, but the way of fiddling with parameters on those engine is quite intuitive and simple.

- HDRP (and in a way URP also) is kinda messy also. There are parameters and presets, and ways to tweak them everywhere. Why not merging everything in a unique place ? (graphics, quality, srp presets etc...)
Not a big deal, but failing to make the parameters less numerous (and I realize that it is difficult without sacrificing flexibility), this would make the configuration a little simpler by centralizing things.

- Since there are many depreciations (code and features), why not tag them with a specific color and tell the way of doing ? Actually, this is done in a manner for the Unity engine API. The depreceated methods for example (not always the case unfortunately), indicates the new method or property which is replacing the old one. Depreaciations are very annoying (for project maintenance mainly), but it is far more time consuming when you have to spend hours finding another way of re-doing what you did in seconds before.

- Please do not give up AR/XR packages as told here. From my point of view, this is a very bad move. Many of my clients are upset from this news and told me they eventually plan to switch to Unreal. Actually, the XR packages are a bit messy (so as the packages system). Why not renaming clearly them and eventually merging them (if possible), and making a subfolder system in the packages. Every packages are placed on the same level. There is no classification (for example "AR/XR" which would gather all AR/XR related packages).

- One problem I do have (and I'm not alone) with SRP beside it's complexity, is the impossibility to switch from a SRP to another. For example, I developped a project (not necesseraly a game) with HDRP and my client is happy with it and want to develop a lower quality version (of course) on tablet or smartphone. Doing this implies to reset all the project for a new platform with URP.
The cost of such a move is tremendous : The developement is nearly doubled, and the project maintenance cost also.
I don't know if a converter would be possible or any possibility to switch from a SRP to another.

- The timeline system is a very good system but not very intuitive to extend. In fact the timeline system is a base which is good (not perfect but good), and far from being complete. So, the user had to finish it himself. I'm not against that but please, make the extension easy to do without having to create classes everywhere.

- That leads me to a more higher point of view : Since Unity switched to subscription mode (which I was against, and still be), It's the race for new features which, for the most part, I have no use for. I would prefer to have

 

a more stable engine with robust and consistently features.
Unity is not the only company to do that, and I understand the urge to sell sexy new features is more attractive than selling bug fixes...

Sorry for being so long (and not exhaustive), but I grasp the occasion to let Unity know what I'm facing everyday from my experience.
Maybe not all of this are good ideas, or being feasable... I realize that developing such a complex engine is hard and difficult... so as responding to every publics (from the big company to the indie developer).

Anyway, thanks you very much for reading me.

Hope this would help a bit.

 

I understand the complexity.

Light is not necesseraly a good example for lacking of "evolving infos", but since I use Unity for more than ten years or so, when beast was abandonned for enlighten, I knew what beast was, and what enlighten was... and wich one replaced the other. So no problem. But for someone who was starting with Unity at that time, I guess this was very confusing to see at least two lighting systems. I had to explain my students why there was two lighting systems, and why the (not obvious) new one wasn't working better than the old one. then came Progressive lightmapper (CPU, then GPU which is not working). I guess DXR will add more confusion. A lot of people will wonder why DXR is separated from the next "new" lighting system.

This is also the case for animation (animation, animator, mechanim), for particles (legacy particle system, then shuriken and now VFX Graph), for video (movie texture, video player), for UI (old GUI system, then UGUI, and Text component which now coexists with TextMeshPro components), AssetBundle (after a long and painfull evolution is now depreceated for addessables), API also (WWW recently replaced by UnityWebRequest and don't know really why for example)... just to name a few.

All those "resets" make the engine very confusing. And I think that might be very difficult also for Unity developers to have to let an old system be for a while, while adding a new one and make them coexist... (manage incompatiblities,errors, and updates...)

By the way, prefabs and Audio mixer are good counter examples. The recently updated prefab system has just evolved from the old one. So as audio mixer. This was complementing the already present audio system. Nothing was added to compete the current feature, nothing was removed with pain/time.

Why not "evolve" old features, for example particles, to keep just one particle system which is backward compatible with old one while adding it new features.
I guess it's impossible (because Unity would have done so) because the systems were drastically differents and incompatibles.

I think Unity is really a good engine (I still use it !), but I feel there is no middle or long term plan concerning features development and backward compatibility. In fact, I don't see any backward compatibility since, each time, a new feature comes to double the old one, and the old one is some times later abandonned.
So, for an old project that use those depreceated features, that's catastrophic. For developer and client that rely on them, that's a costfull pain.

That's what affraids me the most about Unity after all. Now, I'm very reluctant to jump (for production) to new "features" because all Unity history from those past 10 years tells me this feature will very probably be full of bugs for years, then abandonned abruptly because of long wanderings, and finally replaced by the same resetted feature... and the cycle goes on in quest of very costly perfection.

Thank you very much for your concern.