# Mesh Primitive Nodes #86391

Closed
opened 2021-03-08 14:39:14 +01:00 by Dalai Felinto · 45 comments
Owner
• Line
• Cube
• Circle
• UV Sphere
• Ico Sphere
• Cylinder
• Cone
• Plane/Grid
- Line - Cube - Circle - UV Sphere - Ico Sphere - Cylinder - Cone - Plane/Grid
Author
Owner

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

Changed status from 'Needs Triage' to: 'Confirmed'
Author
Owner

self-assigned this 2021-03-09 04:34:57 +01:00
Member

Member

Could it be possible to skip Grid node primitive, and promote Plane + Subdivide combination instead?

Could it be possible to skip Grid node primitive, and promote Plane + Subdivide combination instead?

Torus for the eventual GN Doughnut Tutorial ..? :)

Torus for the eventual GN Doughnut Tutorial ..? :)
Member

Member

@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.

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

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

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.
Member

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.

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

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

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.
Contributor

Contributor

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...?

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).
Member

@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?

Member

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.
Member

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.
Contributor

Contributor

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?
Member

Member

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
**Plane:**Plane (Size, Subdivisions)
Cube: Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions)
Platonic (Size, Type)

> 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#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
**Plane:**Plane (Size, Subdivisions)
Cube: Cube (Size, Subdivisions) & Cuboid (Width, Height, Subdivisions)
Platonic (Size, Type)

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

Member

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.
Contributor

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.

Removed subscriber: @MetinSeven-1

Removed subscriber: @MetinSeven-1
Author
Owner

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.

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)

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)
Member

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

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

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.

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.
Contributor

Contributor

Suzanne is missing in the list :)

Suzanne is missing in the list :)

cuz animal rights activists are against procedural experiments on a poor monkey

cuz animal rights activists are against procedural experiments on a poor monkey
changed title from Primitives mesh nodes to Mesh Primitive Nodes 2021-03-14 03:36:34 +01:00

This issue was referenced by `9a56a3865c`

This issue was referenced by 9a56a3865c06b472ac54c0351e270dcf738add07
Author
Owner

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

This issue was referenced by `22ba85b510`

This issue was referenced by 22ba85b510210d623e06174d0b73996585bf36fc

still have no UVs

still have no UVs
No Label
No Milestone
No project
No Assignees
17 Participants