Mesh Primitive Nodes #86391

Closed
opened 2021-03-08 14:39:14 +01:00 by Dalai Felinto · 45 comments
  • 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

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Added subscriber: @Erindale

Added subscriber: @Erindale
Hans Goudey self-assigned this 2021-03-09 04:34:57 +01:00

Added subscriber: @MikhailRachinskiy

Added subscriber: @MikhailRachinskiy

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?

Added subscriber: @Leul

Added subscriber: @Leul

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

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

Added subscriber: @Blendify

Added subscriber: @Blendify
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.

Added subscriber: @someuser

Added subscriber: @someuser

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.

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.

Added subscriber: @MetinSeven-1

Added subscriber: @MetinSeven-1

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

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
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...?

Added subscriber: @zNight

Added subscriber: @zNight

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

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

Added subscriber: @AmanKumar-2

Added subscriber: @AmanKumar-2
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

Added subscriber: @KenzieMac130

Added subscriber: @KenzieMac130
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

Added subscriber: @CharlieJolly

Added subscriber: @CharlieJolly
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
**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)

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

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.

Added subscriber: @Rafafcdk

Added subscriber: @Rafafcdk

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

Added subscriber: @Raimund58

Added subscriber: @Raimund58
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
Hans Goudey 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

Added subscriber: @ramonkarlos

Added subscriber: @ramonkarlos

still have no UVs

still have no UVs
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#86391
No description provided.