State for Blender 2.91: Brecht continues work on bugfixing for the release. No known regressions compared to Blender 2.90 at this point.
NanoVDB: Patrick will commit the changes to enable it by default for 2.92. (T81454)
Device update: Kévin will upload the patch for faster device updates, to be reviewed.
GPU regression testing: no progress, Brecht will try to find time again this week. (T82193)
Tile stealing bugfix: Lukas asks for review of bugfix for the new 2.92 tile stealing feature. (T82351)
Resumable rendering: Stefan is looking into support for resumable rendering for tangent animation. Particularly for render farm jobs that can be interrupted, which the current resumable chunks feature is not sufficient for.
AMD OpenCL hardware raytracing and denoising: design tasks created by Brian. (T82557, T82559)
AMD interested in profiling/optimizing split kernel, Brecht created a task with ideas, partially based on discussion in the meeting. (T82583)
Eevee
Cryptomatte: Jeroen sent a patch for review (D9165)
Practical Info
This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
I think this is my favorite.
Finally we don’t have to abuse the object id for this kind of stuff anymore.
It is also great that you can differentiate between instances, meshes and objects.
Hey
So, what happens with the Google Summer of Code projects? Do they get committed to a Blender release?
I’m looking at the Improved OBJ exporting/importing which looks very useful, but cant find any information about it being added to an upcoming build. Does the GSoC not work like that? The current exporting is soooooo slow, and eats every ounce of RAM you posses for large files.
Nah, as long as the project didn’t outright fail, it does usually land in master… Eventually. Sometimes it takes a really long time. And sometimes it is completely rewritten from scratch in the mean time. And yeah, sometimes they do wither, but not often.
For the I/O import/export, it’s in review, but as of now, it fails to import/export certain geometry. The dev is aware of the bugs and is still in progress, albeit slowly, tho.
The 2020 GSoC seems to have gone quite well so far in regards to merging.
Out of 10 projects:
3 were already merged (Fluid-Sim, Grease Pencil, Outliner) and 2 seem close (fast IO, regression testing). Think that’s more than usual at this stage.
1 project failed (VR), another one passed but AFAIK student and mentors all agreed not to merge it (soft-body).
The remaining 3 are on the review backlog (many light sampling, custom menus, Info Editor).
For the 2 UI ones: Reviewing these would take significant amounts of time away from projects like Geometry Nodes, Asset Browser and the tool system. So we rely on the students to take the initiative, show that they really want to have the projects merged and can do it efficiently for the reviewers.
Also worth noting that the big LANPR project from previous years is in active review for quite a while already.
Remember that the goal of GSoC is not to get features in. It’s more about the students’ experience than for the projects (as in, Blender). Obviously it’s great to have student projects merged, but it’s even greater if the students stick around and help the project longer term.
I think it’s going better than it used to in both regards. There were some great students lately who became active contributors, became part of module teams, and/or further receive grants through the development fund even.
Uhm. What does that mean? What is it specifically that you expect them to do? Do they even know you have these expectations? I mean, if I were a student, after I handed in the code I’d expect it to be reviewed, there wouldn’t be much else for me to do here.
probably adding fixes
adhering the design patterns of the code to the rest
aligning the UI of the new features to the rest of the program and probably a bit of code commentary?
Blender devs have said they don’t want code merged that isn’t going to maintained. That would include GSOC projects. So if a full time dev doesn’t want to take it on and the student isn’t going to, that’s a good reason not to review/merge.
I don’t know specifics, but I think the student wasn’t happy with the implementation and neither were mentors/module-owners. Such things happen (been there, done that) and after all the student successfully passed GSoC. Also, it’s a good sign that the student realized these issues himself. @ZedDB (mentor) should know more.
First and foremost we have to be assured the student will be around and motivated enough to go through the typically tedious review process, as well as maintain the code after it is merged.
Besides the actual code-review, somebody has to:
Discuss the UI and architectural design from the big-picture to the details.
Get feedback from (trusted & professional) artists.
Think about the best strategy to review and merge individual parts. (E.g.: “This is a muscle memory breaking change, shouldn’t we test this some more before the release?”)
Keep track of and possibly address feedback after the merge.
Ensure there is good documentation and review it (release notes, manual, sometimes code-documentation).
…
It’s simply much more than just reading through the code.
For example, I just did much of this for the Outliner project and don’t like the idea of having to do it again soon. It’s time I wasn’t able to spend on the Asset Browser, which is a questionable trade-off.
However, with Nathan we already knew it would work out in the end.
I don’t think so, it was a rather recent decision and I’d still like to check with the two students personally. I would like to see how they feel about their project, if they would like to merge it at all, as well as how and when we could do this.
To be clear: We would still like to merge the projects, we’re just wary of reviewing them at this very time and have to make sure it works out well if/once we do.
You could argue we shouldn’t accept such projects if we don’t know if we can manage the review, and I agree, we should be more careful there. Although in this case, the initial Info Editor project proposal wasn’t much of a UI project (more about debugging tools), it morphed into one. Plus, at the time William was highly active still which he can’t be currently.
Ah, I didn’t really expect such a detailed response, I now feel like I’ve robbed you of more time than I intended.
So basically you just want them to stick around and polish their patches up after the initial review is done, which is quite reasonable. But please do copy-paste them your response here, else they might think the matter is out of their hands and just continue waiting and be disappointed that their patches aren’t getting any eyes on them.
Notes for meeting of Monday, 16 November 2020. 11:00 CET / UTC 10:00 on #blender-coders on blender.chat.
Announcements
Google Summer of Code “Grease Pencil Bezier editing” by Falk David was merged!
Tuesday Talk (placeholder link for the upcoming meeting)
Blender 2.91
bcon4 still planned for November, 18 (Wednesday).
Focus on fixing/addressing/re-triaging high priority as soon as possible.
Review status on Wednesday at 11:00 CET / UTC 10:00 n #blender-coders .
New Features and Changes
Blender 2.92
Cycles: volume rendering is now significantly more memory efficient, by using a sparse NanoVDB grid. Results are highly dependent on the volume shape. With one a production volume asset memory usage was reduced 3x, at the cost of 10% longer render time. (commit ) (Patrick Mours)
Overrides: support overriding physics point caches, for locally baking simulations. (commit ) (Bastien Montagne)
Pretty cool ! So why do all the objects appear independently even though he chose to create an asset from all of them ? Shouldn’t it appear as a single “Spring” asset ?
