Mesh Primitive Nodes #86391

New Issue

@MikhailRachinskiy If we were to do this we should remove the grid primitive which would be a breaking change, I also found that it is weird to have both grid and plane without much difference between them. However, I'm not sure if combining them is worth the breaking change.

I am all for combing them if possible though.

@MikhailRachinskiy If we were to do this we should remove the grid primitive which would be a breaking change, I also found that it is weird to have both grid and plane without much difference between them. However, I'm not sure if combining them is worth the breaking change. I am all for combing them if possible though.

Some User commented

2021-03-09 07:51:49 +01:00

Added subscriber: @someuser

Some User commented

2021-03-09 07:51:49 +01:00

hm, maybe it make sense to combine UV Sphere + ICO Sphere into 'Sphere' with a dropdown for 'UV/ICO'?

Aaron Carlisle commented

2021-03-09 08:11:16 +01:00

In #86391#1126594, @someuser wrote:
hm, maybe it make sense to combine UV Sphere + ICO Sphere into 'Sphere' with a dropdown for 'UV/ICO'?

These are two fundamentally different so it makes sense to leave them separate.

> In #86391#1126594, @someuser wrote: > hm, maybe it make sense to combine UV Sphere + ICO Sphere into 'Sphere' with a dropdown for 'UV/ICO'? These are two fundamentally different so it makes sense to leave them separate.

Mikhail Rachinskiy commented

2021-03-09 08:36:03 +01:00

If we were to do this we should remove the grid primitive...

Let's do that, Blender 3 is right around the corner and an ideal opportunity to get rid of the useless Grid primitive.

> If we were to do this we should remove the grid primitive... Let's do that, Blender 3 is right around the corner and an ideal opportunity to get rid of the useless Grid primitive.

Metin Seven commented

2021-03-09 09:46:25 +01:00

Added subscriber: @MetinSeven-1

Metin Seven commented

2021-03-09 09:46:25 +01:00

I'd ❤ to see a capsule primitive as well, to avoid the need for a Cylinder + Bevel + Weld.

Dalai Felinto commented

2021-03-09 09:46:36 +01:00

Grids and planes have different settings. Namely, grid allows for different X and Y subdivisions, while plane has no subdivision at all.

The idea is to implement the existing primitives as they are to avoid dealing with the design implications of changing one of the fundamental aspects of Blender.

The system is designed with building blocks in mind. In this case, primitives are to be exposed individually as possible (+ a point primitive eventually) for simplicity sake.

Grids and planes have different settings. Namely, grid allows for different X and Y subdivisions, while plane has no subdivision at all. The idea is to implement the existing primitives as they are to avoid dealing with the design implications of changing one of the fundamental aspects of Blender. The system is designed with building blocks in mind. In this case, primitives are to be exposed individually as possible (+ a point primitive eventually) for simplicity sake.

Ludvik Koutny commented

2021-03-09 09:48:58 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2021-03-09 09:48:58 +01:00

I'd remove the grid primitive, but the plane primitive should have "Subdivisions" parameter then. It should default to 1 though, so by default it's just a single quad plane. But having plane and grid as two separate things was indeed a bit silly.

The "The idea is to implement the existing primitives as they are to avoid dealing with the design implications of changing one of the fundamental aspects of Blender." is probably the weakest argument one could come up with to argue against consolidating plane and grid primitives.

Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are.

"Let's keep it that way because it was always that way" is a really poor argument. Furthermore, what are the practical implications of removing grid and adding subdivs parameters to the plane? Can you come up with a practical example how that would break any existing workflow?

Also, I think Torus is the last common primitive that's missing in the list, but perhaps users are expected to "solidify the circle" or something...?

I'd remove the grid primitive, but the plane primitive should have "Subdivisions" parameter then. It should default to 1 though, so by default it's just a single quad plane. But having plane and grid as two separate things was indeed a bit silly. The "The idea is to implement the existing primitives as they are to avoid dealing with the design implications of changing one of the fundamental aspects of Blender." is probably the weakest argument one could come up with to argue against consolidating plane and grid primitives. Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are. "Let's keep it that way because it was always that way" is a really poor argument. Furthermore, what are the practical implications of removing grid and adding subdivs parameters to the plane? Can you come up with a practical example how that would break any existing workflow? Also, I think Torus is the last common primitive that's missing in the list, but perhaps users are expected to "solidify the circle" or something...?

Trung Phạm commented

2021-03-09 09:50:29 +01:00

Added subscriber: @zNight

Metin Seven commented

2021-03-09 09:51:24 +01:00

I think Torus is the last common primitive that's missing in the list.

That'd be very welcome too, maybe along with a 2D Disc (Circle with hole) and/or a 3D Ring primitive (Torus with a square profile).

> I think Torus is the last common primitive that's missing in the list. That'd be very welcome too, maybe along with a 2D Disc (Circle with hole) and/or a 3D Ring primitive (Torus with a square profile).

Mikhail Rachinskiy commented

2021-03-09 10:35:44 +01:00

@dfelinto
grid allows for different X and Y subdivisions

But is it enough reason to justify another node?

> @dfelinto > grid allows for different X and Y subdivisions But is it enough reason to justify another node?

Aman Kumar commented

2021-03-09 23:18:03 +01:00

Added subscriber: @AmanKumar-2

Hans Goudey commented

2021-03-10 22:24:06 +01:00

I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other.

I will hold off implementing grid / plane for a bit in case I hear a convincing argument for combining them though.

I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other. I will hold off implementing grid / plane for a bit in case I hear a convincing argument for combining them though.

Aaron Carlisle commented

2021-03-10 23:38:11 +01:00

I think its mostly a consistency/simplicity thing, for example, the UV Sphere lets you define the number of segments and rings.
Also in practice, I don't seem many tutorials make use of the grid primitive, it is usually: add a plane then subdivide in edit mode. So if they were one it would make improve discoverability.

Also, the term "Grid" is a bit misleading in its current implementation because it only allows for 2D grids, however more grid types are possible see: https://en.wikipedia.org/wiki/Regular_grid

I see the argument both ways, on one hand, there is feature discoverability/simplicity and on the other hand there is geometrical correctness.

I think its mostly a consistency/simplicity thing, for example, the UV Sphere lets you define the number of segments and rings. Also in practice, I don't seem many tutorials make use of the grid primitive, it is usually: add a plane then subdivide in edit mode. So if they were one it would make improve discoverability. Also, the term "Grid" is a bit misleading in its current implementation because it only allows for 2D grids, however more grid types are possible see: https://en.wikipedia.org/wiki/Regular_grid I see the argument both ways, on one hand, there is feature discoverability/simplicity and on the other hand there is geometrical correctness.

Kenzie commented

2021-03-11 02:15:46 +01:00

Added subscriber: @KenzieMac130

Kenzie commented

2021-03-11 02:15:46 +01:00

In #86391#1127702, @HooglyBoogly wrote:
I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other.

I will hold off implementing grid / plane for a bit in case I hear a convincing argument for combining them though.

Cubes could also receive XYZ divisions, Once they do what is the point of the grid/plane being separate?

> In #86391#1127702, @HooglyBoogly wrote: > I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other. > > I will hold off implementing grid / plane for a bit in case I hear a convincing argument for combining them though. Cubes could also receive XYZ divisions, Once they do what is the point of the grid/plane being separate?

Charlie Jolly commented

2021-03-11 03:25:29 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-03-11 03:25:29 +01:00

In #86391#1126624, @Rawalanche wrote:
Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are.

I agree, I think this is a good opportunity to take a second look at the primitives and make them better. Primitives can also be grouped together where it is logical. Assuming that the primitives are parametric they also need to have better resolution control such as ring counts for cylinders and cones or subdivisions. Adding subsurface nodes in such cases is not the same.

Example:
Circle(Radius, Vertices or Sides) + Fill Type
**Cylinder:**Cylinder (Radius, Depth, Rings) & Tube (Radius, Depth, Inner Radius, Rings) + Fill Type
Cone (Radius, Depth, Radius 2, Rings) + Fill Type
**Plane:**Plane (Size, Subdivisions)
Cube: Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions)
**Sphere:**UV Sphere (Radius, Segments, Rings) & Ico Sphere (Radius, Subdivisions)
Platonic (Size, Type)
Torus(Segments x2, Radius x 2)

> In #86391#1126624, @Rawalanche wrote: > Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are. I agree, I think this is a good opportunity to take a second look at the primitives and make them better. Primitives can also be grouped together where it is logical. Assuming that the primitives are parametric they also need to have better resolution control such as ring counts for cylinders and cones or subdivisions. Adding subsurface nodes in such cases is not the same. Example: **Circle**(Radius, Vertices or Sides) + Fill Type **Cylinder:**Cylinder (Radius, Depth, Rings) & Tube (Radius, Depth, Inner Radius, Rings) + Fill Type **Cone** (Radius, Depth, Radius 2, Rings) + Fill Type **Plane:**Plane (Size, Subdivisions) **Cube:** Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions) **Sphere:**UV Sphere (Radius, Segments, Rings) & Ico Sphere (Radius, Subdivisions) **Platonic** (Size, Type) **Torus**(Segments x2, Radius x 2)

Some User commented

2021-03-11 06:53:42 +01:00

In #86391#1127829, @CharlieJolly wrote:

In #86391#1126624, @Rawalanche wrote:
Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are.

I agree, I think this is a good opportunity to take a second look at the primitives and make them better. Primitives can also be grouped together where it is logical. Assuming that the primitives are parametric they also need to have better resolution control such as ring counts for cylinders and cones or subdivisions. Adding subsurface nodes in such cases is not the same.

Example:
Circle(Radius, Vertices or Sides) + Fill Type
**Cylinder:**Cylinder (Radius, Depth, Rings) & Tube (Radius, Depth, Inner Radius, Rings) + Fill Type
Cone (Radius, Depth, Radius 2, Rings) + Fill Type
**Plane:**Plane (Size, Subdivisions)
Cube: Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions)
**Sphere:**UV Sphere (Radius, Segments, Rings) & Ico Sphere (Radius, Subdivisions)
Platonic (Size, Type)
Torus(Segments x2, Radius x 2)

for the cylinder and cone i propose to add not only rings, but also how many vertices the base will have in order to create for example a pyramid (3-4 vertices at the base) using cone primitive

> In #86391#1127829, @CharlieJolly wrote: >> In #86391#1126624, @Rawalanche wrote: >> Right now, a whole new modeling system is being designed and created in Blender, which is a perfect opportunity to fix the legacy mistakes, such as plane and grid being two separate things. If it's not done now, it will only get harder and harder to change it the more developed geometry nodes are. > > I agree, I think this is a good opportunity to take a second look at the primitives and make them better. Primitives can also be grouped together where it is logical. Assuming that the primitives are parametric they also need to have better resolution control such as ring counts for cylinders and cones or subdivisions. Adding subsurface nodes in such cases is not the same. > > Example: > **Circle**(Radius, Vertices or Sides) + Fill Type > **Cylinder:**Cylinder (Radius, Depth, Rings) & Tube (Radius, Depth, Inner Radius, Rings) + Fill Type > **Cone** (Radius, Depth, Radius 2, Rings) + Fill Type > **Plane:**Plane (Size, Subdivisions) > **Cube:** Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions) > **Sphere:**UV Sphere (Radius, Segments, Rings) & Ico Sphere (Radius, Subdivisions) > **Platonic** (Size, Type) > **Torus**(Segments x2, Radius x 2) for the cylinder and cone i propose to add not only rings, but also how many vertices the base will have in order to create for example a pyramid (3-4 vertices at the base) using cone primitive

Hans Goudey commented

2021-03-11 07:13:46 +01:00

If no one has stated otherwise, just assume that these nodes will have the same settings as their counterparts in the add menu. We can always expose new options in the future-- one I thought of today was a separate choice for the fill type of the top and bottom of a cylinder. I'll post a patch tomorrow morning with all of these nodes.

Maybe the reason people tend not to use the grid primitive is that they like the simplicity of the plane primitive. Also, it's quite common to add a simpler "reduced scope" version of more complex features, i.e. adding a plane node when you can still achieve the same result with a grid node. I'm not saying we shouldn't combine them, just that there should be a good reason to change direction.

If no one has stated otherwise, just assume that these nodes will have the same settings as their counterparts in the add menu. We can always expose new options in the future-- one I thought of today was a separate choice for the fill type of the top and bottom of a cylinder. I'll post a patch tomorrow morning with all of these nodes. Maybe the reason people tend not to use the grid primitive is that they like the simplicity of the plane primitive. Also, it's quite common to add a simpler "reduced scope" version of more complex features, i.e. adding a plane node when you can still achieve the same result with a grid node. I'm not saying we shouldn't combine them, just that there should be a good reason to change direction.

Ludvik Koutny commented

2021-03-11 09:19:40 +01:00

In #86391#1127702, @HooglyBoogly wrote:
I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other.

UI Clutter. There's simply no justification to add one whole primitive when an other primitive can already do the same job. Plane is really just a grid with 0 subdivision. Grid is really just a plane with multiple subdivisions.

When you look at many tutorials on YouTube, you often see people mention this sequence: Add a plane, enter edit mode and press subdivide a few times. Many people don't even know or always forget that there's actually a grid, because it's all the way at the bottom. This is just typical Blender approach of having a complexity just for the sake of having complexity.

> In #86391#1127702, @HooglyBoogly wrote: > I've got to ask, what's the downside of having both the plane and grid nodes? If you need subdivisions you use a grid, and if you just want a simpler node and no subdivisions, you use the plane. It's not like having one prevents you from using the other. UI Clutter. There's simply no justification to add one whole primitive when an other primitive can already do the same job. Plane is really just a grid with 0 subdivision. Grid is really just a plane with multiple subdivisions. When you look at many tutorials on YouTube, you often see people mention this sequence: Add a plane, enter edit mode and press subdivide a few times. Many people don't even know or always forget that there's actually a grid, because it's all the way at the bottom. This is just typical Blender approach of having a complexity just for the sake of having complexity.

Metin Seven commented

2021-03-11 09:54:47 +01:00

Removed subscriber: @MetinSeven-1

Dalai Felinto commented

2021-03-11 10:29:40 +01:00

Hi, this task is a todo for the geometry nodes project. The arguments against grid were made, heard and appreciated. There is no need to reiterate over the points already made. Any new angles/arguments are still welcome.

Some general remarks about the contribution process for this project in particular. A lot of this applies to Blender in general though:

If something is not clear, the team is always available to clarify it.
If you are an artist please contribute by using the system and sharing your artwork, process and experience.
In this case if you are using the system and is encountering any limitation to achieve something please let the team know on devtalk .
If you are a developer there are plenty of open tasks in the community column of geometry nodes board to be picked, please help.
If you are a designer and want to contribute with design, please reach out to the team to find out which current problems are being solved so you can help with design proposals on those. You can also look at the [workboard ]] or the [ https:*wiki.blender.org/wiki/Projects/Geometry_Nodes#Sprints | latest sprint to find what the focus is at the moment.

Hi, this task is a todo for the geometry nodes project. The arguments against grid were made, heard and appreciated. There is no need to reiterate over the points already made. Any new angles/arguments are still welcome. Some general remarks about the contribution process for this project in particular. A lot of this applies to Blender in general though: * If something is not clear, the team is always available to clarify it. * If you are an artist please contribute by using the system and sharing your artwork, process and experience. * In this case if you are using the system and is encountering any limitation to achieve something please let the team know on [devtalk ](https://devtalk.blender.org/t/geometry-nodes/16108). * If you are a developer there are plenty of open tasks in the community column of [geometry nodes board ](https://developer.blender.org/project/board/121/) to be picked, please help. * If you are a designer and want to contribute with design, please reach out to the team to find out which current problems are being solved so you can help with design proposals on those. You can also look at the [workboard ]] or the [[ https:*wiki.blender.org/wiki/Projects/Geometry_Nodes#Sprints | latest sprint ](https:*developer.blender.org/project/board/121/) to find what the focus is at the moment.

Erindale commented

2021-03-11 16:03:10 +01:00

I would like to see a Line primitive node where you could set length, total vertices (2+) and align to which axis. I think that would be valuable in terms of raw procedural generation functionality. (Although you can just as easily reverse engineer a circle primitive with math nodes if there was an option there to not close the loop)

Hans Goudey commented

2021-03-11 16:31:42 +01:00

Good idea @Erindale! I think I would use a rotation input instead of an axis choice though.

Rafael Campos commented

2021-03-11 17:09:54 +01:00

Added subscriber: @Rafafcdk

Rafael Campos commented

2021-03-11 17:09:54 +01:00

I think a good solution for the Line primitive would be to allow for two modes, one where you create a line of a fixed length by using 2 vectors (start and end points of the line) and interpolate the vertices over that line and another where the line grows to a certain direction the more vertices you add. I set to work on something like that as way of getting more familiar with the codebase for nodes but I ve had quite a busy week with other things getting in the way of that. Hopefully I can get something working by the weekend.