Data Type Names #71384

New Issue

Jacques Lucke · 2019-11-06T15:41:27+01:00

Jacques Lucke commented

2019-11-06 15:41:27 +01:00

Currently, Blender exposes only very few data types to users in node editors.
The main types are Value, Integer, Vector and Color.
Unfortunately, more types are required when we want to give users more possibilities.
New types will become very useful when they are usable in a more general purpose node tree and when we want to let users define custom attributes on e.g. mesh vertices.

Examples for types that might become necessary are vectors of various dimensions of floats and integers.
Furthermore, we really need a boolean type.

Besides these simple types, there are a couple more complex types, that might become important in the future.
Namely matrices of various sizes, text and different float and integer sizes.

When we have more types, giving them precise names using some naming convention is important.
Especially the current name Value might be too generic and should be replaced in my opinion.

To get some inspiration for how to name data types in 3D software, I checked the docs of some other applications.
The names below might not be 100% correct in all cases, but this is what I found in their docs.
Having this overview hopefully helps to decide what we want to have for Blender.

Shading Nodes in Blender: Value, Integer, Vector, Color
Animation Nodes: Float, Integer, Vector, Text, Matrix, Color, Boolean
Houdini: int, float, vector2, vector, vector4, array, struct, matrix2, matrix3, matrix, string
Softimage ICE: scalar, integer, rotation, location, 2D vector, 3D vector, color, Boolean, 3x3 matrix, color
Unreal Blueprint: Boolean, Byte, Integer, Integer64, Float, Name, String, Text, Vector, Rotator, Transform
Maya Bifrost:

  bool, signed/unsigned char, signed short int, double, string, char3, float3, double4, int3x3, ulong4x4, ....
  Grouped in the UI, similar types have the same color (e.g. 2d, 3d and 4d vectors; all matrix types; integers of all types; decimal values)

Max Creation Graph: sInt32, Single, Boolean, String, Matrix, Quaternion, Vector3

Various aspects need to be considered when picking a naming scheme:

Similar types should have similar names.
Should data type names be familiar to technical users?
What is a good compromise between precise names like int32 and simple names to be displayed in the UI like Integer?
Should there be two versions of every type name for different kinds of users?
Should type names contain spaces (can be important when their are used in file names or programming languages)?

I do not have a strong opinion on what the names should be exactly. I'd just like to get some feedback to decide which naming scheme to use.

Currently, Blender exposes only very few data types to users in node editors. The main types are `Value`, `Integer`, `Vector` and `Color`. Unfortunately, more types are required when we want to give users more possibilities. New types will become very useful when they are usable in a more **general purpose node tree** and when we want to let users define **custom attributes** on e.g. mesh vertices. Examples for types that might become necessary are vectors of various dimensions of floats and integers. Furthermore, we really need a boolean type. Besides these simple types, there are a couple more complex types, that might become important in the future. Namely matrices of various sizes, text and different float and integer sizes. When we have more types, giving them precise names using some naming convention is important. Especially the current name `Value` might be too generic and should be replaced in my opinion. To get some inspiration for how to name data types in 3D software, I checked the docs of some other applications. The names below might not be 100% correct in all cases, but this is what I found in their docs. Having this overview hopefully helps to decide what we want to have for Blender. - Shading Nodes in Blender: Value, Integer, Vector, Color - Animation Nodes: Float, Integer, Vector, Text, Matrix, Color, Boolean - Houdini: int, float, vector2, vector, vector4, array, struct, matrix2, matrix3, matrix, string - Softimage ICE: scalar, integer, rotation, location, 2D vector, 3D vector, color, Boolean, 3x3 matrix, color - Unreal Blueprint: Boolean, Byte, Integer, Integer64, Float, Name, String, Text, Vector, Rotator, Transform - Maya Bifrost: ``` bool, signed/unsigned char, signed short int, double, string, char3, float3, double4, int3x3, ulong4x4, .... Grouped in the UI, similar types have the same color (e.g. 2d, 3d and 4d vectors; all matrix types; integers of all types; decimal values) ``` - Max Creation Graph: sInt32, Single, Boolean, String, Matrix, Quaternion, Vector3 Various aspects need to be considered when picking a naming scheme: - Similar types should have similar names. - Should data type names be familiar to technical users? - What is a good compromise between precise names like `int32` and simple names to be displayed in the UI like `Integer`? - Should there be two versions of every type name for different kinds of users? - Should type names contain spaces (can be important when their are used in file names or programming languages)? I do not have a strong opinion on what the names should be exactly. I'd just like to get some feedback to decide which naming scheme to use.

Jacques Lucke self-assigned this 2019-11-06 15:41:27 +01:00

Jacques Lucke commented

2019-11-06 15:41:27 +01:00

Added subscribers: @JacquesLucke, @WilliamReynish

Duarte Farrajota Ramos commented

2019-11-06 16:24:04 +01:00

Added subscriber: @DuarteRamos

Robert Guetzkow commented

2019-11-06 16:37:48 +01:00

Added subscriber: @rjg

Duarte Farrajota Ramos commented

2019-11-06 16:40:07 +01:00

! In #71384, @JacquesLucke wrote:
Similar types should have similar names.
Should data type names be familiar to technical users?
What is a good compromise between precise names like int32 and simple names to be displayed in the UI like Integer?
Should there be two versions of every type name for different kinds of users?

Yes, similar/internally-compatible types would ideally have similar names.
Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips.

>! In #71384, @JacquesLucke wrote: >Similar types should have similar names. >Should data type names be familiar to technical users? >What is a good compromise between precise names like int32 and simple names to be displayed in the UI like Integer? >Should there be two versions of every type name for different kinds of users? Yes, similar/internally-compatible types would ideally have similar names. Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips.

Bent Hillerkus commented

2019-11-06 18:14:18 +01:00

Added subscriber: @bent

Robert Guetzkow commented

2019-11-08 15:33:51 +01:00

One aspect that should definitely be discussed here or as a follow up task is color coding for the sockets as you've mentioned in the Maya Bifrost bullet point. New data types will need a color that tells the user which sockets can be connected. With several new data types, especially ones with specific bit length, it could quickly become overloaded if we add a unique color per data type and it would be hard to know what sockets can be connected to each other. However using the same color for data types that can be converted / cast isn't great either, because if you allow connections between data types from higher to lower value range the user will get unintended scaling, wrap-around or clipping of values.

Duarte Farrajota Ramos commented

2019-11-08 16:26:54 +01:00

Indeed agree, given the potential amount of data types colors alone may be insufficient, though most listed implementations have around 10 ~11 data types.
Mapping those to colors I think we could manage 10 different enough hues.

One alternative is to additionally use different socket shapes (circle, square, triangle, star) combined with colors.
Shapes could indicate some sort of relation/compatibility between types, and maybe the increase in possible combinations is enough.

Indeed agree, given the potential amount of data types colors alone may be insufficient, though most listed implementations have around 10 ~11 data types. Mapping those to colors I think we could manage 10 different enough hues. One alternative is to additionally use different socket shapes (circle, square, triangle, star) combined with colors. Shapes could indicate some sort of relation/compatibility between types, and maybe the increase in possible combinations is enough.

Jacques Lucke commented

2019-11-08 18:48:39 +01:00

In #71384#806869, @DuarteRamos wrote:
Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips.

I agree. How are 2D and 3D vector of floats and ints called in "everyday language"?

Yes, 10 different data types can easily be encoded with colors. Animation Nodes has many more and it is ok still. One interesting aspect I'm not sure about yet is whether similar types should have similar colors. I noticed that sometimes it would be better to give them very different colors because e.g. int and float often appear in the same places and it is hard to tell them apart when they have a similar color. On the other hand, having very different data types with similar colors is not that bad, because it is more obvious that they are not compatible.

Another solution would be to just not use colors to encode types at all. Instead we could just write the types next to the sockets (as it is done in Max Creation Graph afaik). The best solution is probably somewhere in the middle.

I'd prefer not to use different socket shapes to encode different data types for now. We might need different shapes to encode even higher level information. For example, a different shape can be used when the socket is not even a data type but something else.

In general, I'd prefer to keep this discussion focused on the types we want to have and which names we want to give them. We can decide which colors/shapes to use afterwards.

> In #71384#806869, @DuarteRamos wrote: > Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips. I agree. How are 2D and 3D vector of floats and ints called in "everyday language"? Yes, 10 different data types can easily be encoded with colors. Animation Nodes has many more and it is ok still. One interesting aspect I'm not sure about yet is whether similar types should have similar colors. I noticed that sometimes it would be better to give them very different colors because e.g. int and float often appear in the same places and it is hard to tell them apart when they have a similar color. On the other hand, having very different data types with similar colors is not that bad, because it is more obvious that they are not compatible. Another solution would be to just not use colors to encode types at all. Instead we could just write the types next to the sockets (as it is done in Max Creation Graph afaik). The best solution is probably somewhere in the middle. I'd prefer not to use different socket shapes to encode different data types for now. We might need different shapes to encode even higher level information. For example, a different shape can be used when the socket is not even a data type but something else. In general, I'd prefer to keep this discussion focused on the types we want to have and which names we want to give them. We can decide which colors/shapes to use afterwards.

Duarte Farrajota Ramos commented

2019-11-08 19:12:35 +01:00

! In #71384#808078, @JacquesLucke wrote:
I agree. How are 2D and 3D vector of floats and ints called in "everyday language"?

Haha I don't have an answer for that. I guess "2D Float Vector" or "2D Value Vector" would have to do and a tooltip could show "2D Float Vector"

One interesting aspect I'm not sure about yet is whether similar types should have similar colors. I noticed that sometimes it would be better to give them very different colors because e.g. int and float often appear in the same places and it is hard to tell them apart when they have a similar color.

Good point. Then again very similar colors are easier to tell apart side by side, rather then being far between. Two similar shades of say orange are easier to distinguish if they are next to each other, and similar colors for related or interchangeable datatypes would help structure thought.

Another solution would be to just not use colors to encode types at all. Instead we could just write the types next to the sockets (as it is done in Max Creation Graph afaik).
I'd prefer not to use different socket shapes to encode different data types for now.

Another option is to use icons instead, next to sockets rather than full names. It seems more compact in terms of space.

Back on topic, is there a specific datatype for lists of things. Won't we need one for objects or list input like an Array?

>! In #71384#808078, @JacquesLucke wrote: > I agree. How are 2D and 3D vector of floats and ints called in "everyday language"? Haha I don't have an answer for that. I guess "2D Float Vector" or "2D Value Vector" would have to do and a tooltip could show "2D Float Vector" > One interesting aspect I'm not sure about yet is whether similar types should have similar colors. I noticed that sometimes it would be better to give them very different colors because e.g. int and float often appear in the same places and it is hard to tell them apart when they have a similar color. Good point. Then again very similar colors are easier to tell apart side by side, rather then being far between. Two similar shades of say orange are easier to distinguish if they are next to each other, and similar colors for related or interchangeable datatypes would help structure thought. > Another solution would be to just not use colors to encode types at all. Instead we could just write the types next to the sockets (as it is done in Max Creation Graph afaik). > I'd prefer not to use different socket shapes to encode different data types for now. Another option is to use icons instead, next to sockets rather than full names. It seems more compact in terms of space. Back on topic, is there a specific datatype for lists of things. Won't we need one for objects or list input like an Array?

Jacques Lucke commented

2019-11-08 20:15:04 +01:00

is there a specific datatype for lists of things. Won't we need one for objects or list input like an Array?

Yes, lists of float/vector/... will be data types as well. Whether we call this "Float List", "List of Float", "Multiple Floats", "Float Vector", "Vector of Floats", "Float Array", ... can be decided after we know how the base type will be called.

> is there a specific datatype for lists of things. Won't we need one for objects or list input like an Array? Yes, lists of float/vector/... will be data types as well. Whether we call this "Float List", "List of Float", "Multiple Floats", "Float Vector", "Vector of Floats", "Float Array", ... can be decided after we know how the base type will be called.

Robert Guetzkow commented

2019-11-08 20:38:35 +01:00

Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips.

I agree as well. Does it make sense to have data types with different ranges like short, int32, int64, e.g. for memory consumption or performance reasons?

My suggestion for the datatypes would be: Integer, Float, Boolean, String, Vector 3D, Vector 4D, Matrix 3x3, Matrix 4x4, Color. Creating arrays of each data type could be useful as well.

> Given the current efforts to make 2.8 UI more user oriented using less "programmer jargon", I'd say they should as much as possible be named using "everyday language" for non technical end users, without oversimplification. "Float" over "Value" would seem like an acceptable trade, or perhaps more technical terms like "int32" could be described in tooltips. I agree as well. Does it make sense to have data types with different ranges like short, int32, int64, e.g. for memory consumption or performance reasons? My suggestion for the datatypes would be: Integer, Float, Boolean, String, Vector 3D, Vector 4D, Matrix 3x3, Matrix 4x4, Color. Creating arrays of each data type could be useful as well.

Jacques Lucke commented

2019-11-08 20:44:44 +01:00

Does it make sense to have varying precision data types like short, int32, int64, e.g. for memory consumption or performance reasons?

One possible compromise is that we allow to have these specialized types when adding e.g. mesh attributes. However, node trees only process e.g. one specific integer type.

My suggestion for the datatypes would be: Integer, Float, Boolean, String, Vector 3D, Vector 4D, Matrix 3x3, Matrix 4x4, Color.

I guess Vector 2D should be added as well (for uvs). Houdini does something interesting, they skip the "3D" in the three dimensional case, so that it is just called Vector.
How about vectors of integers? I do not have a use case for it right now, does someone have an idea?

> Does it make sense to have varying precision data types like short, int32, int64, e.g. for memory consumption or performance reasons? One possible compromise is that we allow to have these specialized types when adding e.g. mesh attributes. However, node trees only process e.g. one specific integer type. > My suggestion for the datatypes would be: Integer, Float, Boolean, String, Vector 3D, Vector 4D, Matrix 3x3, Matrix 4x4, Color. I guess Vector 2D should be added as well (for uvs). Houdini does something interesting, they skip the "3D" in the three dimensional case, so that it is just called Vector. How about vectors of integers? I do not have a use case for it right now, does someone have an idea?

Robert Guetzkow commented

2019-11-08 23:13:54 +01:00

I guess Vector 2D should be added as well (for uvs).

Makes sense. Although with the different dimensions of vector and matrix, would higher dimensions be useful as well? I had something like filter kernels in mind, although perhaps not the most compelling use case.
One could have a socket that outputs a arbitrary dimensional matrix (same thing for a vector) for which the dimension would be known at compile / execution time and the corresponding input socket would need to work on arbitrary dimensions as well. It may not be a good idea or easy to implement, just putting the idea out there.

Houdini does something interesting, they skip the "3D" in the three dimensional case, so that it is just called Vector.

Seems inconsistent to me.

How about vectors of integers? I do not have a use case for it right now, does someone have an idea?

I don't have a specific use case on top of my head, but I can imagine cases where you'd want to avoid floating point precision issues.

> I guess Vector 2D should be added as well (for uvs). Makes sense. Although with the different dimensions of vector and matrix, would higher dimensions be useful as well? I had something like filter kernels in mind, although perhaps not the most compelling use case. One could have a socket that outputs a arbitrary dimensional matrix (same thing for a vector) for which the dimension would be known at compile / execution time and the corresponding input socket would need to work on arbitrary dimensions as well. It may not be a good idea or easy to implement, just putting the idea out there. > Houdini does something interesting, they skip the "3D" in the three dimensional case, so that it is just called Vector. Seems inconsistent to me. > How about vectors of integers? I do not have a use case for it right now, does someone have an idea? I don't have a specific use case on top of my head, but I can imagine cases where you'd want to avoid floating point precision issues.

Duarte Farrajota Ramos commented

2019-11-09 02:04:38 +01:00

! In #71384#808089, @JacquesLucke wrote:
How about vectors of integers? I do not have a use case for it right now, does someone have an idea?

Not sure I understand correctly, but perhaps useful for some sort of grid or increment snapping, voxel based volumetrics, or voxelized geometry or quantizing data.

>! In #71384#808089, @JacquesLucke wrote: > How about vectors of integers? I do not have a use case for it right now, does someone have an idea? Not sure I understand correctly, but perhaps useful for some sort of grid or increment snapping, voxel based volumetrics, or voxelized geometry or quantizing data.

Byungchul Kang commented

2019-11-12 13:15:16 +01:00

Added subscriber: @CGnDEV

Byungchul Kang commented

2019-11-12 13:15:16 +01:00

I vote Softimage and Animation Nodes styles. Because, more friendly to artists.

Bent Hillerkus commented

2019-11-13 12:27:35 +01:00

What kind of implicit conversion will be handled? For example if I plug a Color into a Vector socket? If similar types are being converted automatically, I guess we could have tendencially more types to allow power users to optimize

Jacques Lucke commented

2019-11-13 13:01:46 +01:00

Not sure I understand correctly, but perhaps useful for some sort of grid or increment snapping, voxel based volumetrics, or voxelized geometry or quantizing data.

Yes, that is what I meant.

What kind of implicit conversion will be handled? For example if I plug a Color into a Vector socket? If similar types are being converted automatically, I guess we could have tendencially more types to allow power users to optimize

Some types will be implicitly converted for sure. Whether we want to implicitly convert vectors and colors is debatable. I'd say no for now.

> Not sure I understand correctly, but perhaps useful for some sort of grid or increment snapping, voxel based volumetrics, or voxelized geometry or quantizing data. Yes, that is what I meant. > What kind of implicit conversion will be handled? For example if I plug a Color into a Vector socket? If similar types are being converted automatically, I guess we could have tendencially more types to allow power users to optimize Some types will be implicitly converted for sure. Whether we want to implicitly convert vectors and colors is debatable. I'd say no for now.

Bartosz Moniewski commented

2020-02-06 19:36:51 +01:00

Added subscriber: @BartekMoniewski

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Data Type Names #71384