String attribute

Archive Geometry Nodes
1

This topic is not a proposal (and please do not suggest anything that is not related to the plans of the module).

The reason for this topic is that now proposals have begun to appear that solve a narrow and specialized range of problems, the general solution of which will be the string attribute.

So let’s explore the possibilities of variable sized data as an attribute.

The first is that we now have an attribute field. This is important to clarify, because there is a technically big difference between an attribute (an array) and a field (a function in a context).

For an attribute (array), I will not describe functions, since there are none outside of nodes. And in nodes everything is simpler in either as a single or as in a context

First of all, we need to make string lines for each point. Of course, we will not make a switching node to enter a bunch of lines into the multisocket for each point, as input. It just doesn’t make sense.

Instead, a class of nodes is presented that, for each index entered, can return its own row.

That is, we can:

  1. Split the string to single letters: “abcd” → “a”, “b”, “c”, “d”.
  2. Split string by delimiters: “a+b=c”, “=” → “a+b”, “c”. “a+b”, “+” → “a”, “b”.
  3. Split the string into islands of scopes: “a + (a + d * 2) =”, “(”, “)” → "a + “, “a + b * 2”, " =”.

Agree, if you want, you can already make a language on this to describe your procedural model of a castle or a guitar
That is, if you want, you can how to decode the obj file, enter indexes, or describe the city

Further, we can transfer those nodes that are now in the field so that they can work for individual row instances.

Now new nodes capable of working in the field:

  1. The number of characters or parts of a string that are in the string: “abb,ccdd”, “ab” → 1.
  2. Case substitution (upper, lower): “abcd, ffAAff” → first : “Abcd, ffAAff”, all : “ABCD, FFAAFF”, invert : “ABCD, FFffFF”.
  3. Convert strings to numeric data types: “12324” → 12324, “1234.124” → 1234.124f
  4. String comparison: “abc” == “abc” → true
  5. Comparing characters in alphabetical order: “A. …” > “B. …” → true
  6. Adding Unicode characters to each other, which can be represented as x4 ordinary characters: “-” + “>” → " → "

The main use for strings, besides converting them to curves, is to interact with fields. Most of the procedural generation takes place on the basis of the fields, and strings act only as a way to enter these fields.

Also, you may have noticed that for the example of a node for converting a string to a number, I did not show vectors and logical or color ones.
The reason for this is that there may be different formatting:

  1. “true”, “yes”, “agree”, “t”.
  2. “false”, “no”, “f”.
  3. “<1,2,3>”, “{1,2,3,4}”, “(1,2,3,4)”, “1 2 3 4”.
    …

Any recording standard can be chosen and documented. But while this is not discussed, this is exclusively a user agreement.
All this leads to the fact that users can expand the possibilities and make the largest possible projects. To simply achieve the goal. It’s easy to reuse created groups and apply them to anything.

5 Likes
2

Visual aids will help imagining the concept further, describing the problem and solution we can take.

1 Like
3

Could you mention the range of problems you saw this to solve? Seems great, would simply like some examples to really get the idea

1 Like
4

In fact, after a lot of thinking, I realized that it’s better to use this topic as a place where at least someone can suggest a popular use case for the string attribute :rofl:. Other than creating my own programming language, I just don’t see what it’s better than a user interface for entering data about the model. For reading arbitrary files - perhaps. But then, it’s just functionality for custom obj importers.

1 Like
5

I think another aspect that has to be taken into account is the future of the text object. Not saying string attributes are going to be a part of it but better think about it. I think the natural evolution of the 3d text object would be such that geometry nodes had access to the text, and all text settings (extrude, bevel, font, size, etc) are applied via geometry nodes. That’s where curves are leaning to and it would be excellent if text did so to. Thus, there would be a need for some way to store and pass text in geometry nodes. It could be a string attribute (with tags for the boldness, etc).

2 Likes
6

Attributes of text symbols can be made already now from the point of view of instances.
And the text type, to support various formatting, looks at the same time too specific for unification in blender, and for user implementation. I don’t even know if text formatting should be the only benefit of text attribute processing.

7

I want to make a scatter func to generate foliage or instance to UE, so i need to save scale, orient and a string reference to unreal mesh, like houdini engine’ unreal_instance, but i found blender GN is not supported to store string attributes:

image
image1914×1030 386 KB

does string attribute is on roadmap? or i can use some other way to achieve my thoughts?

8

You need to generate the names as part of the storage file formatting.
It doesn’t make sense for blender to represent identifiers as strings. As a last resort, you can get the names of objects that are in instances.

Edit:
This was my answer in the context of the topic: Why do we need string attributes.
But if you wanted to ask, then the answer would be: there are no string attributes right now and I think you will need to use python to automate something like that.

9

My purpose is export blender pointcloud to UE4 foliage, and i have same flow in Houdini:

  1. Make PointCloud by Nodes
  2. Write cusomized plugin/addon to export point cloud
  3. Import point cloud from UE to instancing

But two problem came to me when i save my customized point cloud file:
A. I cannot get Native PointCloud(I find the PointCloudComponent in c++ Code) by python, and i solve this by convert Point to Mesh Vertex
B. I cannot save string point attribute, whick i need to use in my unreal plugin to determine use which asset to instance for each point

And I understand your suggestion to use name as data, but it’s a trick and actually i need two string attributes, as i say at problem 1, the name seems to cannot get by mesh vertex.

So if GN cannot save string attributes, i have to solve this by other way: make a string table and select by index for example, but i seems not the best solution…

10

I can give examples of materials. We cannot edit them, mix them, … in geometry nodes.
So, if they were material is attribute for face, what operations would be available to us for them? … set material, switch in mask, … … …
Same problem for strings. All you need is static storage. Just have a list of strings and id’s.
If you know what very useful things can be for a huge number of individual strings for each primitive - this topic want to know this too.

11

Where i use string attributes is:
1. point cloud as i say above
2. primitive material reference
both is working for unreal/unity plugins
I use houdini before, and want to explore blender’ func now, so inevitably would like to do same things which houdini can…>_<, below is what i export points to houdini:

[Moderation notice: Image removed, please see Copyright guidelines for devtalk for details]

The string attribute is fixed coded by python in blender

[Moderation notice: Image removed, please see Copyright guidelines for devtalk for details]

12

Hi. I’m new to this board and have just found this thread. However, I’m very much hoping for a string attribute to be introduced - and here’s the reason why. I work in the field of geospatial data, where we typically have collections of features that include both a geometry (typically real world coordinates, representing points, lines or polygons), along with any number of attributes relating to these geometries. Some of these attributes may be values, others may be bools, or dates, or strings. As it stands, I now have a custom importer Add-On that can import such geometries of all types, along with any value attributes (and, potentially, bools) that might be associated with them. However, when it comes to string attributes that exist in the source data, I can’t currently handle them at all, so they’re just being ignored for now. Potentially, such string attributes could be used to create text objects (like place names and such like), or, perhaps more significantly, they could used within Geometry Nodes just as a further means of choosing what gets created on a feature-by-feature basis.

I know, from various recent YouTube videos, that others (notably Erindale) have been experimenting with importing data from CSV, so it seems unlikely that I’m the only one hitting this limitation.

Of course, maybe I’m missing something and there’s some other method for handling this situation? I’m considering implementing some sort of text->enum work around, but that’s only going to be worthwhile in a subset of cases. Beyond that, I’m out of ideas.

13

Hello. The main problem with this is that you are talking about needing imports and exports. But nodes, it’s not a stop for translation-specific files. If you can’t work with strings, then you don’t need them.

14

Hi…thanks for the quick reply. Unfortunately, I’m not sure that I understand what you mean. I’m starting with data that exists outside of Blender (say, in a CSV file) that I’d like to be present within the Blender environment, so that I can access it from within Geometry Nodes. I’ve already written a Python importer that will handle such data - but there seems to be no option to store strings as Named Attributes, once the data has been read in. So, am I missing something?

15

So to speak.
Geometry nodes is a procedural geometry modeling tool.
If you can somehow use individual strings for each primitive in the node space, that’s very good. You can change their case, for example. You can sample random strings from other primitives, shuffle neighbors, … . In general, you have some useful things due to the fact that you have a bunch of lines that you can change.
Now the question is, if you can’t do that, all you want is to match the strings you entered earlier with the strings that will be exported. What then is the problem of just storing the row index in a temporary file in python, in order to exclude them from the work of geometry nodes? What is the use of geometry nodes from the fact that these will not be indexes to an external array of strings, but exactly what an attribute? Why do you need to do a lot of work in the nodes of geometry? If there is nothing that can be done with these strings, then should the nodes of the geometry think about them?

16

On top of what @modmoderVAAAA says: strings are a bit harder technically, currently. The system that is currently used to store attributes can’t really handle variable-sized data. You would need to store indices into a string table and manage all that… Not impossible but a lot of work. there are lots and lots and lots of things that still need to be done for GN, so we need to prioritize.

17

Again, thank you, both. When it comes to the technical difficulty of implementing string attributes, or their relative priority against other development tasks, then, of course, I can only accept what you have to say about that, as I have no inside knowledge of either of those aspects. All I can really do, to add to what has been posted previously, is to post my own reasons for wanting them in the first place, in case this adds to the overall story.

To add to what I posted previously, last summer, I undertook a project where I imported into Blender (via .obj), very simple geospatial geometries that had been extracted from a GIS system. So, these were very simple points, lines and polygons, that had been assigned a feature type and ‘heighted’ using a terrain model. Upon import in Blender, I’d then direct these into one of a collection of Geometry Nodes modifiers, which would then turn those basic geometries into more representative 3D features (with no manual work…). So, a single point geometry might become, say, a mobile phone mast and a simple polygon could become a forest. An example of such output is shown in the following image.

HinkleyPointSmall
HinkleyPointSmall1000×563 1.06 MB

At the time, what I REALLY wanted was to have attribution available to me that could further affect, on an individual basis, how the Geometry Nodes would build each individual feature. However, I didn’t, at the time, have any idea about how this might be possible. This meant, for example, that the building extrusions had to happen in a pre-process outside of Blender and that many other attributes available in my source data just had to be disregarded completely.

It was only more recently that I discovered how I could use CSV to import geometries and attributes together. So, I’ve since created my own importer, that takes that idea, but can handle the points, lines and polygons that I require. This now solves my problem, for example, of how to extrude the building polygons to their given heights (i.e. via a float height attribute…). However, many other attributes within my source data are strings, so it’s this that has then lead me to this thread. Potentially, as a limited work-around, I may be able to ennumerate some of the string attributes and make use of them in that way. However, there will inevitably be others where that is not possible. So, that’s where I’m coming from in my previous comments. I hope this is of interest!

Again, thanks for your replies.

1 Like
18

By the way: There actually is a string attribute. It’s just not exposed to geonodes I think. Because the system currently only supports fixed size data this adds a 256 byte character string (and a 1 byte stringlength) to each point in the domain. So this can get quite unwieldy for large meshes. For your case however it might be usable as long as you can fit your strings within 255 characters. This is however not really exposed in geometry nodes, because it’s not really usable in most cases without a more sparse storage method, afaik.

You could do it in a 2 step process though: in your importer import the string attribute. Then use some sort of hash function to generate a (32 bit signed) int from the strings and store that as well (in the same domain).

You could use the hashes from geonodes to do different things for different strings, but would still have the original string data in the file for use in python scripts or exporting.

Not ideal , but maybe useful?

1 Like
19

It doesn’t seem quite right. The attributes use the std::string. But she’s still big…

At least the field evaluation system…

20

Thanks for the suggestion, Baardaap. I hadn’t thought of using hashes for this purpose, but can immediately see how that might work. I’ll experiment! In most cases, 255 is more than enough for my purposes. Most string attributes I deal with are short classifications or names, rather than extended descriptions or blocks of text.

Again, thank you.