- User Since
- Apr 12 2018, 4:20 PM (171 w, 1 d)
Jun 7 2021
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.
Oct 21 2020
Oct 20 2020
No worries - it's all good. :)
Sep 28 2020
Sep 22 2020
@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.
Sep 10 2020
@Hans Goudey (HooglyBoogly) : Just nudging this in case it can fit for 2.91. If not, no worries.
Sep 7 2020
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.
Aug 21 2020
Aug 19 2020
@Hans Goudey (HooglyBoogly) : Not sure about timelines. When might this land?
Aug 16 2020
Aug 14 2020
@Hans Goudey (HooglyBoogly) : Just curious whether you think this is fully baked (ha!) or not as a patch.
Aug 5 2020
Aug 3 2020
@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? :)
Jul 27 2020
@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.
Jul 22 2020
Just curious - missed the cutoff for 2.90 or still a chance?
Jul 20 2020
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?
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?
Jul 19 2020
Jul 18 2020
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)
Jul 17 2020
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.
Jul 1 2020
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. :)
Jun 26 2020
Just following up again - not sure there's anything pending here for me to change.
Jun 24 2020
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?
Jun 19 2020
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.
Jun 5 2020
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.
Jun 2 2020
Apr 23 2020
Gentle nudge for review :)
Apr 15 2020
Is master in a position where this could be merged? :)
Apr 1 2020
Just wondering if the proposal and differential make sense now and could be signed off
Mar 26 2020
Simplifying UI per feedback.
So how about this:
Mar 23 2020
Just wondered whether any of those suggested labels might be appropriate.
Mar 19 2020
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.
Mar 17 2020
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.
Mar 12 2020
Could this land for 2.83 or will it come later?
Mar 9 2020
Any remaining concerns?
Mar 5 2020
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.
Mar 4 2020
Is there anything pending that I overlooked in the requested changes?
Mar 3 2020
@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?
Mar 2 2020
Adjusted names of functions per feedback.
Abbreviated Apache license.
Moved struct to a dedicated header file.
Mar 1 2020
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.
Feb 29 2020
Feb 28 2020
Feb 25 2020
Feb 22 2020
Feb 21 2020
Feb 19 2020
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.