point confusion or bug
The copy node takes two floats for x and y scaling. To make proportional scaling easy, I've tried connecting a make_point node to the copy node scaling input, with a single number node feeding both the make_point inputs. This has no effect.
Perhaps make_point isn't the right type of node. There is more than one type of point node, but the documentation of other node input types seem to mention only one point type. In general, it looks like more care in type designations in the documentation would be helpful.
Type checking at connection points so that improperly typed connections are impossible would be great. Type coercions, where unambiguous, would also be nice, and documentation of coercions would also be most welcome.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by john on 14 Dec, 2020 10:56 PM
Hi Chris,
I don't understand why you're having trouble with this. You can feed a number or a point or a point made out of a number into the scaling port of the copy node; all three ways work fine. See attached screenshot and sample code.
Although primarily used to represent coordinates, points can be used to represent any pair of numbers (like width and height for scaling). As a convenience, NodeBox allows you to feed a single number into point ports, including the scale node; it interprets this as the same value for both X and Y. And you can always use the make_point node to construct a pair of numbers.
NodeBox does do some type checking. If you have a list of values which contain a mixture of integers and floats and feed it into, say, a sum node, you'll get a class error. The solution is to feed the list into a number node to force all values to float before passing it to the sum node.
In most cases, though, NodeBox is quite liberal about types. You can usually use integers and floats interchangeably, and can feed numbers into string ports and strings into number ports (as long as the string is a number). You can also add and multiply booleans with each other or with numbers - very handy.
This may offend fans of strong typing. But I think it's the right choice for NodeBox. NodeBox was created to make it easier for artists to code with minimal hassle. Forcing users to add a node (and a link to that node and a link from that node) to do type conversion every time they want to display a total as a textpath or sum three integers or whatever would get in the way of creation and add unneeded clutter to already busy node networks. The joy of NodeBox is the ability to almost instantly turn an idea into something visible and changeable.
I do agree that more documentation about these subtleties would be helpful. Until the happy day that someone volunteers to write that documentation, I will do my best to help out here in the forum.
Please keep your questions and suggestions coming!
John
2 Posted by chaynes56 on 15 Dec, 2020 08:24 PM
Apologies. I didn’t do my homework on this one. The problem was nothing to do with the type of scale input. I should have confirmed that adjusting the scale parameters in the copy metadata have the intended effect. They don’t.
There’s clearly something basic I don’t understand (or perhaps a bug). See the attach test program. Changing the scale parameters of the copy node has no effect. If I change the transformation order, it does. Confusion, or bug? For some security reason it wouldn't take the ndbx file upload, so I zipped it. Also included a screen shot that probably has enough info if I'm simply confused again.
Again, I appreciate the related perspectives you shared in your reply, John. I've studied type system design a lot. Strong typing has its place, but for this sort of thing I agree dynamic typing is much better. I'm an old Scheme (Lisp) fan, and mostly use Python for odd jobs now, so dynamic typing is in my blood. My only point was that if it's clear things won't work due to a type conflict for which there's no obvious coercion, there should be an error message. Your reply indicates that at least in some cases NodeBox does that.
Support Staff 3 Posted by john on 15 Dec, 2020 11:10 PM
Congratulations, Chris. I think you found an actual Nodebox bug.
There are six possible orders in which to apply the three transformations. Five of the six work as expected. But if you set the order to Rotate, then Translate, then Scale, the copy node rotates correctly, translates correctly, but fails to scale.
This appears to me to be a bug which anyone can replicate using your test file. I had never noticed this before. I did a brief search of the forum but could find no earlier reference to it.
I have added Frederik (the inventor of Nodebox) to this conversation in case he wishes to comment.
Does this bug prevent you from creating the effect you wanted? Or can you achieve it by just changing the order? Since you're not translating, I assume you could just use Rotate Scale Translate instead.
By the way, you were right to zip your test file before uploading. For some reason this forum software often does not like unzipped Nodebox files. I always zip mine before attaching.
John
4 Posted by chaynes56 on 15 Dec, 2020 11:53 PM
This bug isn’t a show stopper for me. Just trying random things. Good way to find bugs :)
Chris