Making the Hue Correct Curves Wrap #117114

Merged
Omar Emara merged 31 commits from JonasDichelle/blender:hue-correct-bezier-wrap into main 2024-03-21 15:35:13 +01:00
Contributor

Making the Hue Correct Curves Wrap

Overview

Currently, the hue correct curves in both the compositor and the video sequence editor don't wrap on either side.
This causes there to be two reds, one on the bluer side and the other on the greener side.
Both are treated as separate parts of the spectrum, even though they should wrap back onto each other.
This results in tearing between the colors.

Current Proposed Fix

The Proposal

To fix the issue, I've added the ability to enable wrapping to the curve maps.
When enabled, we add two imaginary bezier curve points at either end of the curve map and calculate their handles to get a seamless wrapping fall off.
I added the function BKE_curvemap_set_wrapping, which is called whenever we initialize new hue correct curves.
That way we make sure already existing nodes will not be affected.



works in the VSE too

# Making the Hue Correct Curves Wrap ## Overview Currently, the hue correct curves in both the compositor and the video sequence editor don't wrap on either side. This causes there to be two reds, one on the bluer side and the other on the greener side. Both are treated as separate parts of the spectrum, even though they should wrap back onto each other. This results in tearing between the colors. | Current | Proposed Fix | |:--------------:|:-------------:| | <video src="/attachments/5ec01443-65fa-48de-a3c4-f7ef14ee7153" title="blender_V5ivS8uvtv.mp4" controls></video> | <video src="/attachments/94622177-0e43-43e0-8113-252d96a2bc93" title="blender_24tmwyim0Y.mp4" controls></video> | --- ## The Proposal To fix the issue, I've added the ability to enable wrapping to the curve maps. When enabled, we add two imaginary bezier curve points at either end of the curve map and calculate their handles to get a seamless wrapping fall off. I added the function `BKE_curvemap_set_wrapping`, which is called whenever we initialize new hue correct curves. That way we make sure already existing nodes will not be affected. --- <video src="/attachments/5746fc0c-41f6-4007-a174-76f3c2ca6a5a" title="blender_gFnuDtmIzs.mp4" controls></video> _works in the VSE too_
Jonas Dichelle added 5 commits 2024-01-14 18:43:34 +01:00
Iliya Katushenock added this to the Compositing project 2024-01-14 18:58:57 +01:00
Jonas Dichelle added 1 commit 2024-01-14 19:30:13 +01:00
First-time contributor

Awesome addition! Makes colour correcting images soooo much better!

Awesome addition! Makes colour correcting images soooo much better!
Omar Emara added the
Module
VFX & Video
Interest
Compositing
Interest
Video Sequencer
labels 2024-01-16 15:19:54 +01:00
Omar Emara requested review from Omar Emara 2024-01-16 15:20:42 +01:00
Omar Emara reviewed 2024-01-23 21:55:57 +01:00
Omar Emara left a comment
Member

I feel like this could be implemented in a simpler way, with less such large branching, though I might be wrong. In particular, I suspect we can implement this by only adding the necessary elements to the bezt array, with minor adjustements to the rest of the function. Can you clarify why it is implemented like this?

I feel like this could be implemented in a simpler way, with less such large branching, though I might be wrong. In particular, I suspect we can implement this by only adding the necessary elements to the `bezt` array, with minor adjustements to the rest of the function. Can you clarify why it is implemented like this?
Jonas Dichelle added 1 commit 2024-01-29 18:47:41 +01:00
Author
Contributor

@OmarEmaraDev, thank you for reviewing the code!
You are right, there were some areas of the code that added too many unnecessary redundancies.
I went through the code and I believe that I simplified it as much as possible.

@OmarEmaraDev, thank you for reviewing the code! You are right, there were some areas of the code that added too many unnecessary redundancies. I went through the code and I believe that I simplified it as much as possible.
Jonas Dichelle added 1 commit 2024-01-29 19:32:24 +01:00
Jonas Dichelle added 1 commit 2024-01-30 13:14:45 +01:00
Jonas Dichelle added 1 commit 2024-02-07 19:56:49 +01:00
Jonas Dichelle added 1 commit 2024-02-07 19:57:44 +01:00
Omar Emara requested changes 2024-02-08 10:58:37 +01:00
Dismissed
Omar Emara left a comment
Member

Additionally, a different curve preset needs to be used for curves that wrap. CURVE_PRESET_MID9 has points at the very start and very end, which won't play well with wrapping. Instead, another present that exempt the end point needs to be added and used.

Additionally, a different curve preset needs to be used for curves that wrap. CURVE_PRESET_MID9 has points at the very start and very end, which won't play well with wrapping. Instead, another present that exempt the end point needs to be added and used.
@ -638,2 +643,4 @@
}
/* Evaluate a point on a curve, given two bezier triples */
static void BKE_curve_eval_bezier_point(float bezt1[3][3], float bezt2[3][3], float *point)
Member

Drop the BKE prefix, since this is a static function and not part of a public API.

Drop the BKE prefix, since this is a static function and not part of a public API.
JonasDichelle marked this conversation as resolved
@ -654,3 +675,3 @@
/* Rely on Blender interpolation for bezier curves, support extra functionality here as well. */
bezt = static_cast<BezTriple *>(MEM_callocN(cuma->totpoint * sizeof(BezTriple), "beztarr"));
int bezt_count = cuma->totpoint;
Member

Why allocate the extra bezier points as part of the array? Just create two stack variables for them, see below.

Why allocate the extra bezier points as part of the array? Just create two stack variables for them, see below.
Author
Contributor

I thought since we're already allocating an array of the same type to the heap we might aswell add the two new points. But you're right it's cleaner to just have them as seperate variables.

I thought since we're already allocating an array of the same type to the heap we might aswell add the two new points. But you're right it's cleaner to just have them as seperate variables.
JonasDichelle marked this conversation as resolved
@ -674,1 +696,4 @@
const BezTriple *bezt_next = nullptr;
const BezTriple *bezt_prev = nullptr;
/* Create two extra points for wrapping curves. */
Member

You can do something like, then take their address later.

  BezTriple virtual_start_bezier = bezt[cuma->totpoint - 1];
  virtual_start_bezier.vec[1][0] -= 1.0f;

  BezTriple virtual_end_bezier = bezt[0];
  virtual_end_bezier.vec[1][0] += 1.0f;
You can do something like, then take their address later. ``` BezTriple virtual_start_bezier = bezt[cuma->totpoint - 1]; virtual_start_bezier.vec[1][0] -= 1.0f; BezTriple virtual_end_bezier = bezt[0]; virtual_end_bezier.vec[1][0] += 1.0f; ```
JonasDichelle marked this conversation as resolved
@ -675,0 +705,4 @@
if (use_wrapping) {
/* Handle location of pre and post points for wrapping curves. */
bezt_pre->h1 = bezt_pre->h2 = bezt[cuma->totpoint - 1].h2;
bezt_pre->vec[1][0] = bezt[cuma->totpoint - 1].vec[1][0] - 1.0f;
Member

This assumes the curve map has a horizontal range of [0, 1]. The actual range is [cumap->clipr->xmin, cumap->clipr->ymin]. I am not sure how this should be handled, bur have you considered this?

This assumes the curve map has a horizontal range of `[0, 1]`. The actual range is `[cumap->clipr->xmin, cumap->clipr->ymin]`. I am not sure how this should be handled, bur have you considered this?
Author
Contributor

I assumed since this was only being used by hue correct that would fine.
But you're rigth, I replaced it with the correctly calculated table range now.

I assumed since this was only being used by hue correct that would fine. But you're rigth, I replaced it with the correctly calculated table range now.
JonasDichelle marked this conversation as resolved
@ -727,3 +788,1 @@
int totpoint = (cuma->totpoint - 1) * CM_RESOL;
float *allpoints = static_cast<float *>(MEM_callocN(totpoint * 2 * sizeof(float), "table"));
float *point = allpoints;
int totpoint;
Member

Why separate declarations from initializations? Do the initialization directly.

Why separate declarations from initializations? Do the initialization directly.
JonasDichelle marked this conversation as resolved
@ -765,0 +809,4 @@
/* Handle post point for wrapping */
BKE_curve_eval_bezier_point(bezt[cuma->totpoint - 1].vec, bezt_post->vec, point);
}
else {
Member

I would put that else in its own condition (!use_wrapping) for clarity.

I would put that else in its own condition `(!use_wrapping)` for clarity.
JonasDichelle marked this conversation as resolved
Jonas Dichelle added 1 commit 2024-02-08 17:24:41 +01:00
8749a23e7d fixes for code review
-removed BKE prefix from static function
-removed extra points from array, moved to stack
-made offset of pre and post points dynamic to match table range
-combiend declarations and initializations
-made condition explicit for clarity
Jonas Dichelle added 1 commit 2024-02-08 17:34:30 +01:00
Author
Contributor

Additionally, a different curve preset needs to be used for curves that wrap. CURVE_PRESET_MID9 has points at the very start and very end, which won't play well with wrapping. Instead, another present that exempt the end point needs to be added and used.

I added CURVE_PRESET_MID8. Now MID9 isn't being anymore, since it was only being used by hue correct.
Do you think we can just replace MID9 with MID8?

> Additionally, a different curve preset needs to be used for curves that wrap. CURVE_PRESET_MID9 has points at the very start and very end, which won't play well with wrapping. Instead, another present that exempt the end point needs to be added and used. I added CURVE_PRESET_MID8. Now MID9 isn't being anymore, since it was only being used by hue correct. Do you think we can just replace MID9 with MID8?
Jonas Dichelle requested review from Omar Emara 2024-02-08 17:42:52 +01:00
Member

Do you think we can just replace MID9 with MID8?

@JonasDichelle Yah, just do that.

> Do you think we can just replace MID9 with MID8? @JonasDichelle Yah, just do that.
Omar Emara requested changes 2024-02-08 18:01:50 +01:00
Dismissed
@ -655,2 +687,3 @@
/* Rely on Blender interpolation for bezier curves, support extra functionality here as well. */
bezt = static_cast<BezTriple *>(MEM_callocN(cuma->totpoint * sizeof(BezTriple), "beztarr"));
int bezt_count = cuma->totpoint;
bezt = static_cast<BezTriple *>(MEM_callocN((bezt_count) * sizeof(BezTriple), "beztarr"));
Member

bezt_count is no longer used anywhere, so just use it directly as it was.

`bezt_count` is no longer used anywhere, so just use it directly as it was.
JonasDichelle marked this conversation as resolved
@ -788,3 +859,2 @@
/* Check if we are on or outside the start or end point. */
if (point == firstpoint || (point == lastpoint && cur_x >= point[0])) {
if ((point == firstpoint || (point == lastpoint && cur_x >= point[0])) && not use_wrapping) {
Member

Today I learned that C++ has a not keyword. :)
Not sure if the style guide has anything against it, but I would just use ! to avoid confusion.

Today I learned that C++ has a `not` keyword. :) Not sure if the style guide has anything against it, but I would just use `!` to avoid confusion.
Author
Contributor

hahaha sure

hahaha sure
JonasDichelle marked this conversation as resolved
@ -100,12 +101,13 @@ typedef enum eCurveMappingPreset {
CURVE_PRESET_SHARP = 1,
CURVE_PRESET_SMOOTH = 2,
CURVE_PRESET_MAX = 3,
CURVE_PRESET_MID9 = 4,
Member

Never change the values of DNA enums, if you want to add a new value, add it at the end.
That's because those values can be stored in files.

Anyway, as discussed, you can just change the MID9 to the one we want since it is only used by the hue correction curve.

Never change the values of DNA enums, if you want to add a new value, add it at the end. That's because those values can be stored in files. Anyway, as discussed, you can just change the MID9 to the one we want since it is only used by the hue correction curve.
JonasDichelle marked this conversation as resolved
Jonas Dichelle added 1 commit 2024-02-08 18:27:02 +01:00
d2bf20b47a -removed CURVE_PRESET_MID9
-reverted enum values
-replaced not keyword
Jonas Dichelle requested review from Omar Emara 2024-02-08 18:27:49 +01:00
Omar Emara requested changes 2024-02-09 14:35:16 +01:00
Dismissed
@ -637,12 +642,28 @@ static float curvemap_calc_extend(const CurveMapping *cumap,
return 0.0f;
}
/* Evaluate a point on a curve, given two bezier triples */
Member

The comment doesn't seem accurate, since we are evaluating many points. I would rename bezt1 and bezt2 to start and end, and change their type to BezTriple. I would also rename the final argument to points to reflect that they are actually many points. Then update the comment as follows:

/* Evaluates CM_RESOL number of points at the Bezier segment defined by the given start and end
 * Bezier triples, writing the output to the points array. */

The comment doesn't seem accurate, since we are evaluating many points. I would rename `bezt1` and `bezt2` to `start` and `end`, and change their type to `BezTriple`. I would also rename the final argument to `points` to reflect that they are actually many points. Then update the comment as follows: ``` /* Evaluates CM_RESOL number of points at the Bezier segment defined by the given start and end * Bezier triples, writing the output to the points array. */ ```
JonasDichelle marked this conversation as resolved
@ -643,3 +663,4 @@
const rctf *clipr = &cumap->clipr;
CurveMapPoint *cmp = cuma->curve;
BezTriple *bezt;
const bool use_wrapping = cuma->use_wrapping;
Member

I would add a comment here that roughly describes the mechanism by which wrapping is implemented.

I would add a comment here that roughly describes the mechanism by which wrapping is implemented.
JonasDichelle marked this conversation as resolved
@ -765,0 +805,4 @@
/* Handle post point for wrapping */
curve_eval_bezier_point(bezt[cuma->totpoint - 1].vec, bezt_post.vec, point);
}
if (!use_wrapping) {
Member

I am skeptical about this, because the members will now be uninitialized, so I would just leave it even if it doesn't make much sense. We could add an assert in BKE_curvemapping_compute_slopes, but also doesn't seem worth it.

I am skeptical about this, because the members will now be uninitialized, so I would just leave it even if it doesn't make much sense. We could add an assert in `BKE_curvemapping_compute_slopes`, but also doesn't seem worth it.
JonasDichelle marked this conversation as resolved
@ -59,2 +59,3 @@
short default_handle_type;
char _pad[6];
char _pad[2];
int use_wrapping;
Member

Keep the padding last and use char for use_wrapping.

Keep the padding last and use `char` for `use_wrapping`.
JonasDichelle marked this conversation as resolved
Jonas Dichelle added 1 commit 2024-02-09 16:56:32 +01:00
e154af4856 clarity fixes for code review
-update comments
-removed if statement
-changed struct order
Jonas Dichelle requested review from Omar Emara 2024-02-09 16:57:09 +01:00
Member

@JonasDichelle Looks generally good now. There are some style issues still with comments, but I would like to get review from someone else first.

@Sergey Do you want to take a look at this?

@JonasDichelle Looks generally good now. There are some style issues still with comments, but I would like to get review from someone else first. @Sergey Do you want to take a look at this?

Being able to wrap the curve used by Hue Correction sounds good, but the interface needs to become more clear: either the hue correction always needs to wrap (including the existing files) or it needs to become an option. With the current state of the patch it is confusing for artists to have such discrepancy: they'll see two Hue nodes which behave differently, without having any hint why is it so, and without a way to make existing nodes behave the same as if they were added new.

Another source of confusion is that there are still options for extrapolation in the menu. Wrapping and extrapolating sounds mutually exclusive behaviors.

Being able to wrap the curve used by Hue Correction sounds good, but the interface needs to become more clear: either the hue correction always needs to wrap (including the existing files) or it needs to become an option. With the current state of the patch it is confusing for artists to have such discrepancy: they'll see two Hue nodes which behave differently, without having any hint why is it so, and without a way to make existing nodes behave the same as if they were added new. Another source of confusion is that there are still options for extrapolation in the menu. Wrapping and extrapolating sounds mutually exclusive behaviors.
Author
Contributor

@Sergey
In my opinion hue correction should absolutely always wrap. Them not wrapping results in behavior that is always unwanted. So I don't think it should be an option.
Currently existing nodes, from old blend files are not affected. Only newly added nodes get the wrapping.
However I don't know if that is the best approach.
And you're right, in this case the "extend" options should be removed from the menu.

I'll try to make existing nodes wrap too. And I'll remove the extend options.

@Sergey In my opinion hue correction should absolutely always wrap. Them not wrapping results in behavior that is always unwanted. So I don't think it should be an option. Currently existing nodes, from old blend files are not affected. Only newly added nodes get the wrapping. However I don't know if that is the best approach. And you're right, in this case the "extend" options should be removed from the menu. I'll try to make existing nodes wrap too. And I'll remove the extend options.
Jonas Dichelle added 1 commit 2024-02-11 02:39:02 +01:00
b9bab99c63 using wrapping on existing hue corrects
-changed use_wrapping to use CurveMapping instead of CurveMap
-not showing "Extend" buttons on hue correct menu
-added use_wrapping option to uiTemplateCurveMapping for applying to existing hue corrects
Author
Contributor

I removed the “Extend” options from the hue correct curves.
And it’s now setting wrapping in uiTemplateCurveMapping, so that it affects existing curves too.

I removed the “Extend” options from the hue correct curves. And it’s now setting wrapping in uiTemplateCurveMapping, so that it affects existing curves too.
Omar Emara requested changes 2024-02-12 11:43:57 +01:00
Dismissed
Omar Emara left a comment
Member

Setting wrapping for old files should be done using versioning. See code in versioning_400.cc for examples. If you need help, let us know.

Setting wrapping for old files should be done using versioning. See code in `versioning_400.cc` for examples. If you need help, let us know.

I am not sure we should be setting this flag at all. I didn't have enough time to verify what's possible in the current design of curve-mapping, but you can imagine that it could be just a runtime flag, indicating how the widget is drawn and used by nodes. Having the flag stored on the curve-mapping would useful if we would want to make it a user-selectable behavior (which I don't think we want?)

I am not sure we should be setting this flag at all. I didn't have enough time to verify what's possible in the current design of curve-mapping, but you can imagine that it could be just a runtime flag, indicating how the widget is drawn and used by nodes. Having the flag stored on the curve-mapping would useful if we would want to make it a user-selectable behavior (which I don't think we want?)
Member

but you can imagine that it could be just a runtime flag.

@Sergey This is kind of how I image the property already. I assume you don't want to store it in DNA? Then where should it be stored?

> but you can imagine that it could be just a runtime flag. @Sergey This is kind of how I image the property already. I assume you don't want to store it in DNA? Then where should it be stored?

@OmarEmaraDev I don't think it needs to be stored at all, but live as an argument to UI template (passed from the UI script), and be passed to the evaluation by the node/modifier.

Or is there something non-obvious that make us required to store it in DNA? If so, would be nice to know it, and maybe give it some thought :)

@OmarEmaraDev I don't think it needs to be stored at all, but live as an argument to UI template (passed from the UI script), and be passed to the evaluation by the node/modifier. Or is there something non-obvious that make us required to store it in DNA? If so, would be nice to know it, and maybe give it some thought :)
Member

@Sergey Table construction happens mainly from BKE_curvemapping_changed and BKE_curvemapping_init, the former is called many times in many places like interface handlers, templates, and operators, where it is not immediately clear to me how wrapping could be passed down or identified. It could be that BKE_curvemapping_changed shouldn't really construct the table I guess, but I am not sure if code in Blender relies on that behavior somehow, so it seems possible, just might open a can of worms.

Further, having to pass it to both the draw code and the place of evaluation means that we could potentially have a curve that is drawn using wrapping but evaluated without wrapping, so less robust that having a flag.

@Sergey Table construction happens mainly from `BKE_curvemapping_changed` and `BKE_curvemapping_init`, the former is called many times in many places like interface handlers, templates, and operators, where it is not immediately clear to me how wrapping could be passed down or identified. It could be that `BKE_curvemapping_changed` shouldn't really construct the table I guess, but I am not sure if code in Blender relies on that behavior somehow, so it seems possible, just might open a can of worms. Further, having to pass it to both the draw code and the place of evaluation means that we could potentially have a curve that is drawn using wrapping but evaluated without wrapping, so less robust that having a flag.

@OmarEmaraDev Ok, things are more entagled than you hope they would. Then the wrapping should be stored in the curve mapping once during construction, and the evaluation and UI template would use it. So we wouldn't have a new parameter in the UI template.

@OmarEmaraDev Ok, things are more entagled than you hope they would. Then the wrapping should be stored in the curve mapping once during construction, and the evaluation and UI template would use it. So we wouldn't have a new parameter in the UI template.
Author
Contributor

@Sergey When should it happen during construction? If it happens when the table is constructed it won't be applied to existing curves.
The best place I can see to put it that would work without adding a parameter to ui Template is in curvemap_buttons_layout where it handles the hsv curves.
That way it can automatically be added to HSV curves.

@Sergey When should it happen during construction? If it happens when the table is constructed it won't be applied to existing curves. The best place I can see to put it that would work without adding a parameter to ui Template is in `curvemap_buttons_layout` [where it handles the hsv curves](https://projects.blender.org/blender/blender/src/commit/b9bab99c630a16f894a017922c7faf611e950898/source/blender/editors/interface/interface_templates.cc#L4650). That way it can automatically be added to HSV curves.
Member

@JonasDichelle That's why we mentioned versioning, as it should allow you to adjust existing curves. See my comment above.

@JonasDichelle That's why we mentioned versioning, as it should allow you to adjust existing curves. See my comment above.
Author
Contributor

@OmarEmaraDev thanks, now I understand. Sorry, I missunderstood earlier.
So the idea is to still store it in DNA, but to only set it during construction and versioning?

@OmarEmaraDev thanks, now I understand. Sorry, I missunderstood earlier. So the idea is to still store it in DNA, but to only set it during construction and versioning?
Member
@JonasDichelle Yes.
Jonas Dichelle added 1 commit 2024-02-16 05:46:46 +01:00
Jonas Dichelle added 1 commit 2024-02-16 05:51:51 +01:00
Jonas Dichelle added 1 commit 2024-02-16 06:10:50 +01:00
Jonas Dichelle requested review from Omar Emara 2024-02-16 06:11:04 +01:00
Omar Emara requested changes 2024-02-23 11:04:49 +01:00
Dismissed
@ -644,6 +660,14 @@ static void curvemap_make_table(const CurveMapping *cumap, CurveMap *cuma)
CurveMapPoint *cmp = cuma->curve;
BezTriple *bezt;
/*
Member

Comment lines should start with a start per the style guide.
https://developer.blender.org/docs/handbook/guidelines/c_cpp/#cc-comments

/* Wrapping ensures that the heights of the first and last points are the same. It adds two virtual
 * points, which are copies of the first and last points, and moves them to the opposite side of the
 * curve offset by the table range. The handles of these points are calculated, as if they were
 * between the last and first real points. */
Comment lines should start with a start per the style guide. https://developer.blender.org/docs/handbook/guidelines/c_cpp/#cc-comments ``` /* Wrapping ensures that the heights of the first and last points are the same. It adds two virtual * points, which are copies of the first and last points, and moves them to the opposite side of the * curve offset by the table range. The handles of these points are calculated, as if they were * between the last and first real points. */ ```
JonasDichelle marked this conversation as resolved
@ -751,0 +808,4 @@
/* Handle post point for wrapping */
curve_eval_bezier_point(bezt[cuma->totpoint - 1].vec, bezt_post.vec, point);
}
/* store first and last handle for extrapolation, unit length
Member

Comment style as well.

/* Store first and last handle for extrapolation, unit length. (Only relevant when not using
 * wrapping.) */
Comment style as well. ``` /* Store first and last handle for extrapolation, unit length. (Only relevant when not using * wrapping.) */ ```
JonasDichelle marked this conversation as resolved
Jonas Dichelle added 2 commits 2024-02-26 09:07:28 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
25bb505e5e
fixed comment style
Jonas Dichelle requested review from Omar Emara 2024-02-26 09:08:19 +01:00
Member

@blender-bot build

@blender-bot build
Member

Looks like main is not merged completely and your versioning code is out of sync with the version define.

Looks like main is not merged completely and your versioning code is out of sync with the version define.
Jonas Dichelle added 4 commits 2024-02-27 01:27:29 +01:00
Author
Contributor

I wasn't exactly sure how to adjust the versioning.
The last version being checked in versioning_400 was 402, 5 but the version in BKE_blender_version was already 402, 6. So I just made my changes be 402, 7 now. I hope that is correct.

I wasn't exactly sure how to adjust the versioning. The last version being checked in versioning_400 was `402, 5` but the version in BKE_blender_version was already `402, 6`. So I just made my changes be `402, 7` now. I hope that is correct.
Omar Emara approved these changes 2024-03-01 20:11:17 +01:00
Omar Emara left a comment
Member

Versioning needs to be updated, but we can do that before merging. Otherwise, looks good.

Versioning needs to be updated, but we can do that before merging. Otherwise, looks good.
Sergey Sharybin reviewed 2024-03-05 15:13:10 +01:00
@ -171,0 +172,4 @@
/**
* Set the wrapping mode for the curve map.
*/
void BKE_curvemap_set_wrapping(CurveMapping *cumap, bool use_wrapping);

Do we need this function? Not sure why is this better than direct assignment. Even the current PR kinda mixes the setter approach with the direct assignment.

Do we need this function? Not sure why is this better than direct assignment. Even the current PR kinda mixes the setter approach with the direct assignment.
JonasDichelle marked this conversation as resolved
@ -1413,3 +1473,3 @@
hist->x_resolution = 256;
hist->xmax = 1.0f;
// hist->ymax = 1.0f; /* now do this on the operator _only_ */
/* hist->ymax = 1.0f; /* now do this on the operator _only_ */

This probably generates warning about /* used within /* ... */. Having a note like /* NOTE: The maximum Y value is expected to be set by the users of the mapping, i.e. via operator. */ will be better than such historical/time references in the code. Or just leave the code untouched as it is not directly related implementing the feature.

This probably generates warning about `/*` used within `/* ... */`. Having a note like `/* NOTE: The maximum Y value is expected to be set by the users of the mapping, i.e. via operator. */` will be better than such historical/time references in the code. Or just leave the code untouched as it is not directly related implementing the feature.
JonasDichelle marked this conversation as resolved
@ -81,3 +81,3 @@
short tone;
char _pad[6];
char use_wrapping;

Any specific reason for this being a new flag and not a flag like CUMA_DO_CLIP ?

Any specific reason for this being a new flag and not a flag like `CUMA_DO_CLIP` ?
JonasDichelle marked this conversation as resolved
Jonas Dichelle added 1 commit 2024-03-06 10:05:24 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
c7f6eabc80
chaging to use flags, removed function
Author
Contributor

@Sergey I implemented your suggestions!

@Sergey I implemented your suggestions!

@JonasDichelle Thanks! On the code side I do not have any further remarks at this time.

For the next steps I'd want to double-check on the possible unwanted behavior change with all the latest code updates just to be on a safe side. And either me or Omar will help with the versioning.

@JonasDichelle Thanks! On the code side I do not have any further remarks at this time. For the next steps I'd want to double-check on the possible unwanted behavior change with all the latest code updates just to be on a safe side. And either me or Omar will help with the versioning.
Member

@Sergey To me, user-level behavior seems as one might expect.

@Sergey To me, user-level behavior seems as one might expect.

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR117114) when ready.

@OmarEmaraDev Indeed it does. I've tested it now as well.

So the remaining part is to solve merge conflict, land the patch, take care of the tests (i think some reference images might need to be updated).

@OmarEmaraDev Indeed it does. I've tested it now as well. So the remaining part is to solve merge conflict, land the patch, take care of the tests (i think some reference images might need to be updated).
Member

@JonasDichelle We should be ready to merge this, just need to fix the mergeconflict and update versioning, can you do that?

@JonasDichelle We should be ready to merge this, just need to fix the mergeconflict and update versioning, can you do that?
Jonas Dichelle added 2 commits 2024-03-21 14:17:37 +01:00
Member

It seems like you accidentally committed submodule hashes, can you revert those?

It seems like you accidentally committed submodule hashes, can you revert those?
Jonas Dichelle added 2 commits 2024-03-21 14:29:28 +01:00
Jonas Dichelle added 1 commit 2024-03-21 14:41:05 +01:00
Author
Contributor

Yes sorry about that. But the merge and versioning should all be up to date now!

Yes sorry about that. But the merge and versioning should all be up to date now!
Omar Emara merged commit 8812be59a4 into main 2024-03-21 15:35:13 +01:00
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117114
No description provided.