- User Since
- Apr 12 2018, 4:20 PM (110 w, 3 d)
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.
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.
Feb 18 2020
Feb 17 2020
Used macro, changed comments to fit style guide.
Jan 21 2020
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.
Oct 2 2019
Jul 25 2019
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).
Jul 24 2019
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.
Jul 17 2019
Sep 14 2018
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.
Aug 6 2018
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.
Aug 5 2018
Jul 6 2018
Jun 25 2018
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)
Jun 21 2018
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
Jun 20 2018
Jun 18 2018
Indeed the build from today seems to be fine.
Jun 16 2018
May 13 2018
May 11 2018
Apr 18 2018
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.