182797ea61
This adds a new Format String node which simplifies constructing strings from multiple values. The node takes a format string and a dynamic number of additional parameters as input. The format string determines how the other inputs are inserted into the string. Only integer, float and string inputs are supported for now. It supports two different format syntaxes: * Python compatible format syntax which also mostly matches the behavior of the `fmt` C++ library. Most of this is supported, but there are some small limitations. * Syntax of the form `###.##` where each `#` stands for a digit. This is the syntax that was introduced in #134860. This node greatly simplifies common string operations which would have required potentially many nodes before to convert numbers to strings and to concatenate them. It also makes new conversions possible that were not supported before. This node can also be used to insert e.g. frame numbers into a file path which was surprisingly complex before. This node has special behavior for the name of new inputs. For the purpose of the node, the name of the inputs must be valid identifiers and it's usually helpful when they are short. New names are therefore initialized to be single characters. If possible, the first character of the linked input is used. This works well when connecting e.g. a Separate Vector/Color node. Otherwise, inputs are named `a` to `z` by default. If that's not possible, the source socket name is used instead (converted to be a valid identifier). If that still doesn't work, the name is made unique using the normal `.001` mechanism except that `_` instead of `.` is used as separator to make the name a valid identifier. Python Syntax references: * Python: https://docs.python.org/3/library/string.html#formatspec * `fmt`: https://fmt.dev/latest/syntax/ More detailed notes about compatibility with the above syntax specifications: * Conversion using e.g. `!r` like in Python is not supported (maybe the future). * Sub-attribute access like `{vector.x}` is not supported (maybe the future). * Using `%` like in Python is not supported (maybe in future). * Using `#` for an alternate form is not supported. This might help in the future to make the syntax compatible with #134860. * Using `L` like in the `fmt` library is not supported because it depends on the locale which is not good for determinism. * Grouping with e.g. thousands separators using e.g. `,` or `_` like in Python is not supported (maybe in future). Need to think about the locale here too. * Mixing of unnamed (`{}`) and named (`{x} or {0}`) specifiers is allowed. However, all unnamed specifiers must come before any named specifier. The implementation uses the `fmt` library for the actual formatting. However, the inputs are preprocessed to give us more control over the exact supported syntax and error messages. The code is already somewhat written so that many strings could be formatted with the same format but that's not actually used yet because we don't have string fields yet. Error messages are propagated using a new mechanism that allows a limited form of error propagation from multi-functions to the node that evaluates them. Currently, this only works in fairly limited circumstances, e.g. it does not work during field evaluation. Since this node is never part of field evaluation yet, that limitation seems ok, but it's something to work on at some point. Properly supporting that requires some more changes to propagate enough context information everywhere. Also showing errors of field evaluation on the field node itself (instead of on the evaluation node) requires even more work because our current logging system is not setup to support that yet. This node comes with a few new requirements for the socket items system: names must be valid identifiers and they are initialized in a non-trivial way. Overall, this was fairly straight forward to implement but currently it requires to adding a bunch of new members to all the accessors that don't really need it. This is something that we should simplify at some point even if I'm not entirely sure how yet. The same new requirements used in this node would probably also exist in a potential future expression node. Pull Request: https://projects.blender.org/blender/blender/pulls/138860
59 lines
1.1 KiB
C++
59 lines
1.1 KiB
C++
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
|
*
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
#pragma once
|
|
|
|
/** \file
|
|
* \ingroup fn
|
|
*
|
|
* An #Context is passed along with every call to a multi-function. Right now it does nothing,
|
|
* but it can be used for the following purposes:
|
|
* - Pass debug information up and down the function call stack.
|
|
* - Pass reusable memory buffers to sub-functions to increase performance.
|
|
* - Pass cached data to called functions.
|
|
*/
|
|
|
|
#include "FN_user_data.hh"
|
|
|
|
namespace blender::fn::multi_function {
|
|
|
|
class Context;
|
|
class ContextBuilder;
|
|
|
|
class Context {
|
|
public:
|
|
/**
|
|
* Custom user data that can be used in the function.
|
|
*/
|
|
UserData *user_data = nullptr;
|
|
|
|
friend ContextBuilder;
|
|
|
|
private:
|
|
Context() = default;
|
|
|
|
public:
|
|
Context(ContextBuilder & /*builder*/);
|
|
};
|
|
|
|
class ContextBuilder {
|
|
private:
|
|
Context context_;
|
|
|
|
friend Context;
|
|
|
|
public:
|
|
void user_data(UserData *user_data)
|
|
{
|
|
context_.user_data = user_data;
|
|
}
|
|
};
|
|
|
|
inline Context::Context(ContextBuilder &builder)
|
|
{
|
|
*this = builder.context_;
|
|
}
|
|
|
|
} // namespace blender::fn::multi_function
|