Hi all!

So, this is my first post and I tried to find pointers how to make a good post. I have searched information about geometry in Houdini and I wanted to ask something before continuing my studies.
I am a newbie with Houdini 19.5 / Windows 10 pro and I'd like to just ask something.

Here the next is what I would like you to confirm as a fact.

I have learned that in Houdini, points are just physical points with position (P) and maybe other point attributes. Position attribute generally is made of x,y and z coordinates of the corresponding point. @ptnum is used for indexing points and therefore every point has a unique @ptnum.

In Houdini, there are many types of primitives, which are typically used as "building blocks" for meshes for example. Primitives are also indexed by @primnum, much like @ptnum with points.

Vertices were really a bit harder to understand in Houdini. Now, my updated opinion about vertices is that, well, they "bind points to primitives" and vice versa. If I have a mesh with 200 polygons, quads, I then must have 200x4 vertices. First polygon of my mesh is defined by first four (vtxnum 0-3) vertices (and their corresponding point numbers). The second polygon of my mesh is made of next four vertices (vtxnum 4-7) and their corresponding point numbers. Also @vtxnum is an integer index value for a vertex.

Thank you for commenting my thoughts.

Janne Sopanen

You seem to have it right. The way I see it is that vertices are unique instances of a point for each primitive they are connected to, and are useful for attributes that can't be shared among all these instances. UV's and normals are the most common.

You can think of vertices as the connectors that connect a primitive to the points - which are essentially just 'locations in 3d space'.

Geometry and attributes, nodes, parameters and channels

Points vs vertices

Geometry have components for which the label "class" has been applied (5).

Let's begin with points. "KineFX treats joints as regular point geometry" (1). I know these points have position, rotation, and scale. A vertex however, only has a position. (Edit: we don't see this in the Geometry Spreadsheet, but the vertex must be positioned somewhere). This you can see if you export a geo (mesh) as an obj or other human readable format.

Geometry attributes can belong to any component class, but it has to be specified. Geometry attributes can be observed in the Pane "Inspectors > Geometry Spreadsheet". (4)

Points are categorized just below the object level (2), so I'd consider them to be a superset of vertices.


Vertices can be connected to additional information, or attributes if you will, such as vertex groups, UV:s and color information. (Edit: Confusingly, Houdini internally place color, Cd, by default at the Point component. UV:s are placed at the Vertex class. This may change during file export. You may also store Color and more information on Vertices, and then this attribute will override the same data from the Point [www.sidefx.com])

So this information focuses on geometry. In Houdini you work with nodes. These primarily have parameters (called parms). Once a parameter has been keyframed with changes it is called a channel. (3) Nodes also have categories (like classes), and you can read more about them in the (free) official book "Foundations".

1. Houdini Foundations [media.sidefx.com], SideFX, page 30
2. Foundations, page 12 (image attached)
3. Foundations, page 10
4. Foundations, page 11
5. Foundations, page 11

This book is also available in paper format.

SWest
Points are categorized just below the object level (2), so I'd consider them to be a superset of vertices.

terms point and vertex may be confusing as some softwares use vertex/vertices term to describe points
but in Houdini they are very different elements and one is not subset of another

SWest
A vertex however, only has a position

vertices in Houdini don't have position
every vertex is attached to a single point (or as described in docs [www.sidefx.com], it's a reference to a point) and therefore intrinsically vertex's position is position of the point it's attached to

maybe useful for someone.

tamte
terms point and vertex may be confusing as some softwares use vertex/vertices term to describe points
but in Houdini they are very different elements and one is not subset of another

Yeah, thanks for your clarification. Your point (no pun intended) is rather Houdini specific, however my perspective is including other software. So the exported geometry will then have the vertex position and the Houdini points will be lost in translation to some data formats. I'm aware that fbx is able to store skeleton data, which uses points, from Houdini. The vertices are actually elements that exist in the other class (thus being a subset). (Edit: correction, they are not elements that exist in the other class, but they share components or data)

tamte
vertices in Houdini don't have position
every vertex is attached to a single point (or as described in docs [www.sidefx.com], it's a reference to a point) and therefore intrinsically vertex's position is position of the point it's attached to

Sure, it would introduce complexity if you could use different (actual) positions for points than vertices. It is good to be specific like you are. This is called nuanced knowledge in my country (Sweden), but it requires an in-depth understanding. However, my statements are correct in a computer graphics context (I do have a BSc. in computer science and specifically graphics, and have have modeled since the early 90:s so I'll be stubborn here).

However, considering Computer Graphics as a science, and probably all other 3D modelers, the vertex will surely have a position, although in Houdini it is referenced as you pointed out. Probably this is used to avoid unnecessary complexity and for optimization. In programming you would say that a dictionary can have strings as data types although they are only referenced. Houdini will also export the vertex position when requested.



At first, it can seem confusing to have both points and vertices, however, when doing rigging it become absolutely clear that you need directions for joints. I've tried to replicate this with Blender and that failed. This is probably because Blender only has vertices as far as I know, and not points with rotation, and scale values as well. With Houdini you also can name each point which is important when making skeletons for KineFX rigs. The Armature in Blender is something different, and I'm not sure if this can be converted into a Houdini skeleton. Please note that I've not followed the development of Blender the last two years or so.

Anyway, thanks for you generous contribution as always Tamte. You've been contributing such a vast amount of knowledge through the years and I really appreciate it and respect you for that.

Here's another example with Points and Vertices



The Points hold the elements for position (P) and color (Cd).



The Houdini Vertices are holding the definition of the UV maps.

It is not until you export your geometry into standard formats that the attributes get into their proper place.

So, it is basically two sides of the same coin. How Houdini internally stores data and then how it is stored when exported. Probably you need to keep both in mind.

I'd also say that you should be careful to see @ptnum as an index for points. @ptnum can change from frame to frame, or the ordering can sometimes change.

This image from Tamte's reference to the docs on Points vs Vertices. I'm thinking that those faces have to have vertices that they are "attached to". They do not seem to be the actual Points (P). Are these not the vertex positions that we do not see in the Geometry Spreadsheet? I was not able to recreate this with the Facet node.

Anyway, according to the Houdini docs about vertex attributes [www.sidefx.com] a Vertex class only support the following attributes:

"Diffuse Color, Alpha, Texture Coordinates, and Normal."

The Vertex class has access to locals such as TX, TY, TZ and these are exactly the same components as what the referenced Point has. I've not tested this out but I'm expecting that T strands for Translate which refer to movement or position. There are also a bunch of other locals that the vertex has access to. It just seems like SideFX simply decided to store T values on the Point, and let the vertices read that data. However, they must have this data otherwise they would be at world center. See Vertex Geometry Node [www.sidefx.com].

You seem to be thinking about Vertices and Points interchangeably

It's only semantics, names , they mean different thing in different softwares

In Houdini
Points are actual points in space that have P, and can have any other arbitrary attributes

Vertices are just a name for anchors that primitives use to attach to (or point to) points
They can also additionally have any other attributes except for P as they intrinsically inherit P from points they are attached to if the value is needed

You brought up Blender, so if you particularly compare Polygonal Meshes in Houdini and Blender then you can relate their element names like this
Houdini -> Blender
Point -> Vertex
Primitive -> Face
Vertex > Face Corner

Which hopefully clearly shows that what Houdini and Blender (and many other software) call vertex is completely different element and shouldn't be confused, that's why I think in this thread is best to stay Houdini centric to try to minimize that confusion

SWest


This image from Tamte's reference to the docs on Points vs Vertices. I'm thinking that those faces have to have vertices that they are "attached to". They do not seem to be the actual Points (P). Are these not the vertex positions that we do not see in the Geometry Spreadsheet? I was not able to recreate this with the Facet node.

that image shows the sphere after using Facet SOP/Unique points + Primitive SOP/DoTransformation/Scale 0.8(ish)
what Unique point does is it duplicates the Points and reattaches Vertices so that every Vertex has its own unique Point which results in every polygon corner being able to have independent position from any other as each of them now point to unique point in space

here is another docs page [www.sidefx.com] with a simple picture that may shed some light on the topic of geometry component names

This really help me get my head around it when i made the swap from max to houdini - https://www.tokeru.com/cgwiki/Points_and_Verts_and_Prims#Shadesails_and_verts_and_prims [www.tokeru.com]

Someone want to claim that the vertices in Houdini’s OpenGL vertex shaders or fragment shaders neither have positions?

SWest
Someone want to claim that the vertices in Houdini’s OpenGL vertex shaders or fragment shaders neither have positions?

not talking about OpenGL here, OP clearly stated he is interested in understanding what Point, Vertex and Primitive names mean in Houdini geometry specifically

Vertex in OpenGL I believe is equivalent to Point in Houdini, not directly to Vertex in Houdini
again, same word different meaning

Just because Houdini can use OGL Vertex Shaders it doesn't mean that the name Vertex means exactly the same thing as in SOPs

but again even Vertices in Houdini SOP geometry can return position as their position can be easily sampled from corresponding point which holds that position, so Vertices directly don't have to store duplicate position data
you can have 1000 Vertices all point to the same Point, so technically you have 1 point, 1 position data and 1000 pointers to the same point, no need to store 1000 duplicates of the same position

Yeah, I’ll agree on that, basically the ”how” things are arranged in Houdini.

There is also some interesting details in the docs about component classes’ data (be it attributes or locals) being inherited and overridden. This has been barely touched in this thread so far. However, this I’ll study and test more another time.

Hatchery’s link does touch upon the ”why” it is like that question. In particular the Point class is supposed to support a vast array of data and nodes.

Another thing is, that there are different ways to count vertices. One way (like in the picture above from the document page) is starting from 0 for each primitive, which gives you relative vertex number for each primitive.
The other way is counting all vertices together, which is called linear vertex number/index. If you read a vertex number in VEX for example, it will usually give you the linear vertex index and not the primitive related number, but there are functions to convert them to each other.

In fact a vertex is always bound to a primitive (I don't know, where this is not the case). While a vertex is just point reference and nothing much more (there are not different types for vertices AFAIK) but on the opposite for primitives there multiple different types.
There are polygons and polylines for example (not the only ones).