Thanks for providing the easy to reproduce report as well as the fix!
Fri, Jun 11
I only made this from the Cycles procedural, so updating the data when changing properties
was not implemented for Blender.
The checkbox used to only be shown if Cycles was set as the render engine, but it was decided in an earlier review to always show it. Perhaps we should always show it but only enable it if the RenderEngine supports the feature, and add a message in the modifier's UI to if the currently selected render engine does not support it?
That sounds good to me!
In that case, I'll consider this task resolved :)
- Apply the same change to the Industry Compatible keymap
I'll apply that change when committing this patch. Thanks for the contribution!
This should probably also be addressed in the Industry Standard keymap then? That's stored in industry_compatible_data.py.
We talked about this in yesterday's Animation & Rigging module meeting. It's probably better to make the patch a little bit more "invasive", and actually remove the code that changes the user's choice in extrapolation mode (search for /* FIXME: this needs to be more automated, since user can rearrange strips */).
Thu, Jun 10
This was just mentioned in the Animation & Rigging module meeting as well, as a big issue also with newer Blender users.
I think this patch does a few things at once, and even though they're useful, I think they should be split up:
Rebased and removed Invert, since I don't have an immediate use in mind for it.
Just to check whether I understand this patch correctly. Does the "Owner Local Space" do this?
Some more review comments. I haven't read through everything yet, though, but I wanted to at least submit this.
I'm still missing some ingredients of a patch. I'd like to know why this solution (evaluate the to-be-applied constraint by itself, then apply) was chosen over other solutions (like simply applying the result of the constraint stack up to the to-be-applied constraint). Does it produce more reliable or predictable results? Or was there some other reason?
Now that I look at it again, I don't agree with the way these functions interact with each other:
I'm resigning as reviewer, as T81704 has been fixed already. Feel free to close the patch ("Abandon Revision", which sounds slightly more dramatic).
This patch doesn't build without D10197:
Playing around with the feature a bit more, I see I may have accepted the patch too soon. It would seem that the "Use Render Engine Procedural" checkbox doesn't do anything until Cycles is actually chosen as render engine. This makes it rather confusing, as:
Alembic 1.8.2 was just released. Shall we target that one instead of 1.8.1? The changes really are minor, and I don't expect they'll even influence Blender, but that way at least we're at the latest version.
Tue, Jun 8
LGTM. I've changed @Luciano Muñoz Sessarego (looch) from blocking reviewer to normal reviewer; this feature has been discussed in the Animation & Rigging meetings as well, and AFAIK it has his approval.
- Asset Browser: explain reason "Open Blend File" is disabled
- Merge remote-tracking branch 'origin/master' into asset-browser-poselib
- Pipeline config: use asset-browser-poselib addon branch
- Merge remote-tracking branch 'origin/master' into asset-browser-poselib
- Cleanup: add notice to pipeline_config.json
There are some compiler warnings now:
/* Checks whether the given rectangle intersects the given fcurve's calculated curve (i.e. not * only keyframes, but also all the interpolated values). This is done by sampling the curve at * different points between the xmin and the xmax of the rectangle. */
At first I was considering to suggest using some Beziér curve intersection routine. However, that would get rather complex, because every section of the FCurve can have a different interpolation function. On top of that, there are modifiers that can arbitrarily change the FCurve shape. In the end I think sampling is a good choice.
How does the "Apply Constraint" operator work? Can it be used on anything but the first constraint of the stack? This should be clearly described in the patch description. I don't know whether the code is doing the right thing or not, or whether it's doing its job efficiently, if I don't know beforehand what it should be doing.
Using an environment variable makes all this a bit easier. First, you do not have to pass environment variables arguments down to the Wayland implementation for GHOST. Second, you can set this in your profile (~/.profile) and it will always use the Wayland backend, no matter how the blender executable was started. Third, this is only temporary, until the Wayland backend is deemed to be stable. Having this single if (std::getenv("BLENDER_WAYLAND")) is much less of a maintenance burden when it is removed later again. This is also how Firefox and SDL manage this.
Mon, Jun 7
This enables Wayland by default at compile time (WITH_GHOST_WAYLAND set to ON) but leaves it deactivated at runtime unless the environment variable BLENDER_WAYLAND is set.
Is there a reason to use an environment variable for this, instead of a commandline option? So far the only choice (--background for choosing between X11 or no graphics at all) is also a CLI option.
This is not a support forum. Since the problem with the Track To constraint has been clarified, this task can be closed.
Correct. Shows how much work there is for the developers.
In that case let's consider this a known limitation that is also under-documented. As far as I'm concerned, it can be resolved by simply clarifying this in the manual.
Moving this to the Short Term workboard as discussed in the 2021-05-27 Animation & Rigging module meeting.
Fri, Jun 4
@Philipp Oeser (lichtwerk) Thanks for confirming. I guess it would be nice if this limitation is considered a bug at this point
I think this patch would be nice to have in Blender 3.0, as it is potentially more disruptive, which fits an "x.0" release. @Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) would you agree that your earlier comments have been addressed?
With recent changes in the Alembic exporter code, this patch no longer applies. Could you rebase it to the latest master?
I tested with Blender as old as 2.75, and the behaviour has been the same through the years.
For that one remaining topic seems it is all clear that there are cons and pros in all the camps. Don't think it worth re-iterating on those cons/pros. So, have a vote between admins and carry on with lives?
Since Blender 2.93 (release notes) it is possible to alt-click and get a drop-down of available bones (just like alt-click to select objects). Would that be a good enough resolution for this issue? Or should the depth picking still be improved?
Thanks for the analysis @Falk David (filedescriptor) . I take back my "this seems like a bug" and replace it with "this is by design".
While applying your patch:
Created and checked out branch arcpatch-D11181. /tmp/d51mdooucy04c4oo/19099-GxedVl:259: trailing whitespace.
[...] the Limit Rotation constraint with Limit XYZ all turned off should have no effect at all
I don't have the time to look at this on short notice, so unassigning myself to allow someone else to step in.
Thu, Jun 3
@Hadrien Brissaud (hadrien) this patch is still under review, so it's not in any release.
From the patch description:
Exactly what counts is the perimeter should to be clearly defined.
I think this sentence should also be more clearly defined ;-) I'm guessing you meant "what counts as the parameters".
This patch has a problem that properties being modified currently use ID_RECALC_GEOMETRY, this patch will prevent them from updating the copy-on-write data.
Something to think about for a future patch: maybe it could automatically enable extrapolation when someone types a percentage outside the [0-100] range?
Since all changes in this patch are now contained in the aforementioned patches, this one can be closed.
There are a few changes that are different than just renaming a field. These changes are fine, but should be committed separately.
Wed, Jun 2
Mon, May 31
Fri, May 28
Thu, May 27
This is discussed in the Animation & Rigging module meeting, and agreed that the way things work now are sub-optimal. This could be a nice thing to fix for a new developer.
Tue, May 25
Correction: FFmpeg was upgraded from version 4.2.3 → 4.4
Given that this version bump fixes an acute problem for the Blender Animation Studio, I'll go ahead and land this patch, then update the Linux libraries in SVN.
Remove check from ffmpeg_compat.h again so that Blender can build against any version. This should only be included after all platforms have had a chance to build the libs.
- Update minimum version check in ffmpeg_compat.h
I can confirm this is fixes by linking against FFmpeg 4.4.
I don't quite like the fact that Cycles is made part of the CacheFile API. Is there any reason why this would be Cycles-specific, and not just render-engine-agnostic? In the current state of the patch, all of a sudden there is Cycles-specific code, which spreads to the constraint & modifier systems as well.