point confusion or bug

chaynes56's Avatar


14 Dec, 2020 08:58 PM

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.

  1. Support Staff 1 Posted by john on 14 Dec, 2020 10:56 PM

    john's Avatar

    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!


  2. 2 Posted by chaynes56 on 15 Dec, 2020 08:24 PM

    chaynes56's Avatar

    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.

  3. Support Staff 3 Posted by john on 15 Dec, 2020 11:10 PM

    john's Avatar

    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.


  4. 4 Posted by chaynes56 on 15 Dec, 2020 11:53 PM

    chaynes56's Avatar

    This bug isn’t a show stopper for me. Just trying random things. Good way to find bugs :)


Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? 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

Recent Discussions

25 May, 2024 11:52 AM
24 May, 2024 07:39 AM
16 May, 2024 02:11 AM
16 May, 2024 01:58 AM
14 May, 2024 01:29 AM


13 May, 2024 12:36 AM
12 May, 2024 07:46 PM
05 May, 2024 04:38 PM
03 May, 2024 06:50 AM
03 May, 2024 12:30 AM
03 May, 2024 12:09 AM