Austy51 |
I often come across many filters that have a very messy structure in the editor, and with so many lines going fr om one thing to another it is hard to tell how it is set up. Now I know there is already things set in place to help with that (specifically the component grouping feature), but I had the idea of adding a node set that is made of 2 nodes and has a receiver and a sender and all it does is bridge a gap without adding a big long line fr om one component to another.
Here are some example pictures of what I am talking about. (I color coded the nodes to tell where they are going) Without use of nodes ![]() With use of nodes ![]() Now you may be thinking "hey, how would someone figure out wh ere a node is leading to?" well then you would have it display a line connecting the two whenever you click on it. When I made the images I used slider controls as the teleporter node, but it could be something as simple as a small box shaped component that has a numeric (or alphanumeric) slider on it to select which channel it is on. Also, I believe the component would be best placed in the advanced tab. |
|
Posted: May 9, 2014 9:15 pm | ||
Skybase
![]() |
I always +1 this feature request.
|
|
Posted: May 9, 2014 9:29 pm | ||
Crapadilla
![]() |
I always thought that connections should just fade out (i.e. become invisible) when exceeding a certain distance from their source node and fade in again when arriving in the vicinity of the target node.
This way, connections in the local vicinity would be readable, but those that just happen to cross "underneath" - connecting two distant areas unrelated to your local work area - would be totally invisible. If you select the source (or target) component of such a connection, this connection would become fully visible, allowing you to follow it visually. Also, the visible connection "ends" near its source/target component could display a clickable icon that would let you quickly jump to the connected downstream or upstream component. [This would be similar to what the 'Don't panic' button does: Setting a new view center and zoom level for the filter editor view.] A benefit of "uncluttering" like this would be that you do not have to introduce new components. You'd just modify how the engine draws those connections. --- Crapadilla says: "Damn you, stupid redundant feature requests!" ;) |
|
Posted: May 10, 2014 10:03 am | ||
Austy51 |
That is a good idea too. But it is not why I want this feature.
I like making the editor all nice and clean and having every output fr om a filter go to something right in front of it so you know wh ere it is going. Also it bugs me whenever two lines cross (it's an OCD thing) Having the line fade out like that still doesn't fix the problem of having lines go backwards to components behind it, or a line going to something far away and crossing a bunch of other lines. |
|
Posted: May 10, 2014 10:18 pm | ||
Crapadilla
![]() |
Yeah, connections can get messy and confusing to look at. Still, that's pretty much a necessary evil in more complex filters. In the pursuit of computational efficiency, you won't be able to avoid crossing connections and connections going backwards behind components, even in very structured layouts.
But... coming back to your two examples: To me, your first example is immediately and clearly decipherable, while the second one appears more visually obscure (i.e. harder to read by several degrees). Consequently, I do find the second example worse (i.e. more unclear) than the first. Just my personal take, though. --- Crapadilla says: "Damn you, stupid redundant feature requests!" ;) |
|
Posted: May 11, 2014 6:41 am | ||
Skybase
![]() |
Actaully on second thought I'd be able to really obfuscate and do some crazy things that nobody will understand.
|
|
Posted: May 11, 2014 7:25 am | ||
Velho |
I'd prefer that when you select a component, the other components connected to it's inputs would be highlighted. Maybe the connections could be highlighted as well.
|
|
Posted: May 11, 2014 9:36 am | ||
Ramlyn
![]() |
My opinion is that we could simply collect the components in groups. This would already make the main structure easier to understand.
Then, every single group would contain only what is necessary for a particular effect, so it wouldn't be too complex. Austy51 idea is ok, but I'm not sure it may really make the structure more understandable. At a first view, the structure may look more simple, because it reduces the number of connections. But, in complex filters, not connecting too many components may make difficult to check quickly what is connected with what. |
|
Posted: May 11, 2014 12:04 pm | ||
Austy51 |
I understand what you guys are talking about. I added this post because I think that there are cases in which this would be usable, but it would be an optional component in filter forge.
If you don't like how it looks with teleporting nodes, then don't use them. I just think it would be a really easy thing to add in the next release to be used to make filters cleaner and easier to look at - if you would even wan't to use it. I personally hate having any lines crossing each other or going backwards in a filter, so this is something I would use. Now, to address some of the ideas you had about this: Crapadilla - You said that having lines crossing and going backwards is a necessary evil, although I just came up with an idea to fix it. Also, as I said before: If you wan't the connections to be more clear when you are looking at the filter as a whole, then just don't use these. -Also I think that having the connector lines appear for all the teleporting node connected to whatever component you have currently selected would be a nice fix. -Or even have a general check box somewhere to be able to select if you want the lines to show at all times, you know, just in case you opened up a filter that somebody else made who had used a bunch of teleporting nodes. -Also I think using the idea you had of having faded lines for connectors can be used here. You can have a short line come out of the node with an arrow on it to show where it is pointing. Skybase - you can make really confusing filters anyway without use of T-nodes. -Also i'm going to call them T-nodes, because I am really tired of typing teleporting. Velho - Good idea! Thank you for positively contributing to the idea instead of knocking it down because it wouldn't be something you would always use. Ramlyn - Going back to what I wrote for Crapadilla. If you think putting these in big filters is a bad idea then don't do it. -Lastly, I think for any good feature that can be added into Filter Forge, should be added into Filter Forge. Whether or not it would be used 100% of the time doesn't matter. You could find yourself wanting a T-node, and are unable to do so because it wasn't added because somebody else didn't wan't to use it. Everybody would use these differently and in different measures, but I still think it should be there to use. Also another idea of an fairly useless component would be a middle node. Basically having a blank node that just has an input and an output. It would be used to angle long connections around others. The middle node would be something that is rarely used, but it still is occasionally useful and is easy to make and add (programming wise). |
|
Posted: May 11, 2014 5:07 pm | ||
Crapadilla
![]() |
Fun fact: You could easily arrange the proposed "Node Receivers" in a way that creates crossing connections, or makes connections go backwards underneath components. In short, these nodes could be used to obfuscate things even more.
Basically, what the proposed "Node Receivers" do is allow the user to manually control the angle of outgoing and incoming connections as well as manually specify a cutoff distance for connections (i.e. the distance after which connections will no longer be drawn). Being able to manually control the angle of outgoing/incoming connections really is a double-edged sword. This angle serves as a visual indicator of the direction you can find the target/source component in. Wrong angles/directions make a filter tree very hard to read. Now, as I've suggested in my first post, there is an implementation of the "teleporting nodes" idea that would work automatically in the background -- without bothering the user with the micro-management of connection angles/cutoffs via additional components. In conclusion, I'm not "knocking down" the general idea at all -- I'm rejecting the originally proposed implementation of it, simply because I'm convinced there are more elegant solutions to the problem of improving readability of filter trees. --- Crapadilla says: "Damn you, stupid redundant feature requests!" ;) |
|
Posted: May 12, 2014 7:03 am | ||
Austy51 |
The idea of a "Node Receiver" is a good idea. But I don't know if you are proposing a new idea or trying to knock my idea down, because I must not get exactly what you mean by manually controlling the angle and distance. Do you mean that the line will just go out at a random (user controlled) angle and distance, and be completely misleading as to where it is going? That just seems useless, and not at all what the T-nodes would be doing.
That is not the point of what I am wanting. What I am wanting is something that will simplify a filter, and, to me, a simple filter is one without any super long lines, or crossed lines, or backwards lines. Now, you still would easily be able to see where connections are going just by clicking on a component and having all the connecting lines of all the incoming/outgoing T-nodes that are attached to that component appear or even having the option of having those lines be always on. Also, T-nodes aren't changing the angles of the outputs. they are like an extra redundant component that are only used when they are needed. Now, before you say "That would just add more clutter to a filter." I would want to point out these would only be used when you want them to be used; in whatever way you would use them. Again, I would use them to bridge large confusing gaps, or remove crossing lines. But again you wouldn't even have to use these, and we could implement Crapadilla's fading line idea along side it so we can all be happy. Which in itself is a good idea of something to add, but it would serve a different purpose. |
|
Posted: May 12, 2014 4:33 pm |
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,711 Registered Users
+18 new in 30 days!
153,531 Posts
+36 new in 30 days!
15,347 Topics
+72 new in year!
20 unregistered users.