In T67594#734256, @dark999 (dark999) wrote:

i tried to give you a trick to mitigate eevee's fallback for large scene

In T67594#733867, @dark999 (dark999) wrote:

disable the LoadUI option when opening the file

it work?

That overlooks the issue of Eevee crashing, though, which is my primary concern here and why I reported the issue. Silently crashing without any guidance to help the user seems like a bad thing. There's zero reason for the user to try 'load UI' when faced with a crash like this. Could the Eevee crash be caught and Workbench invoked as a basic level 'try not to die' mode?

@dark999 (dark999) : the test scene attached is small and focussed purely on illustrating the fallback to Eevee rather than Cycles. You won't see any errors from it (or at least should not do). For my larger scenes that were built in 2.79 (often with side-by-side configuration for Cycles and V-ray), loading those set for V-ray will fall back to Eevee in 2.80 rather than Cycles, and Eevee can't handle the amount of data (it seems).

No idea - screenshot attached, in case useful.

I do, but the scene is too large to make a practical reproduction case for the bug tracker. I had complaints for 'too large to be useful' before, so don't want to make that mistake again. The UI is blocked as Eevee is attempting to compile shaders, and I have no way to abort either that process or to change the renderer. The viewport is configured to whatever the fallback is in this case; I'm not actively requesting a render or a render preview in the viewport, and as the UI is blocked, it's impossible to change anyway.

The issue with Eevee, from the point of view of large scenes, is that it might simply fail due to the scene complexity, and it's unfortunate that its failure crashes the whole of blender. Falling back to something that isn't intimately tied with the GPU (where resources might well be constrained) seems like a safer strategy.

OK. So here's a simpler example, which demonstrates the same problem. The only difference is, again, the negation of the values from the transform("object", P) call. This fixes the texture projection (for the most part). I think this is as simple as it can get.

OK. I didn't realize that the time saving was that significant beyond throwing a sphere in; I'll bear that in mind for future reports and apologize for the aggravation caused.

Again, I cannot save a blend file because blender instantly crashes when loading the EXR. I get that you're frustrated and consider me to be a contributor to your situation, but I'm genuinely not trying to piss you off here - blender crashes on loading the image. There is no window of opportunity to save a blend file.

I'm not sure what the objection is. Providing a blend file is not helpful here - the crash happens loading the EXR image in. I've supplied PNG and the resulting EXR file so that the crash can be better understood (PNG is not crashing, EXR is). Steps are provided. Release information and OS/graphics card information is provided.

Indeed. I'm just offering additional background to help any decision from Brecht at this point :)

For additional background, I ran into this following Brecht's advice on devtalk about how to workaround the UV map per object limitation; I went through renaming the UV maps on each object (prior to joining the meshes together) and all of the surfacing broke (since I'd made an explicit reference to each UV map in the surfacing). It was a fair bit of work to fix this up, so it felt like a bug (lack of notification or something)

Ah, that works. There's a different issue (multi-selection of objects, and 'add to group'). I'll file a separate ticket for this - I guess it's not related to this specific case.

Is this supposed to be resolved in the 2.79 code? I'm still seeing this behavior in the current nightly builds, so wanted to check

Indeed the build from today seems to be fine.

It's reporting as 2.79.3 in the header, so I thought this was 2.79b; I'll ask them why their labeling is misleading. Apologies for the noise.