Gentle nudge for review :)

Is master in a position where this could be merged? :)

Just wondering if the proposal and differential make sense now and could be signed off

Simplifying UI per feedback.

So how about this:

Just wondered whether any of those suggested labels might be appropriate.

Apologies for the confusion; I was thinking at the individual X->R, Y->G, Z->B level, not as the whole 'vector' - too close to the tree to see the forest. I've tweaked the description to better describe things. I'm very open to whatever label is appropriate and clear. I can live with curvature, but there is an aspect of rate of change to this as well so it might need to be indicated that this is also a rate of change / velocity.

Here's an overview video showing why the terminology is open to debate. The eigenvalues come from the mathematical representation and the minus and plus are essentially complementary. I can't really think of a good general name for this, though, in terms of what it represents. It could be labelled, I guess, as spray veolocity, but there's no spray as such without a particle system, so I am uncertain. The underlying equation is a combination of wave folding and collision.

Python indentation reverted prior to diff being generated. Fixed.

The debug suggests an addon is responsible. I'll close this as invalid given the debug output; thanks for the pointer to that - I wasn't aware of its existence.

Could this land for 2.83 or will it come later?

Any remaining concerns?

Changed names and descriptions per feedback.
Moved common JONSWAP code (shared between the JONSWAP and TMA choices) into a static float function 'jonswap'. The difference between the two is thus more apparent in code.
Simplified the calculation of the damping across all of the models.

Request review again based on the comment regarding names/descriptions. I tend to think the existing approach is more user friendly compared to tooltips.

Enum typedef removed
Changed enum names to separate whole words with '_'
Moved static up in source file, removed from header.
Added license information to new header file.
Added guard to new header file.
Added doc block to header file.
Added full-stops to new comments per feedback.

Is there anything pending that I overlooked in the requested changes?

@Joshua Leung (aligorith) : I ran into this again recently with 2.82/2.83 code. Is this something that might be discussed, to see whether the animation data could/should be retained for the copy?

Adjusted names of functions per feedback.
Abbreviated Apache license.
Moved struct to a dedicated header file.

Moved apache licensed code to ocean_spectrum.c
Changed names to suggested values.
Hopefully fixed comments to use required convention.
Added some more comments to better explain 'fetch' for the JONSWAP model.
Made UI spectrum show guidance about the spectrum itself.
Removed obsolete 'surface_tension' float.

Addressing nitpick for spacing, using make format to check

Changed to use blender's hash function (I went looking, but somehow missed it originally). RNG approach changed per guidance.

Using blender's hash function with parameter scaling. Changed RNG approach to change seed of existing RNG rather than initialize a new RNG each time.

Used macro, changed comments to fit style guide.

Looks OK here with the buildbot 2.82 on Windows from Jan 20. It does seem to need more memory than is available on most GPUs (~ 8 GB or so) so the performance is hurt, but the tool no longer crashes or throws an error.

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. This is during the load; shortly after this, blender just exits silently to desktop

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.