Create new geometry-kernel module #86869

New Issue

Campbell Barton · 2021-03-24T03:55:57+01:00

Campbell Barton commented

2021-03-24 03:55:57 +01:00

Motivation

Currently spesific editing operations are being added to blenkernel (boolean, mirror, voxel), that are closer to modifier operations than core kernel features.

With modifiers being ported to nodes, there will be more cases where the modifiers and geometry nodes will share code. To avoid adding more specific geometry operations to blenkernel, we could have a new module for this shared logic.

Proposal

Add a geometry kernel module ./source/blender/geomkernel.

This fits above blenkernel/bmesh, and below modifiers, geometry-nodes & editors.

Operations associated with modifiers nodes would be moved here from blenkernel (boolean, mirror, voxel).
This would not be spesific to mesh data, it can contain mesh/curve/point-cloud/voxel operations.
Low level (core operations) such as custom-data API, data validation would remain in BKE.
High level operations (window manager, operators ... etc), would remain in editors.
When porting modifiers to nodes, shared operations would be added to this module.

Open Topics

Naming, the name kernel indicates this is lower level than it is, could be called geom_ops... or something that indicates this is intended for shared geometry manipulation functions.
Choose a common naming prefix for headers & functions.
Exactly which BKE modules to move to this module initially. As already stated (boolean, mirror, remesh_voxel, fair), others could be moved later.

### Motivation Currently spesific editing operations are being added to `blenkernel` (boolean, mirror, voxel), that are closer to modifier operations than core kernel features. With modifiers being ported to nodes, there will be more cases where the modifiers and geometry nodes will share code. To avoid adding more specific geometry operations to `blenkernel`, we could have a new module for this shared logic. **Proposal** - Add a geometry kernel module `./source/blender/geomkernel`. ``` This fits above blenkernel/bmesh, and below modifiers, geometry-nodes & editors. ``` - Operations associated with modifiers nodes would be moved here from `blenkernel` (boolean, mirror, voxel). - This would not be spesific to mesh data, it can contain mesh/curve/point-cloud/voxel operations. - Low level (core operations) such as custom-data API, data validation would remain in BKE. - High level operations (window manager, operators ... etc), would remain in editors. - When porting modifiers to nodes, shared operations would be added to this module. **Open Topics** - Naming, the name kernel indicates this is lower level than it is, could be called `geom_ops`... or something that indicates this is intended for shared geometry manipulation functions. - Choose a common naming prefix for headers & functions. - Exactly which BKE modules to move to this module initially. As already stated (boolean, mirror, remesh_voxel, fair), others could be moved later.

Campbell Barton commented

2021-03-24 03:55:57 +01:00

Added subscriber: @ideasman42

Kenzie commented

2021-03-24 04:02:58 +01:00

Added subscriber: @KenzieMac130

Jacques Lucke commented

2021-03-24 10:37:11 +01:00

Added subscriber: @JacquesLucke

Howard Trickey commented

2021-03-24 12:41:11 +01:00

Added subscriber: @howardt

Howard Trickey commented

2021-03-24 12:41:11 +01:00

I think this is about gathering together the transformational operations that work directly on the kernel-level (DNA-defined) object data. Kind of like what is in bmesh/tools (mostly) for transformation operations on mesh data in bmesh form.

To me, the name geom_ops seems a little better than geomkernel. What prefix would be good for the public API functions of the module? BGE would be nice if there's no possible confusion with old game engine. Else maybe BGM? What about for interfaces defined in C++? I think we have not used prefixes for public C++ API functions but rather have put them in a namespace made up for the general area that the operation is for. Is that a good practice to continue?

I think we should encourage new interfaces in this new module to be written in C++, though there will be a need for C=interface wrappers for them as long as we need to call these functions from modifiers.

I think this is about gathering together the transformational operations that work directly on the kernel-level (DNA-defined) object data. Kind of like what is in bmesh/tools (mostly) for transformation operations on mesh data in bmesh form. To me, the name geom_ops seems a little better than geomkernel. What prefix would be good for the public API functions of the module? BGE would be nice if there's no possible confusion with old game engine. Else maybe BGM? What about for interfaces defined in C++? I think we have not used prefixes for public C++ API functions but rather have put them in a namespace made up for the general area that the operation is for. Is that a good practice to continue? I think we should encourage new interfaces in this new module to be written in C++, though there will be a need for C=interface wrappers for them as long as we need to call these functions from modifiers.

Brecht Van Lommel commented

2021-03-28 22:43:31 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-03-28 22:43:31 +02:00

I suggest a folder structure like this and using prefix GEO_.

geometry/common/
geometry/bmesh/
geometry/curve/
geometry/mesh/
geometry/metaball/
geometry/multires/
geometry/subdiv/
geometry/volume/

Note sure why we would need to call it "kernel" or "ops". I'd make it the place to move most geometry related functions that are now in blenkernel.

I suggest a folder structure like this and using prefix `GEO_`. ``` geometry/common/ geometry/bmesh/ geometry/curve/ geometry/mesh/ geometry/metaball/ geometry/multires/ geometry/subdiv/ geometry/volume/ ``` Note sure why we would need to call it "kernel" or "ops". I'd make it the place to move most geometry related functions that are now in blenkernel.

Campbell Barton commented

2021-04-09 01:38:44 +02:00

@brecht seems fine, the term kernel would be to signify this isn't "editor" level. That these are low level transformations on geometry.

For example, modifiers now contain WM/operator code which I'd rather not creep in to this module.

As for naming GEO_ is already used: ./source/blender/blenkernel/BKE_geometry_set.h (not using BKE prefix, tsk).

Prefer BGE_ or BGM_.

@brecht seems fine, the term kernel would be to signify this isn't "editor" level. That these are low level transformations on geometry. For example, modifiers now contain WM/operator code which I'd rather not creep in to this module. ---- As for naming `GEO_` is already used: `./source/blender/blenkernel/BKE_geometry_set.h` (not using BKE prefix, tsk). Prefer `BGE_` or `BGM_`.

Jacques Lucke commented

2021-04-09 09:57:41 +02:00

I don't care too much about whether we call the new folder geometry or geomkernel or whatever. Either way is fine with me, however if I had to choose, I'd go with geometry as well.

I think the prefix GEO_ is the most obvious, but again, I don't care too much.

What about for interfaces defined in C++? I think we have not used prefixes for public C++ API functions but rather have put them in a namespace made up for the general area that the operation is for. Is that a good practice to continue?

I do wonder what others think about that as well. Namespace pretty much serve the same purpose as the prefixes, so using both is somewhat redundant.

I don't care too much about whether we call the new folder `geometry` or `geomkernel` or whatever. Either way is fine with me, however if I had to choose, I'd go with `geometry` as well. I think the prefix `GEO_` is the most obvious, but again, I don't care too much. ---- > What about for interfaces defined in C++? I think we have not used prefixes for public C++ API functions but rather have put them in a namespace made up for the general area that the operation is for. Is that a good practice to continue? I do wonder what others think about that as well. Namespace pretty much serve the same purpose as the prefixes, so using both is somewhat redundant.

Jacques Lucke commented

2021-06-08 17:19:08 +02:00

@ideasman42 Why do you prefer BGE_ or BGM_ over GEO_?

@ideasman42 Why do you prefer `BGE_` or `BGM_` over `GEO_`?

Campbell Barton commented

2021-06-10 09:47:15 +02:00

The reason I wanted to avoid using GEO is that it's already used in quite a few places, a quick search shows up 600+ uses of "\bGEO_", mostly defined in BKE_node & BKE_geometry.

If this distinction was made clearer by moving some of these definitions into the geometry module... or by renaming them and leaving them in BKE - I think it's fine.

The reason I wanted to avoid using GEO is that it's already used in quite a few places, a quick search shows up 600+ uses of `"\bGEO_"`, mostly defined in `BKE_node` & `BKE_geometry`. If this distinction was made clearer by moving some of these definitions into the geometry module... or by renaming them and leaving them in BKE - I think it's fine.

Jacques Lucke commented

2021-06-10 09:57:40 +02:00

Ah I see. Those are almost exclusively constants/enums from what I can see. Personally, I'm not too concerned about those, but I can see that they might be confusing for some. We could use a different prefix for the GeometryComponentType enum. As for all the GEO_NODE_* defines in BKE_node.h, I hope that we can remove them eventually. The idname of nodes is used to identify them anyway.

When hearing BGE_ I always think of the game engine, so that prefix feels wrong. BGM_ seems fine, although I don't remember what that stands for exactly.

Ah I see. Those are almost exclusively constants/enums from what I can see. Personally, I'm not too concerned about those, but I can see that they might be confusing for some. We could use a different prefix for the `GeometryComponentType` enum. As for all the `GEO_NODE_*` defines in `BKE_node.h`, I hope that we can remove them eventually. The idname of nodes is used to identify them anyway. When hearing `BGE_` I always think of the game engine, so that prefix feels wrong. `BGM_` seems fine, although I don't remember what that stands for exactly.

Campbell Barton commented

2021-06-10 14:05:41 +02:00

These kinds of discussions could happen in chat.

BGE for the game-engine is historic and I don't see the issue with reusing the name, B is hint this is Blender module, it fits with (BKE/BLI/BGE).

It others prefer GEO or BGM, I'm not that fussed :)
although in it's current form using GEO naming should not be mixed as much as it is currently with BKE.

*These kinds of discussions could happen in chat.* `BGE` for the game-engine is historic and I don't see the issue with reusing the name, `B` is hint this is Blender module, it fits with (BKE/BLI/BGE). It others prefer `GEO` or `BGM`, I'm not _that_ fussed :) although in it's current form using `GEO` naming should not be mixed as much as it is currently with `BKE`.

Hans Goudey commented

2021-06-10 16:35:03 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-06-10 16:35:03 +02:00

I prefer GEO, it's simple in that it's just the first three letters of "Geometry", which is the main abstraction for the module. I also agree with Jacques that we can remove many of the existing uses of GEO_.

I prefer `GEO`, it's simple in that it's just the first three letters of "Geometry", which is the main abstraction for the module. I also agree with Jacques that we can remove many of the existing uses of `GEO_`.

Henrik D. commented

2021-06-22 22:48:09 +02:00

Added subscriber: @HDMaster84

Ray molenkamp commented

2021-06-22 23:02:31 +02:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2021-06-22 23:02:31 +02:00

I do see issues with re-using the name there's 2 million+ hits on google for blender bge, if new/current developers are having issues with some code and they punch it into the google machine, it be real nice if they didn't have to battle through thousands of unrelated stack exchange issues , so beyond definitely not BGE I have no strong feelings on any of the alternatives.

I do see issues with re-using the name there's 2 million+ hits on google for `blender bge`, if new/current developers are having issues with some code and they punch it into the google machine, it be real nice if they didn't have to battle through thousands of unrelated stack exchange issues , so beyond definitely not `BGE` I have no strong feelings on any of the alternatives.

Campbell Barton commented

2021-06-23 04:13:30 +02:00

+1 for GEO then, it's most descriptive, although we should avoid naming collisions longer term.

+1 for `GEO` then, it's most descriptive, although we should avoid naming collisions longer term.

Bastien Montagne commented

2021-10-21 11:15:23 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2021-10-21 11:15:23 +02:00

Changed status from 'Needs Triage' to: 'Resolved'

Bastien Montagne closed this issue

2021-10-21 11:15:23 +02:00

Bastien Montagne self-assigned this 2021-10-21 11:15:23 +02:00

Bastien Montagne commented

2021-10-21 11:15:23 +02:00

Think this can be considered as done then, closing.

Sign in to join this conversation.

9 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#86869

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Create new geometry-kernel module #86869

Motivation