UI: Increase Node Label Name Limit From 63 to 255 Characters. #114378

Closed

Hoshinova wants to merge 1 commits from Hoshinova/blender:increase-label-name-limit into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.

Hoshinova commented

2023-11-01 21:18:20 +01:00

Member

This PR increases the node label name limit from 63 to 255 characters.
This allows node frames to be used as explanations for more complex mathematical relationships, which are getting more common especially with the quickly developing geometry nodes.

Here's an example from @Raiko

Since the use of unicode characters like π or θ take up 2 characters, we might even want to increase it beyond 255.

This PR increases the node label name limit from 63 to 255 characters. This allows node frames to be used as explanations for more complex mathematical relationships, which are getting more common especially with the quickly developing geometry nodes. Here's an example from @Raiko ![3.png](/attachments/8894eb11-c5e3-47d4-a922-1e5c63850313) Since the use of unicode characters like π or θ take up 2 characters, we might even want to increase it beyond 255.

26 KiB

Hoshinova added 1 commit 2023-11-01 21:18:36 +01:00

d7181d0be4 -- Increase node label name limit from 63 to 255 characters.

Leon Schittek added this to the Nodes & Physics project 2023-11-01 21:59:41 +01:00

Leon Schittek added the

label 2023-11-01 22:00:12 +01:00

Hans Goudey commented

2023-11-01 22:28:53 +01:00

Member

I don't think increasing the size of bNode by 192 bytes is worth it here.
For longer descriptions, a frame can already contain a text data-block.

I don't think increasing the size of `bNode` by 192 bytes is worth it here. For longer descriptions, a frame can already contain a text data-block.

Hoshinova commented

2023-11-02 21:25:31 +01:00

Author

Member

@HooglyBoogly I figured you'd say that however oftentimes you have dozens or in in some bigger projects even hundreds of node frames. You'd have to individually add dozens/hundreds of text data-blocks and link them to the corresponding node frames. Can you imagine how frustrating this gets over time. Apart from having to manually going through multiple steps of creating, writing and linking the text data-blocks, they also pile up over time.
Good luck making sure that Text.001 to Text.083 are all linked to the correct node frames.

Thus especially for bigger projects the node frame labels are the only real way to conveniently explain parts of the node tree and 63 characters are really just not enough for that. The label in the example image I PR already exceeds the 63 character limit and it's not even that long and descriptive. If you use unicode characters the limit drops to a mere 31 characters.

Some tricks I've seen to deal with this issue is artists doing stuff like using node frames around node frames to get some extra character space. Here's an example from a real production file:

If we were in the 1980s it'd make sense to argue over 192 additional bytes per node, but were well past that age now.
Modern SSD's offer multiple Terabytes of storage for cheap prices.
Just imagine an artist applying one subdivision level more than necessary on a model and the file size would increase more than those 192 additional bytes per node could ever cause.

@HooglyBoogly I figured you'd say that however oftentimes you have dozens or in in some bigger projects even hundreds of node frames. You'd have to individually add dozens/hundreds of text data-blocks and link them to the corresponding node frames. Can you imagine how frustrating this gets over time. Apart from having to manually going through multiple steps of creating, writing and linking the text data-blocks, they also pile up over time. Good luck making sure that `Text.001` to `Text.083` are all linked to the correct node frames. Thus especially for bigger projects the node frame labels are the only real way to conveniently explain parts of the node tree and 63 characters are really just not enough for that. The label in the example image I PR already exceeds the 63 character limit and it's not even that long and descriptive. If you use unicode characters the limit drops to a mere 31 characters. Some tricks I've seen to deal with this issue is artists doing stuff like using node frames around node frames to get some extra character space. Here's an example from a real production file: ![4.png](/attachments/ced76f2a-0b8d-4083-8208-01af7968828a) If we were in the 1980s it'd make sense to argue over 192 additional bytes per node, but were well past that age now. Modern SSD's offer multiple Terabytes of storage for cheap prices. Just imagine an artist applying one subdivision level more than necessary on a model and the file size would increase more than those 192 additional bytes per node could ever cause.

45 KiB

Hoshinova commented

2023-11-02 21:32:25 +01:00

Author

Member

It's also worth to be noted that this issue is really only prevalent with node frames. Instead of increasing the label size to 256 for all nodes we could also just have the node frame contain it's own separate label field. Then we could also add some more quality of life features like having the label be able to contain carriage returns, text styling like having *example* render as example or perhaps even support things like LaTeX.

What do you think @HooglyBoogly ?

It's also worth to be noted that this issue is really only prevalent with node frames. Instead of increasing the label size to 256 for all nodes we could also just have the node frame contain it's own separate label field. Then we could also add some more quality of life features like having the label be able to contain carriage returns, text styling like having `*example*` render as *example* or perhaps even support things like LaTeX. What do you think @HooglyBoogly ?

Hans Goudey commented

2023-11-02 22:16:58 +01:00

Member

Thanks for the background, but currently my opinion remains the same. The core node data structures are already much more bloated than they should be, and we've been trying to improve that. It's not the size on disk I care about really-- I assume empty strings are easily compressed away anyway-- the memory usage is much more important. Especially as we are pushing the direction of using complex node graphs in the background, exposed as high level groups, this is important. The node graph itself would ideally be negligible in terms of Blender's resource usage.

A better approach would probably be turning the label into an allocated string (the DNA equivalent of std::string). For that, I would prefer to rely on the longer term developments discussed here: https://devtalk.blender.org/t/dna-decentralization-and-c/30391

Thanks for the background, but currently my opinion remains the same. The core node data structures are already much more bloated than they should be, and we've been trying to improve that. It's not the size on disk I care about really-- I assume empty strings are easily compressed away anyway-- the memory usage is much more important. Especially as we are pushing the direction of using complex node graphs in the background, exposed as high level groups, this is important. The node graph itself would ideally be negligible in terms of Blender's resource usage. A better approach would probably be turning the label into an allocated string (the DNA equivalent of `std::string`). For that, I would prefer to rely on the longer term developments discussed here: https://devtalk.blender.org/t/dna-decentralization-and-c/30391

Hoshinova commented

2023-11-05 21:56:13 +01:00

Author

Member

A better approach would probably be turning the label into an allocated string (the DNA equivalent of std::string). For that, I would prefer to rely on the longer term developments discussed here: https://devtalk.blender.org/t/dna-decentralization-and-c/30391

You mean turn char label into something like DNAString label? If that means we could have the label contain an arbitrary number of characters while having the container adapt to the size of the string, then I'm all for it.

@JacquesLucke Has there already been any work done on a DNAString container?

@HooglyBoogly >A better approach would probably be turning the label into an allocated string (the DNA equivalent of std::string). For that, I would prefer to rely on the longer term developments discussed here: https://devtalk.blender.org/t/dna-decentralization-and-c/30391 You mean turn `char label` into something like `DNAString label`? If that means we could have the label contain an arbitrary number of characters while having the container adapt to the size of the string, then I'm all for it. @JacquesLucke Has there already been any work done on a `DNAString` container?

Hans Goudey commented

2023-11-05 22:06:36 +01:00

Member

There hasn't been a decision about how we proceed with that topic. A clearer shorter term goal is allowing DNA to convert between char array[64] and a char * separately allocated string. But that would raise forward compatibility issues as well.

There hasn't been a decision about how we proceed with that topic. A clearer shorter term goal is allowing DNA to convert between `char array[64]` and a `char *` separately allocated string. But that would raise forward compatibility issues as well.

Hoshinova commented

2023-11-05 22:12:21 +01:00

Author

Member

If we'll have forward compatibility issues anyways, then why not just have all DNA use a single universal DNAString container and have this discussion off the table for the next 20 years?

If we'll have forward compatibility issues anyways, then why not just have all DNA use a single universal `DNAString` container and have this discussion off the table for the next 20 years?

Hans Goudey commented

2023-11-05 22:14:13 +01:00

Member

Not sure I understand your question. But anyway, I don't think code review is really the right place for this discussion.

Not sure I understand your question. But anyway, I don't think code review is really the right place for this discussion.

Hans Goudey closed this pull request

2024-02-14 15:56:15 +01:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

2 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#114378

No description provided.