This was written with the intent that it would work with the upcoming particle system overhaul. That work was postponed so the spray vector maps aren’t immediately usable within blender for driving particles.
The idea is that each channel of RGB drives velocity in XYZ. These velocity representations come directly from the Jacobian inputs to the foam. I left the option for complementary in the spray because it was not immediately clear what would work best with the particle system when it arrived.

No worries - it's all good. :)

@Hans Goudey (HooglyBoogly) : I'm not sure how to do that without polluting the cache and/or result in order to track the spray usage (and even foam usage). It looked messy, so I opted to simply go-with-the-flow. This also makes it less awkward for reloading the baked data - I just get what's there and map it in identically to the foam. It's quite a naive approach, but seemed less problematic.

@Hans Goudey (HooglyBoogly) : Just nudging this in case it can fit for 2.91. If not, no worries.

Fundamentally, what I'd like to do is to link the camera and render properties between scene copies. I'd hoped the 'linked copy' did this; hadn't realized it was collections-only at the time. There doesn't seem to be a way to set up drivers to tie scene camera, etc. together across scenes, though.

@Hans Goudey (HooglyBoogly) : Not sure about timelines. When might this land?

In D8470#208975, @Hans Goudey (HooglyBoogly) wrote:

I can't really speak to the utility of the feature, but considering it's basically the same as the foam maps I'd say it's close to there. Two things:

1. Even though the existing code uses short for the do_spray variables, I think this should probably use bool since it's new code.

@Hans Goudey (HooglyBoogly) : Just curious whether you think this is fully baked (ha!) or not as a patch.

@Hans Goudey (HooglyBoogly) : I rebuilt from scratch and it worked then. Stale parts of the build, I guess.

@Hans Goudey (HooglyBoogly) : Your fix didn't seem to resolve it for me here.

From poking around, it looks like it's the copyData code that is breaking things. I originally thought the use of viewport_resolution would be fine, but it looks like the render pipeline doesn't cause a re-evaluation and re-set of the resolution. I don't have the flag to capture the situation elsewhere, so it drops through the cracks.

Hmm. Indeed caching looks like it needs additional work to implement. Not sure how beneficial that might be, though. As little thought as I gave to caching, I'd anticpated people caching the particles rather than the maps responsible for them. I haven't really made any use of the caching in the ocean modifier; some idea of how prevalent this workflow is and whether caching of spray maps would be useful would be welcome.

@ronan ducluzeau (zeauro) : Per the original differential, 'Assuming the particle system was capable, for example, the eigenvectors could be used to drive spray emission velocities.' It's also not exactly related to the displacement or foam intensity - this is more about an implied surface velocity (of two or more waves coming together, resulting in spray). I used the same approach as foam to offer compatible workflow with foam/displacement exports until such time as the new particle system matures.

Hopefully this is what was asked for. Changed the property names and removed the overrides for the UI.

@Hans Goudey (HooglyBoogly) : would you be able to find time to commit this soon? :)

@Brecht Van Lommel (brecht) : when would this be merged for 2.91? I know 2.90 is the focus - this isn't intended to hassle, just curious.

Just curious - missed the cutoff for 2.90 or still a chance?

I couldn't reproduce the crash. I wonder if it might have been arising from the misplaced versioning code. If it still happens with this patch, could you supply the blend file?

'make format'

Moved versioning code into the correct place (possibly this caused the crash Hans reported).
Fixed up the without-ocean-modifier function to take the additional resolution parameter.
Fixing up the UI entries (hopefully, although I find this part of blender's code to be rather confusing)

@Hans Goudey (HooglyBoogly) : anything left for me to fix up here?

Tooltip and label updates

No crash here with a file saved from blender 2.83.

Here's the rename and grouping work for the UI. Padding also removed. Hopefully this ticks all the boxes.

Renaming per earlier feedback, remove useless padding

@Hans Goudey (HooglyBoogly) : does this look cleaner to you?

Finding a way to handle older scenes. Still WIP, pending renames (at the very least)

An ugly workaround would be (in BKE_ocean_init_from_modifier)

I can of course abuse the versioning system to set ocean_resolution on-load; I'm just not clear yet on the code flow that means the doOcean is not called to set this as I would have expected.

Versioning

In D8336#202737, @Hans Goudey (HooglyBoogly) wrote:

The terms we usually use are "Viewport" and "Render" resolution, I would be consistent here.

For getting old files to work, check in the versioning_290.c. I've already done some versioning there for the ocean modifier there for 2.90.

Something like this should work:

if (!DNA_struct_elem_find(fd->filesdna, "OceanModifierData", "int", "viewport_resolution")) {
  for (Object *object = bmain->objects.first; object != NULL; object = object->id.next) {
    LISTBASE_FOREACH (ModifierData *, md, &object->modifiers) {
      if (md->type == eModifierType_Ocean) {
        OceanModifierData *omd = (OceanModifierData *)md;
        omd->viewport_resolution *= omd->resolution;
      }
    }
  }
}

Change from gen_spray to use_spray per feedback

@Brecht Van Lommel (brecht) : I was using gen because this really generates the map rather than 'uses' it; I find 'use_foam' misleading in that sense. I can change it for consistency, but the modifier never really uses these properties; they are used elsewhere (the modifier generates the data)

@Hans Goudey (HooglyBoogly) : is there anything pending? I think your comments are already addressed, unless I missed something. Hoping to move this forward through review. :)

Just following up again - not sure there's anything pending here for me to change.

The layer data names should already be consistent. I opted for 'generate' rather than 'use' for the spray, as the spray map is generated. It's not actually 'used' by the modifier, so I always felt 'use foam' was wrong - you have to use it somewhere else.

Hans, what do you think? Is this OK from your perspective?

Continuing feedback

Responding to feedback. The uninitialized warnings are meaningless - the variables are defined at outer level for scope, but only used in the conditional blocks where they have been initialized. Not sure how this ought to be handled.

Last attempt went wrong somewhere. Here's an updated diff responding to the modifier UI changes.

Reworked to respond to recent modifier UI code changes.

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.