Hi this is a suggestion for a new type of Blueprint node. This is the “Math formulae node”. Say you have a node that takes two coordinates and spits out a third of the distance from the origin. Usually you might have to combine lots of different nodes or create a function that looks like “z=Math.sqrt(xx+yy)/3”.
But wouldn’t it be nice, if you could have a node where you could edit equations just like in a word document or Mathematica or Maple.
i.e. it would be a node that looked like this:
Don’t you think that would be neat? You could have an option whether to diplay math as formatted or as text. It wouldn’t be too hard, just convert it to MathML or something. Editing it as a formulae might require more thinking, but I’m sure there are plugins out there.
What do you think? It would make the formulae more readable right?
(Extra things would be the ability to factorise expressions etc. which would increase performance. But that’s just a pipe dream)
The math function could be compiled on the fly with gcc into an in-memory function.
Well, not really. I mean that’s a start but it’s not formatted as a math expression. i.e. with powers as superscript, with square root symbols, quotients as numerator and denominator. As in the picture I supplied.
I bet it wouldn’t be too hard to convert the expression to MathML or latex and show it like that? Right? I mean its supposed to be visual programming and math expressions have a lot of visual ways of making them easier to read.
In your example it should (optionally) be shown in the node as:
At a glance that’s quicker to interpret than all the brackets on one line. Just type sin(2x+(y-2)/5) into Wolfram Alpha, for example, to see what I mean. The idea of nodes is to get away from code so this is a way to show formula in a human readable instead of machine readable way. (I know many will say, it’s perfectly understandable as it is, but remember that its supposed to be understandable by a layman who might have GCSE math but not programming language skills and might not understand that "" means times).
OK Since this node is in Beta. Can I suggest the following:
You should be able to include user-defined mathematical functions in your formulae. That is any function which does not rely on information about the world state. Examples would be a factorial function, user-defined vector math functions, sorting components of a vector, user defined math functions such as “cubePlus3(x)” etc. But it would exclude functions such as ColorOfSky() or LeftJoyStickPosition() since those changes depending on the world state.
There should be a separate node for boolean logic formuale. So you could write in !(x && y) and that would define a NAND node. These can be thought of as little integrated circuits. There should be an option to display these as truth tables.
It would be nice to see this idea extended to other areas such as writing a little expression to combine 5 strings x+" plus “+y+” equals " + (x+y) is quite cumbersome to construct out of nodes. This could be a string formulae node. Or even better output="<font colour=red>%d plus %d <b>equals</b> %d</font>".
An array formulae node could be made that translates SQL type expressions into a compressed node. e.g. “SELECT v.colour FROM SORT x ASCENDING” or whatever.
I’m sure there are other kinds of formulae that would save time creating nodes. RegEx? Shader Language? Multimedia Language (e.g. “PLAY x FROM 0.5s TO END LOOP TWICE”) The common theme should be they should be a self contained system operating on the a class of variables that aren’t affected by world-states. i.e. static functions.
Separate nodes should be where data flows in from something which is affected by the world to some static function that processes it and out again to a node which affects the world. The rest should be compressed just like the formulae node. There is no point displaying the inner workings of a factorial function node unless you have just created it and are testing it. From then on it should be a closed box
In each formulae node it should list the operations that you are allowed to use. For example in a Math node (+,-,*,/) for a string formulae node (+) for an array node (SELECT,WHERE,ORDER,FROM,SORT…)
Good news! We’ve cleaned up lingering issues with the node and moved it out of experimental. So if you have GitHub access, then you can mess with it’s “final” state in the main branch.
We have this! Any BlueprintPure function defined in a UBlueprintFunctionLibrary will be callable using this node. This is how we accommodate calls like sin(), square(), etc. We have even defined some aliases to make calling these functions easier (like “pow” for the “power” function). This also means functions that don’t have a place in traditional “math” context can be called (like UKismetSystemLibrary::IsPackagedForDistribution()… we’re not recommending you call things like this, but we don’t want to prevent it).
While there isn’t a separate node for this, we do accommodate some boolean logic in this expression node. You can have things like: ((x > y) && (z <= 2)). Currently, any named variable (“x”, “y”, “z”, etc.) will be spawned as a float. So you can’t explicitly have “x && y”, but this is something I’d like to address in the future (I’ve added a task to our backlog to discern the type from context).
A lot of these other suggestions are exciting, but we want to be careful. When we introduced this node, we realized that we were walking a fine line. Essentially we’re introducing programming into a visual scripting language. If you get into anything much more complicated, why aren’t you just writing it in code? That said, I can see arguments for having things like this available, and there is nothing preventing you from implementing a lot of these features yourself. I’d love to see what you come up with! If you have access to GitHub, then you can dissect the math node yourself. Hopefully I obnoxiously commented it to the point that it is understandable.
We do have a backlog for more features to add to this node (like conditional operators, inferring variable type, etc.). So keep the suggestions a coming! The node should be out of experimental for 4.3.
As Mike said, we’d like to have better auto-typing for brand new expressions, but you can change the type of an autogenerated variable right now by selecting the node and editing that pin, and it will conform to the new type when rebuilding the expression tree.
You can also use this before you modify the expression. Adding a new input to the node (of whatever type you want) will be usable just like a member variable when you edit the expression.
If you are interested in doing new expression graphs, the math node is a nice resource as it shows how to create a composite node (containing other nodes) from a textual input. If you’re interested in trying to parse some other DSL and convert it into nodes, it’d be a great starting point.
Hi, thanks for replying. Sounds like you got it all sorted!
Looking back at my suggestions, I would say my main extra node I think would be valuable (don’t know if I could make it, I’ve never done open source programming before!) would be the string combining node. I think it would have to be separate because you would simply have to assume all inputs and outputs were strings.
e.g. "There were “+x+” camels today at the "+y.
The output would be a string and we would also have to assume x and y were strings. For example y=“market” and x might be an integer converted into a string. It could be incorporated into the Math formulae node but it’s not really a Math formula even though it uses +'s. You could use * as well for example ":- ) "*10 would create a string with 10 smiley faces.
Or, I suppose a simpler solution would just be a concat node with multiple inputs! Come to think of it a “+” or “*” node with multiple inputs would also be fairly useful.
I wonder, in a Math node if you wanted to create one that added 3 vectors A+B+C how you would deduce that they are vectors? Would it assume they are floats then you change the type by hand?
P.S.
I don’t think it’s a problem writing in formulae. I wouldn’t count that as coding. I would count that as mathematics which most people learn at school. As long as it’s written in a fairly standard way that all languages agree on. e.g. using */± sin cos (not Math.sin) sqrt PI E pow exp (or ^) and (…) you don’t have to learn any language-specific words.
P.P.S. Yes, “domain specific” that’s the words I was looking for! “DSL nodes”. Has a nice ring to it!
P.P.P.S. Another advantage of DSL nodes is that you could copy and paste formulae from elsewhere! Such as if I had a formulae sin(x*x+y/3) from another non-blueprint project I could copy and paste that into my blueprints.
The expression parsing is split into a couple distinct steps, the first is tokenization, where we parse the string and segment it into things like literals (constant numbers, strings, etc.), operators (+,*,etc.), and variables. I believe this step already parses out and segments string literals (things like: "There were "), so that half is done for you. The other half that is left to do is turning those tokens into blueprint nodes and connecting them.
Right now, you’d have to do something like: “vec(x,y,z)+vec(1,2,3)+vec(u,v,0)”. You could change the var type after the node was generated, but you’d probably have to replace the nodes that they’re plugging into as well (to be vector specific functions).
Is there a reference page for the formating required to use the node? For instance, for Power people have said to use POW, but I haven’t seen these specifics outlined anywhere.
No, unfortunately not yet, but I’ll bring it up with the docs team today to see if we can get the ball rolling on one. “Power” will also work, but POW is an alias that’s used to map to the same function. So you can use one or the either.
