Did very quick skim-review and saw nothing wrong here, feature is nice to have, so LGTM.
I just wanted to express my appreciation of the edit mode crosshair. I even used the Speedflow addon mainly because it displays the current mode in fat letters in the corner of the viewport but the crosshair change is so much better. Now you can tell if you are in edit mode even with disabled overlays and header.
Mon, May 25
If I understand what you are trying to prove in your code, then changing this:
I wouldn't mind having WebP support upgraded and integrated with Blender as supported image format. It's a nice image format, and rather widely used, and a patch has been waiting for 5 years already (D1598).
I was going to update this yesterday but ran out of time look for an update today. Changes shouldn't be committed yet until we bump versions.
Sun, May 24
Sat, May 23
Just updating to current state of master. No changes.
Fri, May 22
Fix own nitpicky comments.
- rebase with latest master
- added task isolation
Thu, May 21
Wed, May 20
have updated task description to bring it back to the right track
Note this has nothing to do with the imported object (can be reproduced with the default Cube).
Tue, May 19
+1 on the USD upgrade; I've updated the task description for this.
Mon, May 18
As for overall coordination here. I think it would be most convenient to review and commit the code for the library upgrades in parts, and then when it's all in place let the platform maintainers update the precompiled libraries all at once. At least as macOS maintainer I'd like to avoid doing this multiple times.
After discussion with @Sergey Sharybin (sergey) we arrived at the following. From what we can see, the following are reasons for a frame_change_post handler:
Some changes based on recommendations from @Julian Eisel (Severin):
Didn't dig too deep, but everything seems reasonable. I have a few cosmetic points to make, but that is further polish.
@Bastien Montagne (mont29) should get a chance to intervene here, he's module owner -- Feel free to remove yourself as reviewer, if you think it's gotten enough treatment already :)
Sat, May 16
Hello! I updated the diff that was mentioned here earlier.
Here is the latest demo and updated diff: D6813: Searchbox wrap around feature
Fri, May 15
Just updating to reflect recent changes to master.
While OpenSubdiv does not really bring any user-measurable difference I still suggest updating it. Reasoning:
Thu, May 14
I checked the OpenXR SDK releases. There's nothing important or interesting for us really, so no need to update that.
i took a quick survey of all our deps, made some recommendations , the deps without notes i really have no opinion on, there's some module specific deps where the owners will have to decide,
@Jacques Lucke (JacquesLucke) I agree that kind of setup would be better. But we need to check all mutex locking code for this, task isolation is the safer option until then.
Based on the Brecht's backtrace I wonder if the following would be a better long-term solution to this particular problem.
Working on oiio
Wed, May 13
Tue, May 12
I'm testing this locally for the daily rendering/lighting routine and so far it seems to stop Blender from freezing like it's been doing all week. nice!
That's only an issue when you want to have existing animation also applied. So the importer would have to be a rather special one, importing some animated data (otherwise it wouldn't have to be run on frame change) but still allowing other animations to be applied as well. I don't know of any importers that do this.
Complication #1: due to the nature of RNA and python scripting you would need to inform all dependency graphs about all property changes. Imagine having importer implemented in Python, ugh :(
Mon, May 11
Sat, May 9
Using task isolation will likely have some performance impact, but hopefully it's negligible with the right choice of implementation.
Fri, May 8
Task isolation might be a solution:
Here's a backtrace from a thread that shows the problem.
Not sure if it is related to the new undo, but I just faced weird bug: When in edit mode, i pressed Ctrl-Z to undo (inteded to undo scaling some vertices), and then quickly Ctrl-Shift-Z to redo, but i ended up in weird state - the mesh appear scaled, in the undo history I appear to be two steps below the tip, and if i redo those two steps, they was undoing my scaling action halfway for each of those two steps.
I will continue to work on it on Monday (if it is still open) @Andy Goralczyk (eyecandy) the current work-a-round IMO is to use b283.
Seems like a pthread read lock isn't freed making all write locks wait forever when building bvh trees.
I try to pause the loop and the editor stops here:
Also confirmed in Windows 10 RTX2080TI
Ah, I guess we submitted nearly at the same time :P
I can confirm the freeze on my end. If I open up the file and start playback, it will freeze after a few frames.
BLI_thread_queue_wait_finish completing does not mean all tasks have completed, just that the background thread has popped everything from the queue but might still be working on the last task.
- do not remove threads in the work_and_wait
The reason to have this background task system is for cases where the task must be run in another thread. For example in the file browser where image file previews are generated, this can't be done as a blocking task without freezing the file browser for a long time.
I decided to keep the background_queue for now.