GSoC Roundup Episode One: Geometry Codes

The 2021 Google Summer of Code projects have just wrapped up, concluding ten weeks of Blender development over eight projects helmed by students and supervised by members of the Blender development team. This is the first post in a four-part series exploring what the students have achieved during this year’s development stint.

Episode One: Geometry Codes


The first part of this series will look at GSoC projects dealing with one of the liveliest and youngest sections of Blender: Geometry Nodes. Two projects tackled the module, with Fabian Schempp diving head-first into the development fray and porting a slew of modifiers into their nodal form, and Himanshi Kalra providing support to this breakneck development pace by developing a framework for regression testing of Geometry Nodes.


Porting popular modifiers to Geometry Nodes – Fabian Schempp

Familiar grounds

Fabian Schempp is no stranger to the Blender codebase: He had already been contributing patches to the Geometry Nodes Project since the end of 2020, a familiarity that must have come in handy during his GSoC tenure, which saw him complete and submit patches for nine new modifier-turned-nodes. Fabian was mentored by Jacques Lucke and Hans Goudey.

Show me the nodes

Here is a quick rundown of the 9 added nodes.

Remesh Blocks

Based on the Remesh modifier.

Merge by Distance

Based on the Weld modifier.

Unsubdivide

Based on the Decimate modifier.

Dissolve

Based on the Decimate modifier.

Voxel Remesh

Based on the Remesh modifier.

Collapse

Based on the Decimate modifier.

Mesh Inset

Based on the Mesh Inset operator.

Mesh Extrude

Based on the Mesh Extrude operator.

Solidify

Based on the Solidify modifier.

Seven of these nine new nodes are a port of the “Solidify”, “Weld”, “Remesh”, and “Decimate” modifiers. Some modifiers (such as the “Remesh” modifier) have been split into multiple nodes to fit into Geometry Nodes’ modular design philosophy. Fabian also ported the “Inset” and “Extrude” operators, with the latter’s power being on full display on the “Attributes and Fields” blog post. Fabian’s final report contains images and examples of what every single one of these is capable of.

What comes next

Fabian plans to continue working on these nodes until they are ready to be merged to master, a step that would probably include porting them to work with the up-and-coming “fields” revision of Geometry Nodes.


Regression Testing of Geometry Nodes – Himanshi Kalra

One more time, with feeling

Next up is Himanshi Kalra, who is not only familiar with the Blender codebase, but is also a GSoC Veteran: She had already successfully worked on regression testing during the 2020 edition of GSoC.This year Himanshi returned, flanked by mentors Habib Gahbiche and Jacques Lucke, to develop a regression testing framework for the rapidly growing Geometry Nodes.

Testing, 1, 2, merged

At the time of writing this, Himanshi successfully submitted and merged four patches, with the main new feature being the extension of the framework to test .blend files directly without going through the Blender API to add tests. This process is explained in more detail by Himanshi on the wiki. While its usefulness and importance within the growing size of the Blender project is beyond question, the development-oriented nature of this GSoC project makes it less flashy and visually compelling than its brethren. So here is a screenshot of all the nodes with implemented tests at the time of writing, to satisfy your Blender-loving irises:

An image of all the geometry nodes than now have regression testing, implemented by Himanshi during her GSoC
Himanshi developed quite the testable roster over her ten week stint

Join us next week for the second episode of the GSoC Roundup, where we will take a look at improvements made to the VSE and UV Editor!

Find out more on these two projects on the links below:

19 comments 4,462 Views
  1. Great Job!!

  2. Congrats everybody and thanks for your contributions

  3. ooh, very exciting!

  4. Congrats to all the students!
    On a side note, I’d recommend toning the writing style down a bit. These overwrought sentences don’t aid communication, aside from being in slightly bad taste.

    • It is the first time Mario writes to the Blender Development Blog so we were still adjusting the tone. He has just toned it down a bit. Thanks for the feedback, it was super valuable.

      • Actually, I found that really enjoyable. Shows passion and addresses a young and eager community that’s the exact opposite from the corporate talk you’d expect from the big brands like Adobe and Autodesk.

      • Rereading it now, I wish I’d put it more delicately; I didn’t mean to sound rude. Props to Mario for his work towards the Blender community and for his impressive command of the language. But I believe my point still stands, in that we’d benefit from less flowery sentences. Cheers!

  5. Cool, thanks for all the efforts!!!

  6. I would like to see particle nodes, including some good solvers

    • While integrating simulations in geometry nodes is planned, and exciting, it’s far outside of the scope of a single GSoC project!

  7. Are there any plans to implement:

    – Dynamic vertex/edge/polygon selection, based on expressions, normal direction, world space coords, etc.
    – Dynamic vertex groups.
    – Dynamic material polygon assignment and material slot creation.

    It seems like an area that would be hard to change, but I don’t know?

    • Yes! All three are planned, or at least the functional equivalents.
      1. Selections are handled quite well by the fields changes, which are detailed in other recent posts here. You can also see people sharing selection node groups in the proposal thread on devtalk.
      2. “Dynamic vertex groups” I’m not actually quite sure what you mean with this one. In many cases vertex groups will be superseded by generic attributes in the near-ish future.
      3. This is already possible in the 3.0 alpha branch with the “Material” assign nodes. Try it out!

  8. Great work!

  9. Good

  10. Why not keep the same names and feature sets between the modifiers and the nodes for coherence?

    Like the decimate, why is it 3 nodes in geo nodes, but a single modifier on the other side?
    Just do a decimate node with the same 3 options as the modifier…

    The simpler the better.

    • Nodes are building blocks that users can combine with more flexibility than monolith modifiers. The idea is to try to make them as small as possible within reason.

      • That’s your version of a node system, many prefer fewer nodes with a couple more options than a million nodes to learn.

        A node can embed multiple behaviors like a math node that can handle multiple operations, or a blur node that features all blur types in one… why not the same for decimate?
        That was a completely arbitrary decision you took here.

        Splitting everything in a bazillion nodes end up being a huge pile of complex mess like Houdini.

  11. Does anyone by any chance knows why the latest features like extrude, selection etc. are not available anymore on the latest geo nodes fields build?

    • The extrude node was quickly hacked for the prototype. It will come back, but the current priority is to first properly port the existing nodes.

  1. Leave a Reply

    Your email address will not be published. Required fields are marked *

     
share this story on