New name for Debug Drawer node

[JacquesLucke]

I would like to rename the Debug Drawer node to give it a more meaningful name. This is especially important when we have other debug nodes that draw stuff in the future (eg a node that draws in the 3d viewport).

I don't know yet what a better name is, if someone has an idea, please post it here. Preferably we should rename this before the release.

[rasamaya]

Debug Sockets Debug Data Debug 3D Debug Scene

[JacquesLucke]

Thanks, unfortunately none of these names really tells what the node does. Debug Data would still be the best of those I guess. Maybe I should join the node with the normal Debug node.. Not sure about that. There could be an option to use the "draw-mode" or not, or the node decides automatically what would be best.

[LeonCheung]

Not sure what exactly will be planned for 3d viewport display, in which case, I guess it could be called a Viewer or Visualizer?

But I also agree to combine the Debug and Debug Drawer, actually I suggest to combine all current debug nodes into a "N in 1" Debug node that will be not only smart enough to automatically choose the most expected mode for target data, but also allow users to make manual decision in particular cases (sounds crazy anyway :P ).

[enzyme69]

Debug Stethoschope 👯 :D

I think any node with "Viewer" should be related to what you see in 3D View.

[JacquesLucke]

What do you think about this:

We could remove the word "Debug" completely from Animation Nodes. It is something normal users don't really know what it is. Instead we could rename the nodes like so: Debug and Debug Drawer -> Viewer (combine both nodes) Debug Loop -> Loop Viewer Debug List -> List Viewer Debug Interpolation -> Interpolation Viewer

The new debug node I plan can be called "3D Viewer" then.

Opinions?

[LeonCheung]

Not a bad idea. What I'm wondering is, for Debug Loop and Debug List, should they behave more like "data recorder/writer"? Because you need to write them down to the Text Editor anyway in order to check the details, Furthermore, List Viewer might also be a bit ambiguous with Viewer for new users, since Viewer node actually debug list as well. Besides that, all should be fine. FYI

But this is not so critical for sure. Function matters after all, more than what you name it.

[JacquesLucke]

do we need the Debug List node anyway? Maybe we can join it with the normal Debug node as well (which we might rename to Viewer). It could have 3 options: in-node, overlay-draw, text-editor (those names are not official, tell me if you have better alternatives)

[LeonCheung]

Yeah, thats why Ive been voting for a combination if possible. To be honest, writting debug result to textblock still gets its own advantage when trying to extract data generated by AN then use them elsewhere (inside or outside AN anyway, e.g. for an AN/SV workflow), because it seems impossible to get the written data by not doing so.

[JacquesLucke]

That's true, so combining all these three noded into one to get the best from all worlds seems to be the best solution.

Beside the three modes I mentioned earlier, we can also have a mode called "automatic" that chooses one of the others depending on the data type.

[LeonCheung]

Sounds cool.

[JacquesLucke]

Another idea would be to do it like this:

3 modes: automatic, in-node (one liner), text overlay (multiple lines).

In addition to that there can be a checkbox "Output in Text Block". If it is enabled, there will be a new text block input socket. The data will then be drawn in the node editor and in the text editor.

All these option are in the Advanced Settings. By default the mode is "automatic" and the checkbox is turned off.

One thing I still don't know is, if the text in the text editor should be exactly the same as in the​ bode editor, or if it should be formatted differently.

[LeonCheung]

I*ll vote for a WYSIWYG style, though I believe the textblock is usually for list. In case not, the manual switch would hopefully solve that.

However, one more concern is how it would look like while outputting results that contain line breaks, a corner case perhaps.

[JacquesLucke]

ok. I think I won't handle text with line breaks explicitly.

In general using a text block should only be used in rare cases as it can be much slower. The problem is that all list elements have to be printed in the text block, while the Debug Drawer currently only converts a few elements to text which allows it to work with much longer lists.

[JacquesLucke]

I was thinking about it again, do users really need to be able to adjust wether the information is drawn in the node or below it? I can't think of a scenario right now where AN could not figure out the best place itself. The user normally does not care where the information is, as long as he can see everything, right?

[LeonCheung]

Yeah, AS LONG AS he can see everything. Not sure if we are talking about the same thing, just thinking about a scenario when debugging a relatively long list (e.g. with 500+ elements), do users want to view the complete result with in a very long overlay (when they have to) in Node Editor, or they would rather view it in Text Editor conveniently?

[JacquesLucke]

I think it is rarely important to really see every element in the list, so I think the node should not show all the elements in the node editor. I want to implement the same functionality we have in the Debug Drawer as well, where we can choose how many objects to show. When "Show in Text Editor" is enabled, the whole list will be written in the text editor, not just a part of it.

[LeonCheung]

Agree.

[scorpion451]

Two counter opinions:

• I always use the debug drawer, never debug list. I find it more convenient to have everything in one panel, and as someone who uses a wacom tablet, I can freely slide around on the node panel, zoom out and look for a particular spot on a list, and then zoom back in to look at it closely with a couple flicks of the wrist. On the text editor I have to fiddle with arrow keys, the scroll bar, and a locked zoom size while trying not to accidentally let my stylus hover over another panel and change the focus.
• I frequently need to see the entire contents of a list at the same time. Looking at the raw data laid out in a series is simply the fastest and most effective way for me to troubleshoot.

For an example of both, the other day I set up a node tree to make a character blink at semi-random intervals. I connected several debug drawer to different points in the tree, set them to display ~200 frames each, and placed them side by side. This let me see in real-time how the spacing between blinks was changing while I fine-tuned the math, and helped me track down where a couple of weird frames were coming from. It would have been a pain to do the same thing with the list node.

[JacquesLucke]

@scorpion451: this will still be possible of course, it's just not very common. In many cases you only need to see the first few elements to see if everything works correctly.

[JacquesLucke]

There are no debug nodes anymore now :) The "debug system" has been replaced by the "viewer system".

Currently we have 4 viewer nodes: Viewer, 3D Viewer, Loop Viewer, Interpolation Viewer